The Four Big Questions ITIL Doesn't Answer

There are still many people who are under the illusion that ITIL provides a prescription or plan for implementing IT service management (ITSM). It doesn’t. In fact, the more important the decision you need to address, the less likely there is guidance for it.

When we want to know how to, say, measure a service desk, we can find quite exact guidance from several sources including ITIL. But the depth and usefulness of advice is inversely proportional to the importance of the question. Consider the most important decisions you need to take as you embark on an ITIL initiative, the Big Questions. In this article, we will look at the most important four.

The first and biggest decision of all is whether you should even do ITIL. What are the gating criteria specific to ITIL? What special factors should we look out for? Surely, ITIL defines them? No.

Or look at the next most important Big Question: how far should we go?

To answer this, the standard consulting approach used in ITIL is to determine the current "as-is" state through assessment, then decide the "to-be" state, and then work on the gap. ITIL v3 still fails to provide an as-is assessment model, though COBIT does. So too do many consulting firms. So, we can find the as-is readily enough, especially if we pay for it. But what about the other half? How do we pick the target "to-be" state?

Very often the as-is and to-be are defined as some composite capability maturity model (CMM) level from 1 to 5 (Actually, 0 to 5. I've met zeroes.). A consultant will give you the as-is to two decimal places, but how do we determine the to-be? The standard model is to extract a number from a suitable orifice. If you're a basket case you'll go for Level 2. If you are mainstream you'll shoot for a 3. If you want to swagger you'll aim for 4. And if you want to use the result in marketing your company's services you'll find a consulting firm that will certify you as a 5.

This is not exactly scientific or rigorous, and there is no process other than a brief gaze at the navel. Why do we have whole books of guidance from multiple sources on lesser issues but when it comes to setting the broad scope, the ambition (and of course the cost) of the initiative, we allow someone to pick a number? On what basis? With what advice and guidance? Reached through what reasoning and methodology? None. Not in ITIL v3 anyway. Nor in COBIT.

The Journey Begins

So, we pull some numbers out of … umm …. the air, and we embark on the ITIL journey. We look at ITIL v3 and it is huge. Even ITIL v2 towers above us as we look at all 10 or 11 or 13 processes. Surely, we won’t try to do it all at once?

Advice exists that says pick the processes off one or two at a time but this is patently rubbish. Processes are intertwined and interdependent. We need to go into a number of processes at once, in a phased manner. Many times there is a crying need for a bit of all of them. Now if ITIL v2 was a line of processes, v3 is a plane. It has the extra dimension of the lifecycle of the services. And we certainly are not going to attempt that entire dimension at once. Nor are we going to do each of the five ITIL v3 books (which map that dimension) one by one. They are just as intertwined. So, we need to implement pieces from all five, at the same time, in a phased manner.

Which brings us to Big Question Three: how to determine what goes in each phase? How to measure whether a phase is done? How to get from one phase to the next? How to project manage the implementation of ITIL? Surely, ITIL gives some guidance on that? Well it does, a bit; accidentally. It describes how to implement services, so there is some guidance there that can be applied to implementing anything. But directly about how to implement the ITIL systems to run the lifecycle to implement those services, it provides nothing. Nada. Bupkis.