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:

Please check out my latest blog ... http://blogs.forrester.com/stephen_mann

Comments

End to a means

I agree with all of these and could probably add a few more. In sime cases they are avoidable mistakes, but sometimes they are part of the eco-system.

Perhaps it is the undue influence of Ian Clayton ( who I'm guessing will be commenting within seconds) but for me many of these can all be traced back to ITIL and ITSM being solutions to a problem that is rarely acknowledeged.

Red pill or blue pill?

If you NEED to implement ITIL/ITSM then you need to admit that you are failing to deliver the service/product that your customer needs.

You forget that at your peril, but many people do, depsite the best attempts of their customers to remind them of the fact. As a result they forget the reason why doing ITIL/ITSM is important and fail to convince others of why it is important.

And the "problem" is?

OK, James. I'll bite.

What is the problem that is rarely acknowledged?
How does ITIL/ITSM *really* address that problem?

kengon

James - I agree with

James - I agree with you.

There is a more positive way to look at why you need to improve the Service Management capability. Yes, you may be failing in some ways, but even if you are not seen to be failing you need to keep up with changing requirements and continually improve the capability to stay ahead of competition and various threats that can come up. An initiative which includes better service management may just be reflecting a new requirement or an improved maturity - which could be positive rather than reacting to a perceived failure.

I think it is reality of the subjective nature of what we do in Service Management. People will have an opinion on whether you are failing or not. It's not something that gets proved by reports and data, it is about how people feel. Even if on paper you are seen to be meeting all your targets, you may still not be meeting expectations of some and if they are not happy then you may still get negative feedback. We probably have to accept that perception is reality to a certain extent, because we won't survive if we spend all our time arguing the point.

The focus needs to be on the business objectives you are seeking to achieve, not on the mechanisms and influences (like ITIL or any other similar item) you are using.

You can fail today, or you can fail tomorrow...

...it is still failing !

But seriously I did talk about implemeting ITIL/ITSM, which of course is an expression most of us would avoid these days, and I've suprised the company here hasn't picked me up on that , but I did so deliberatly. There is a difference between on the one hand starting to take ITSM seriously and need ing to use something like ITIL or a switch of service management toolset, to make that change of attitude stick, and on the other maintaining an ITSM culture in the face of change.

The stories we get to hear in most articles and confernece sessions, and where the value of recognising many of the mistakes Stephen has identified tend to ocur, are about the first klnd of situation, rather than about maintaining momentum and remaining agile. Again I'm sure Ian can give us a marketing perspective on this.

I've often made the point that in IT we would often benefit from making the distinction the medical profession does between chronic and acute health issues. Although the real benefit of ITSM is to be found in treating chronic cases we too often use it just to address the acute ones, and then we stop taking the pills.

@jimbofin (If anyone is reading this blog and the comments and is not on Twitter I would suggest you sign up, since this discusson is bound to continue there as well)

Transformation

James - It's a good point, and a very similar one I make when I'm explaining the difference between Transformation and Continual Improvement (similar to the difference between Chronic and Acute). We created our Transformation Journey methodology, which would not be a suitable approach for Continual Improvement, because you need a specific approach for transformational business change.

Ears Burning While ITIL Fiddles

James - my ears were burning...

Stephen - amazing job - you should have helped write the new books. Few of these are actually suggested in Edition 2011 as things to watch out for.

James - exactly - if you are 'implementing' anything you are likely on the path to failing your customers. ITSMers/ITILers should consider words like 'listen', 'hug', 'understand', 'WOCAS - what our customers are saying about our services' and spend a day with customers looking at one aspect of their services rather than lobbing in the proverbial reengineering hand grenade.

A huge test - sit down with one (friendly?) customer and use the chess clock method set at 30 seconds to exchange views and comments on "how you can help them succeed". See how often ITSM or ITIL is injected in, and by whome, and whether it lasts more than 3-4 rounds.

Thanks Ian ...

... I have still to spend my (or Forrester's) hard earned cash on the ITIL 2011 books (PDF version me thinks).

No - invest in me!

Stephen - said with only half my tongue in my cheek - invest in my practitioner guides!

Making of a good checklist

Stephen, the value of the list could grow. Very useful for organizations to run down this checklist and make it a matter of habit.
Very very useful. Thanks for sharing.

Sincerely,
@bro0t

Step 1. Define the Problem

Kengon - there yer go!

I'm going to suggest something here that may rub the IT genetic code the wrong way... so I'll offer a 'process' first to grease the edges...

1. Pick a customer community, anyone, go on lift your head, who is out there? Pick one?
2. Find a 'dougnut and coffee' store near customer location
3. Make an appointment with anyone in that community who is prepared to speak with you (first clue)
4. Visit, offer them the doughnuts and coffee (fresh please) you bought on the way
5. ASK - the following simple questions...

A) Is there one thing I and IT could do differently or better that would help you succeed in what you do every day?

Write down word for word whatever is said in response....

Go back to base and develop a two paragraph email that explains how your ITSM/ITIL ambitions will improve this situation.

Repeat as necessary.... and file results under 'continuous improvement is the death of ITSM projects'

This is similar ...

... to what I have recommending to Forrester clients since I joined ...

Ask an internal customer to score IT on a scale of 1-10 (BTW be prepared for the score being lower than you expect/want). Then ask what IT needs to do to move from that 5 or 6 to a 7 or 8. So much value in starting a dialog about real IT perceptions.

Also helps to set and manage expectations.

The Wake Up Call

Just to be clear, my posing those two questions was *not* intended as a jab @ jimbo! If I wanted to do that, I'd go a more direct route! :-)

Thanks for kicking this in.
I think this is the right direction to steer the conversation.

In a related tweet, I wrote that I only have three items on my list:
1. Leadership
2. Communication
3. Accomplishment

Those are the only things we *really need to pay attention to*!
The remainder (and it's not that it's a bad remainder) is all detail that will flow from those three.

In the end, it's all about people -- establishing and deepening relationships.
If you don't do that, you're left playing the "commodity services" game and everyone loses!

kengon

Personal impact is the oil of change

Ken, I've found that you need to be able to personally impact a person, positively or negatively, to realize any of the three items you listed. This takes me back to (I think) what I was alluding to, and what Stephen commented. Make it personal. Set a smaller scope and goal,

Find one problem, translate it into an opportunity for improvement.

This is the very essence of what I try to do with my programs and yet the majority of folks I meet are still smoking teh 'Implement ITSM' crack... help...

Yes And More...

I take no issue with your comments and endorse the surgical approach!
It's also important to recognize that my three items also play out in the context of organizations and creating lasting, sustainable change.
I like that I can start working *anywhere* in an organization and tie all these elements together.
It's not just for individuals...

kengon

Talking to customers

I'm always advising my customers to sit down with their customers and do exactly what Ian has suggested. Almost always, they are reluctant to do it. Maybe this is because they already recognise deep down that they are failing to express what they do in terms which their customers and business colleagues understand (and see value in).

They often see the options as being 2 equally horrible choices:
1. Show the customer your current Service Catalogue (knowing that it's not something they recognise or see any value in - probably because it's a list of systems or applications)
2. Go with a blank sheet of paper as say "what do you think you get from us?"

With some customers I've had to push the boundaries a little and sit down with their customers to make sure the conversation happens. My reassurance to all who fear starting this dialogue is that it is always worthwhile and beneficial in the end. Yes, you might feel a little discomfort at times, but it needs to be done, and you'll be glad you did it.

Great list Steve - we see

Great list Steve - we see these all the time. Two really big ones we see, and you've sort of covered them: 1. Thinking that a tool will solve all their problems, and 2. Thinking that putting people through the ITIL Foundation course is all they need, i.e. "go on the Foundation course and you will then have enough knowledge to adopt ITIL."

The overselling of ITIL?

Totally agree Alan ... ITIL is often oversold by providers of products and services and unfortunately we haven't reached a point of collective understanding such that customers know what tools and training can and should deliver.

ITIL is not a Strategy

I would add to the list : Assuming ITIL is your IT Strategy.

ITIL is a best practice not a strategy, the salient analogy is the Japanese automotive industry, they all broadly adopted 'Just In Time' manufacturing best practices and overtime they all converged on the same productivity frontier ; until the recent Toyota situation you couldn't understand why you would buy a Honda over a Nissan over a Lexus.

I find many IT departments are in a similar position, in their case focusing on internalised view of resources and capabilities espoused by ITIL only to miss the fact that they are about to be outtsourced in favour of a provider who offers a better cost or quality model.

Outside IT

Failing to get key people from outside IT participating.

Quality people, who often have the real experience on getting iniciatives done on their organization. There's lot of activivities (around improvement, measuring, satisfaction, complaints) that may be already happening outside IT - or require help.

Plan, Do, Stop!

Stephen, you've nailed most of the mistakes. Most IT organisations can make decent headway with the most commonly adopted processes (Incident, Problem & Change). However, I'd argue that Problem Management could be delivering much more value than most adopters manage to realise. The key thing is that you can make 'reasonable' progress with these basic processes without radically changing the culture, and without much engagement with the customer/user.

The more proactive processes (SLM, Service Catalog etc) require a level of customer engagement that is lacking in many IT organisations. There is no getting away from the fact that Service Management is a mindset, and true benefit can only be delivered once you have engaged the customer to find out what's important to them. Apart from USMBOK, I don't believe that any framework places enough importance on the customer element, which is so crucial to success. I believe this is why progress stagnates, as far too many adopters fall foul of Plan, Do, Stop!

Using blog for local itSMF

Stephen,
I would like to use your\this blog for our upcoming local (Perth, Australia) itSMF seminar.
The idea is to play BINGO, i.e. we'll 'draw' a numbers of these mistakes and discuss them. Whomever has got all of them 'wins'.
I also would like to reference this site, or even print out a copy of the blog for each participant for further info.
Is that OK (feel free to e-mail me directly)?
With regards,
Simon

iso 9000

Very good post, I was really searching for this topic, as I wanted this topic to understand completely and it is also very rare in internet, that is why it was very difficult to understand.
iso 9000

Underlying Source; Symptoms not problems.

A bit late to the party... even so.. :-)

