The sport of ITIL bashing has been increasing in popularity since the 2011 revision was released. Developers have used the DevOps and Agile scythes to hack at the much-maligned Change Advisory Board (CAB). ITSM Tool vendors have made frankly ludicrous claims of “ITIL in 30 days” with the poor defenceless framework getting the blame for the inevitable failure. Many have bemoaned tick box exams for producing “ITIL Experts” who have no real world experience that shows in solutions they implement. ITIL’s popularity and ubiquitous nature have in many ways led to it becoming a hygiene factor…something that just needs to chug along after initial adoption of a few key processes. Is it still relevant? As a framework, absolutely it is.
As an ITIL devotee of many years it might shock you to learn that there are some parts of the current guidance that I believe are best consigned to Room 101 (the chapter on Supplier Management in Service Design is woefully inadequate)! However, there are elements of the guidance that I believe should be retained and form the cornerstone of your progression into Agile, DevOps, SIAM or even the Enterprise Service Management space. I am not saying that ITIL offers the absolute best academic explanation of these areas or that new skills and frameworks should be ignored. I do advocate using ITSM retained knowledge and exploiting its familiarity to make any digital transformation way easier to stomach for staff who have previously suckled on ITIL’s teat.
These are some areas where elements of ITIL that should have been blended with other best practices years ago! Adopt and adapt anyone?
- Value Proposition – From V3 onwards, ITIL became almost pathological in its pursuit of value extracted from services. Utility and Warranty, the customer defining value, understanding the relative value of services were all keys to the foundation that good service provision and resource allocation was built upon. It is no surprise then that DevOps adoption starts by looking at value stream mapping. ITIL tried to tell us; the Service Portfolio – good idea if integrated with its project cousin from development. Change Evaluation – a great idea but should never have been called out as a process but embedded elsewhere. Had Change Management been given a more strategic role in defining value of particular change cadences and approaches rather than just obsessing in CAB meetings things could have been very different. But ITIL never said don’t do any of that…it gave us the building blocks we just didn’t always put them together correctly.
- Constraints – The theory of constraints can trace its roots right the way back to 1963 in a magnificently named management theory (Machtorientierte Führungstheorie). You have to hand it to the Germans. Nobody does long words quite like them! M.Goldratt later coined the term ‘theory of constraints’ in the 1984 book, The Goal. Goldratt theorises that “The underlying premise of the theory of constraints is that organizations can be controlled by variations on three measures: throughput, operational expense, and inventory”. ITIL gave us an adaptation. Design by constraints in one of the most powerful diagrams in the V3 literature (the pick-up sticks diagram from the 2006 vintage)
ITIL® diagram is reproduced under license from AXELOS
The usefulness of this diagram is truly underestimated when designing services in conjunction with our enterprise architecture colleagues. The premise it works on is that “I’m far more likely to get my design right if you tell me the shape of the canvas first”. Constraints define the shape of the canvas or solution space. The key is understanding each constraint, why it is there and the result of relaxing or tightening it. Of course, having that common understanding of constraints right through our organisation, documenting them and reviewing them is essential. In a drive for digital transformation and automation this activity is now mission critical.
- Continuous Integration, Continuous Delivery (CI/CD) – Continuous integration (CI) is a process in which developers and testers collaboratively validate new code. Continuous delivery (CD) is the process of continuously creating releasable artefacts. Some companies release to users once or even multiple times a day, while others release the software at a slower pace for market reasons. Genuinely, ITIL best practices such as standard changes, release policies, designing in monitoring and configuration management should have their mark stamped all over the tools you use to automate CI/CD. The logic, governance and cadence you program into the tool chain has to come from somewhere. It just so happens that the ITIL best practices have already given you a tremendous head start that everybody understands and recognises without a CAB in sight!!
- Repeat Failures – Nothing is as damaging to the reputation of an organization as repeat failures. When it happens in the digital arena, the focus is sharp and the impact immediate. I believe failure is instructive. An organization that succeeds in the long term is one that learns as much from its failures as from its successes. When adoption of ITIL’s problem management techniques and processes gets beyond the single-minded pursuit of ‘root cause’ then it genuinely can be an absolute powerhouse in delivering added value and become a hub of organisational learning and improvement.
- Continual Service Improvement (CSI) – If we’ve done one thing wrong with ITIL over the years it has been our hedonistic pursuit of ITIL compliance over business benefit as a focus for CSI. I remember legendary ITIL author Vernon Lloyd once explaining to me the difference between ‘continual’ and ‘continuous’ in relation to service improvement. During our discussion we found much common ground with the argument that just because an improvement in maturity is possible doesn’t always mean that it is valuable. The ITIL CSI advice goes someway to addressing this. Latterly released by Axelos, the ITIL Practitioner guidance goes the extra mile by introducing more external thinking. It is a solid, highly pragmatic framework for adopting more Agile and Lean principles into your service management practices and the way we deploy them. I’d advise everybody to study and adopt it.
In conclusion, those that tell us that ITIL is dead are maybe missing a point. They have let certain superficial features where the advice is beginning to show its age disguise the fact that the bulk of the body is healthy. Maybe the CAB is ITIL’s equivalent of a few grey hairs? I believe many of the solid practices enshrined in ITIL give us the base to consider further collaboration, automation and innovation. After all, it is only after understanding your current ecosystem that you can disrupt it. If you succeed in disrupting something you don’t understand then you are more likely to have been lucky than blessed with insight.
If you pick and choose; adopt and adapt then swathes of ITIL are common sense that will never go out of fashion.
I’d love to hear from more of you about the parts of ITIL that are still adding value in the digital age.
The ITIL® certification structure now comprises foundation, intermediate and complementary courses leading to the award of ITIL® Expert. Visit our website for more information.