Anyway, in my opinon it’s an interesting list and most likely incomplete. What it is, however, is something that could potentially be used as a tick list for organisations starting out with ITIL or considering a change of IT service management (ITSM) tool. Please take a read and let me know what I missed (or if you think I am making bits up).
Understanding and Vision
1. Believing the ITIL hype or, for my American friends, “drinking the Kool-Aid”. It’s about improving the business not adopting ITIL.
2. Not understanding what ITIL is, i.e. that it is only a framework. There is no such thing as ITIL-compliance. Oh, and ITIL does not equal ITSM and vice versa.
3. Not understanding that it isn’t about “doing ITIL” but rather that it is about “using ITIL”.
4. Thinking that either ITIL is a silver bullet or that it “the only fruit”. What about ISO 20000, COBIT, USMBOK, Six Sigma, and CMMi?
5. Not fully understanding the breadth and depth of the changes it will require across people, process, and technology.
6. Not understanding the level of resources (including cost) and commitment needed to adopt it.
7. Not understanding the criticality of people to success.
8. Not understanding that it isn’t a one-off project (nor is it an “ITIL project” or “ITIL implementation”).
9. Thinking that ITIL is the answer rather than just guidance.
10. Not understanding and committing to the concepts of ITIL - IT delivered as a service and the service lifecycle.
11. Not understanding that these “end user types” are actually “internal customers”.
12. Not having an overall vision for I&O improvement and/or optimization.
13. Lack of top-level support and buy-in (yes, it’s an old chestnut).
14. Insufficient effort placed on selling the concepts and benefits of ITIL to employees. The result is a lack of commitment and reticence to change.
15. Not realising that this is a commitment to ITIL beyond the life of the adoption project.
16. Not ensuring that roles or individuals are responsible and accountable for individual ITIL-aligned processes and their performance.
17. Not having a common understanding and language concerning the reasoning behind and the benefits of ITIL adoption. Not communicating in language the business understands.
18. Poorly or mismanaging business stakeholder expectations. Not planning for resistance.
19. No, or lackadaisical, business case. More of a leap of faith into the arms of ITIL.
20. Lack of an overall vision including short, medium, and long-term goals. Planning beyond the technology implementation.
21. Planning for a shorter adoption window than is realistic (normally driven by how long it takes to install the technology).
22. Not planning for inter-process linkages and dependencies.
23. Not planning for technology integrations with other corporate systems.
24. Not thinking beyond IT and how the processes and technology can be leveraged by other business activities such as facilities management, complaint management, or people management.
25. Thinking that sending your people on ITIL training courses is enough. Training needs to encompass not only the concepts of ITIL, the processes in the context of the organization, and how to use related technology but also areas such as “the business” and customer service.
26. Employing people based on ITIL qualifications rather than experience, work ethic, and common sense.
27. Thinking that consultants will deliver a “finished” solution (or even that the consultants can and will do all the heavy lifting).
28. Starting with an incomplete plan. We don’t want a Pirates of the Caribbean 3-esque ITIL adoption do we?
29. Not planning for success. An initial failure is a shadow looming large over future attempts.
30. Trying to do too much too soon, the proverbial “running before walking”. Trying to implement too many processes at once is like doing two jobs badly rather than one well.
31. Too internally focused, it’s often about what I&O wants to provide rather than what the customer wants and needs.
32. Aiming for perfection from the outset rather than trying to get the basics right, often death by flowcharting.
33. As a caveat to the above, the reverse can also be true - not providing sufficient operational details for processes to be followed “in the real world”.
34. Quick wins are often paraded in the business case but lost in the mayhem of change. Where are benefits accounted for?
35. Too often too much reliance is placed on the technology. However the correct implementation of the technology is critical - when people say they dislike their ITSM technology it is often the implementation of the technology that causes them issues.
36. Insufficient focus on people and organizational change management, where’s the WIIFM?
37. Too much emphasis is placed on the “easy stuff” such as incident management. Organisations then fail to progress past the reactive elements to the proactive elements of ITIL such as availability and capacity management.
38. Having said the above, too little emphasis is then placed on customer service and satisfaction in the context of these reactive processes.
39. While consultants can add value they are often badly managed. A particular issue is the transfer of knowledge to employees and allowing the consults to concentrate of the higher value-add activities.
40. Not freeing up key internal people from their day jobs to work on the ITIL adoption.
41. This is a personal one - anyone else ever work for an organisation that staffs up business change projects with surplus people rather than their best people (of course these groups need not be mutually exclusive)?
42. Good old-fashioned poor or ineffective project management.
43. Placing more emphasis on the “IT” and less on the “SM” part of ITSM.
44. Silo-ing processes (both operation and responsibility) within individual teams rather than appreciating that processes will span teams and functions. Ask yourself why you have multiple change processes across Run the Business and Change the Business for instance.
45. Then there is “the elephant in the ITIL adoption living room” - failing to maintain momentum after third-party “supporting” resources, like consultants, have left the organisation.
46. ITIL’s enabling and enveloping processes are seen as add-ons rather that elements of other processes and therefore relevant from day one. Two great examples are continual service improvement and knowledge management. Oh, and IT financial management too.
Measurement and Improvement
47. There is no measurement of the current state to allow for the assessment of improvements. In fact, often too little emphasis is placed on improvement post-adoption project.
48. Adopted metrics and KPIs are often misaligned with business requirements, they are often IT-focused or technology-led.
49. Not identifying success stories and communicating them back to the business.
50. Last but not least, day-to-day operation can become more about the processes than service delivery; it’s like ticking boxes or operating in a vacuum. People never question why they do things the way that they do.Posted by Stephen Mann