I suspect the fundamental or underlying cause for the 50+ is a quick-fix attitude. That leads to believing that ITIL is something it isn't, that ITIL is a "fix" or panacea for problems, specifically process problems. This notion is ITIL completely and totally misunderstood that leads to a degree of dogma (Kool-Aid consumption :-)) devoid of an understanding.

At its core ITIL describes a different paradigm for IT. One that is customer-centric. It's about the business, outside-in thinking that typically absent in IT. Actually, it's not just IT, every related engineering curriculum (going back since the beginning of modern IT -- WW II) is more about technique and technology, inside-out thinking minus a business justification (or even consideration).

David
Is there any wonder for the size of the list... or that I suspect we could each add even more symptoms.

A big addition.

The ITIL "out of the box" mistake is one of the most diabolical ones.

The ITIL Wizard gives an excellent (tongue firmly in cheek) extrapolation.

http://www.itskeptic.org/node/1873

1) Implementing a tool is the most effective and cost-effective way to drive cultural change and improve process - it really hammers it home

2) Your new and preferred vendor is clearly confident and adept, ready to take on a comprehensive set of ITIL processes all at once. They can do this because they can knock off an ITIL process in one or two months, unlike the ITIL consultants who try to tell you cultural transformations take years

3) Software vendors are expert in ITIL. The tier-1 vendors you refer to have OGC's official certification of that on their products, as they frequently remind us

