Top 20 (OK, 50) ITIL Adoption Mistakes
In a “spare” hour this afternoon I needed to create a list of the Top 20 ITIL adoption mistakes for a Forrester client. An hour later (I made sure I time boxed myself to avoid scope creep … oh dear, scope creep could be included below too) I had 50. Quite scary really.
Anyway, IMO 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 organizations 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 is “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
Business Backing
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. Result = lack of commitment and reticence to change
15. Not realizing 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 re the reasoning behind and the benefits of ITIL adoption. Not communicating in language the business understands
18. Poorly setting or mismanaging business stakeholder expectations. Not planning for resistance
Planning
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
Adoption
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. Organizations 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 organization 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” resource has left the organization, e.g. consultants
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.
UPDATE: Two popular ITIL-related blogs:
- http://blogs.forrester.com/stephen_mann/12-02-01-itil_adoption_5_steps_that_can_help_with_success
- http://blogs.forrester.com/stephen_mann/12-01-26-we_need_to_talk_about_itil
Please check out my latest blog … http://blogs.forrester.com/stephen_mann