What's wrong with ITIL V3?

I recently wrote a blog about What’s Coming in ITIL 4. While the response was generally very positive, a few people had questions. They asked why we needed ITIL 4, and what the drivers behind it were.  In short, they wanted to know what was wrong with the current version of ITIL. This blog reflects my own personal opinions about what’s wrong with ITIL V3, and why we need ITIL 4 and I should point out that it’s not based on official statements from the owners of ITIL.

I won’t give an overview of ITIL V3 here. If you aren’t familiar with it then have a look at one of my previous blogs on the topic:

• Getting Started with ITIL
• What is ITIL
• ITSM vs. ITIL: What’s the Difference?
• Do we still need ITIL?

I also won’t be providing an overview of ITIL 4 here, you can find that in my blog What’s Coming in ITIL 4.

Too much focus on process

ITIL V3 describes 26 processes organized into five lifecycle stages. Each lifecycle stage has its own book – Service Strategy, Service Design, Service Transition, Service Operation, and Continual Service Improvement.

The process descriptions in ITIL V3 include examples of typical activity flows. For example, the description of change management includes a diagram labelled “Example of a process flow for a normal change”. But though the books include lots of other great content, the example process flows seem to have taken on a life of their own. Even though they are clearly labelled as examples of how you might do the work, there’s an unfortunate tendency to treat them as instructions written in stone: “ITIL says you must do it this way”.  And that is not what anyone originally intended.

There’s a second problem too. ITIL service design describes “The Four Ps of service design”: People, Processes, Products (services, technology and tools), and Partners (suppliers, manufacturers and vendors). Despite this, the vast majority of the writing across all of the books is about the processes, and there’s far too little guidance on people, products, and partners.

This emphasis on process can lead to some very poor practice when it comes to using ITIL. Some organizations document processes and think that they have now adopted ITIL. Other organizations focus on a few specific processes, and are often disappointed by the results, because, operated in isolation they fail to deliver much value.

Implementation in SILOs

When organizations adopt ITIL V3, they often operate each of the processes as a separate set of activities. Every process has a queue of work, and these queues are independent of each other. But the activities needed to create value for our paying customers rarely depend on the smooth working of any one process alone.  More often, we need a combination of things from multiple processes. For example, resolving an issue which impacts users of a service may require activities from:

• Incident management: to diagnose individual user incidents and offer workarounds
• Problem management: to analyse the underlying causes and devise long term resolutions
• Service asset and configuration management: to provide information needed by incident and problem management
• Financial management for IT Services: to allocate budget for developing a solution
• Design coordination: to oversee design and development of a solution
• Availability management and Capacity management: to analyse alternate solutions and make recommendations
• Release and deployment management: to plan how a software fix will be rolled out
• Change management: to approve deployment of the software

And potentially many more.

When each of these processes has its own queue of work, this can lead to very long lead times with many delays. Really good organizations understand how to manage the flow of work across multiple processes, but ITIL V3 doesn’t provide enough guidance to help the rest of us get this right. V3 doesn’t actually tell people to create a separate queue for each process, but that is the obvious simple approach to take, and that is what many organizations put in place as part of “doing ITIL”.

Too little focus on value, outcomes, costs and risks

IT services are all about value, outcomes, costs and risks. If we help our customers get value by achieving the outcomes they want, and we help them do this with the right cost and level of risk, then we’ve done a good job.  This is something that should be clear to all of us, even if we're not familiar with the ITIL definition of a service as

A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.

Every ITIL Foundation course teaches this definition, but for some reason it doesn’t seem to have much influence on how IT staff behave when they adopt ITIL V3. I still see far too many organizations that focus on executing processes and achieving numbers they’ve defined in a service level agreement, regardless of the impact this has on their customers. I suspect that we would do a much better job with ITIL V3 training if, instead of going into all the detail of how processes and lifecycle stages work, we just taught people the ITIL definition of a service, and then helped them understand how they could make this real for their own organization.

ITIL Practitioner, published in 2016, started to address this issue. It has a very clear focus on value, outcomes, costs, and risks, but sadly very few people have studied this compared to the number who study ITIL Foundation.

Support for digital transformation

Much of the current ITIL content is based on work originally carried out 10 or more years ago. Organizations are now adopting digital technologies for things that were never dreamed of when ITIL V3 was being written, and the rate of change is increasing. To be of value, ITIL needs to help organizations transform, but too often it is seen as anchoring them to the past, rather than helping them to realize a new digital future.

Compatibility with agile, lean, devops and other management approaches

ITIL V3 is often seen as promoting a waterfall approach to development of new and changed IT services, but many organizations are moving away from this to a much more agile approach. ITIL V3 can work perfectly well in these environments, but organizations using V3 need to work a little harder to achieve a good fit. ITIL 4 has been updated so that it fits more naturally with the collaborative approach supported by DevOps, and with the improvement culture of Lean. It should work well in organizations that adopt them.

Summary and conclusion

There’s lots of really great guidance in ITIL V3, and many organizations have used this to help them deliver valuable IT services in an efficient and effective way. But it does have some weaknesses that need to be addressed to help it retain relevance in a rapidly changing technological and business environment. It needs to help organizations create a more collaborative culture that can eliminate process silos.  It needs to support modern ways of working, maintaining good processes but developing a much sharper focus on people, technology, and suppliers.

If your organisation has adopted ITIL V3 and found it works well for you, you don’t need to throw away what you have done, or make sudden and radical changes to how you manage IT. But you are probably already thinking of changes you need to make, because of evolution in your organisational culture, and in the environment where you operate. When ITIL 4 is published, I think you will find the updated version an excellent resource for helping your organisation think about the changes you need to make, and how best to make them.

 This work is licensed under CC BY-SA 4.0