ITIL is version-less and timeless

I realise I am almost a year behind the times here, but I have to give the Cabinet Office (, OGC, APMG?) credit for removing the version number of ITIL. No more ITIL v3, but plain ITIL; or ITIL (2011) if you want to be pedantic.

When in 2007 ITIL v3 was released, or perhaps even earlier when the name was made public, automatically the previous version became v2 and the original one v1. This then became the topic of many a debate about what was wrong with version 2 and whether organisation needed to ‘upgrade’.

I actually wrote a white paper in those days comparing ITIL v3 with Windows Vista (remember, this was early 2007). Vista had sparked similar debate where people admired some of the new functionality and visuals (mainly aero) but were unconvinced about the need to upgrade from Windows XP. To a large degree the same discussion can still be had about Windows 7 and Window XP (and with Windows 8 just around the corner get ready to revisit this discussion once more).

I’ll digress slightly here by going off-topic and tackling the issue of justifying a change (sure to be a topic for future blogs as well). One of my favourite ways of stirring up people is to say there is no such thing as an IT project! There are projects with IT deliverables, but ultimately a project should be done for a business reason\benefit. Thus the business case for Windows (8, 7, Vista, …) should not be about niceties, but about utility and\or warranty improvements. The moment Microsoft stops providing support for a product, is when the case for upgrading can be made, not before (unless the new version offers additional and needed functionality). With this in mind now try to write a business case for an iPhone!

Anyway, back on the topic of the debate of ITIL v3 and v2. To a degree I myself partook in these discussions. As a self-confessed ITIL-dinosaur and conservative I believed that the new ITIL version 3 was nothing more than v2 in a shiny coat and didn't add any real value. I have to admit the error of my ways and over the years have found appreciation for the lifecycle ordering, the process ‘refinement’ and the Strategy ‘add-on’ (I guess all of them worthy of a blog at some stage).

I concluded in my white paper that unlike Windows, ITIL is not a product that gets installed or upgraded, but instead it is a framework of structured activities (processes).  And these activities are generic or perhaps common sense (I now, common sense isn’t always common … and doesn’t always make sense either! Hence the need for frameworks to help us follow common sense). The fact that ITIL v3 had added new activities (mainly Strategy) or had moved them around (‘old’ v2 incident management split over new v3 incident, request and access management) did not invalidate the ‘common sense’ activities but provided merely a new way of structuring these same activities (i.e. in the Lifecycle).

So when last year the rumours of v3.1 (let alone v4) surfaced I was bracing myself of a repeat performance of these discussions. Never mind the commercial mistrust where many believed ITIL v3 was just there to increase book sales and training opportunities. Therefor I was more than pleasantly surprised when not only there was no training upgrade required, AND the updates were logically and improved or enhanced the existing theory but that ITIL had dropped the v3 moniker and had gone back to being ‘just ITIL’, the best practice framework for IT service management (another return after a short dalliance with good practice).

Of course PRINCE2 has applied this way of version numbering for a long time. After the initial 'upgrade’ from PRINCE to PRINCE2 in 1996, several subsequent versions have followed in 2002, 2006 and 2009 without making it PRINCE3 or PRINCE2.1. The new version comes out and 6 months later all publications and training of the old version is gone and PRINCE2 (and now ITIL too) remains THE framework it always was (and will be).

We ‘experts’ are often positioning ourselves as critics, with better or improved interpretation, application or communication of the theory, but I think it is important to recognise the goods things too. And ITIL (2011) is such a good thing, a common sense improvement on a common sense framework. Makes sense really!

the ITIL Zealot

ITIL and BUREAUCRACY are NOT synonyms

I have to say that I am quite pleased with the segways I have been managing with these blogs (although secretly this is the reason why it took me several years to write these as I have been perfecting them all this time). So, whilst ITIL is a religion, it is a long and winding road to service management (blog 1), which requires you as much understanding of the WHY as the WHAT, in order to create your personal HOW (blog 2). My example was to show how different projects need different business cases, sometimes not even put on paper at all.

This is almost diametrically opposed to the perception of some people that ITIL introduces a major amount of bureaucracy in the form of procedures, work instructions, logs, forms and other paperwork. And whilst this it true to some degree, there is a very good reason for this, and this reason is what I call my first mantra of ITIL (or perhaps the first commandment to stick with the religion analogy):

YOU CANNOT MANAGE WHAT YOU CANNOT MEASURE!

Not being able to measure is basically what ‘best effort’ is. Individuals doing their best, in whatever way they individually think it should be done. The end result is, for instance, 3 people on the service desk who each use their own way to answer the phone, ask questions, record details, hand these to 2^nd level support, follow-up and report to management (i.e. incident management). The result is that even though each of the 3 individuals may do a good job (best effort), the overall result is a bit up-and-down and inconsistent. The introduction of ‘best practice’ (like ITIL) makes all 3 individuals act the same, by following a predefined, accepted way of doing things; and to manage this we need measurements (to compare against baselines, service levels, KPIs, performance targets etc.).

The clincher is though that ITIL never dictates how big or how formal your procedures need to be or even whether you need to document any of this (for instance for those 3 service desk operators). This is where I normally borrow from PRINCE2 which describes the need for tailoring (note not choice, but need!) and this tailoring is based on the size, risk and complexity of the project\organisation. The bigger the organisation, the more complex the organisation (various suppliers, geographical locations, …) and\or the more risky the activity (support for the intensive care in a hospital, nuclear power plant, …); the more, formal documentation you will need.

Thus it is your job (having been converted to ITIL, and understanding both the WHAT and the WHY) to determine HOW much documentation you need in order for you to deliver the best services to your customer (I may get back on the repeatability of ITIL process at some stage). This of course may lead to bureaucracy, but a necessary one.

Imagine this: you’re in an airplane and on the speaker comes the captain saying that they have started the descent into the airport of your destination. He\she continues to says that it a special day as it is his\her 1000^th landing here and that to celebrate he\she has a really cool, new way of landing the plane! Probably not something you want to hear as a user\customer in row 23C. You want to hear the pilot say that he\she has a procedure that he\she has followed 999 times before and can do blindfolded, backwards, with one hand tied behind their back, in Russian. But the pilot promises to do this procedure step-be-step and then the co-pilot will check (i.e. audit) that every step has been completed, as that provides the best, repeatable, guaranteed, measured value to you (as the customer in 23C).

And this is the role of IT in the business these days, we can no longer ... (wait for it …) wing it anymore (pause for canned laughter) but have to provide repeatable, guaranteed services and the use of best practice\procedures, if necessary through the use of documentation. And ITIL is that best practice and thus requires a certain, adequate amount of documentation, without becoming bureaucracy.

I’ll leave with one more analogy: if ITIL is perceived as bureaucracy and bureaucracy is meant to slow you down (a often heard complaint), it can therefor be compared to the brake in a car (which slows you down). But would you drive a 100kmph+ on a freeway without a break … and how would you change direction?

The role of ITIL (and its documentation) is to control your speed and to allow the organisation to change direction in a managed, controlled way.

the ITIL Zealot

May 2012