4) When you get software vendors' resources to do your project management for you, you buy the best in the industry - that's why you pay a premium.

5) Who better to understand how to implement ITIL processes than the vendor of the tool? C'mom this should be obvious. The vendor's technical staff may seem young to you, and maybe their only formal certifications are a computer science degree and a training course in their own product, but you can be sure they have done hundreds of ITIL process transformations in the same industry vertical as you using their product

6) Contracting with software vendors for delivery of an outcome is guaranteed - that's another reason why you pay more. They stand behind their products. They bring in their very best people from all over the world, especially in the pre-sales cycle, and again if the project is going badly wrong.

7) Software vendors have rich IP in ITIL processes: their material is always exciting and colourful and easy to understand

8) Software vendors demonstrate their deep understanding of cultural change through their own internal sensitive handling of human resources

Yup. When you hand your ITSM journey over to the software vendor you put yourself in safe hands.

Brilliant. I believe that I

Brilliant. I believe that I could use search and replace to change ITIL to almost any standard or framework and most of the comments would still be valid!

Funny ...

... I've had the same thought a few times when looking at different areas :)

Success

Stephen has inspired me to produce this brief blog post

http://coreitsm.blogspot.com/2011/12/3-secrets-of-itil-success.html

Great List

A wonderful list.

I get lots of requests, however, to "do ITIL."

Something in the education and marketing process leaves people thinking that the processes are everything and that even minor deviation from said processes is a denial of the "faith."