If You Went On an ‘ITIL Journey’

Next Story

Idea through to Delivery - Part two

You Shouldn’t be Surprised if You Got Lost….

We’ve all heard the story (or a variation of it):
“In order to address growing complaints from customers our organization chartered a project to ‘implement ITIL ®’. We brought in experts to assist, we sent people to training, and over the course of x number of months our processes became operational.   We created definitions and critical success factors and key performance indicators just like the ITIL books say to. So why are there still so many incidents? Why do problems keep occurring? Why are changes still failing?”

There are no figures available to substantiate the number of times that scenarios similar to this have occurred over the twenty-five year period that ITIL has been available, so I believe that ‘many’ will have to suffice. As a fair number of articles have already taken aim at reasons to explain failed ITIL ‘implementations’, I will start by saying that I do not plan to bore you with a list of my own choices. My intent in this writing is rather to focus on just one possible reason that may contribute just a little, which actually traces back to the caretakers of ITIL.

If you look on the Axelos website, you will find case studies that liken adopting ITIL to a ‘journey’. Now when I hear the word ‘journey’ it brings to mind soul searching in Tibet, or some other individual existential voyage of discovery, an unstructured path that is meant to be wandered for an indefinite time. Getting lost is understood to be part of a journey – the part they make into movies.

But getting lost isn’t something you want to do during a business initiative. In truth, introducing any type of initiative that is dependent upon behavioral change – and ITIL is certainly one of these – is not a walk in the wilderness; rather, it is (in the case of ITIL) a full on program to alter the current practices of from tens to tens of thousands of people that support and deliver ITSM to your business and customers.

So as an alternative, I would offer that one should consider moving to ITIL with your organization more like relocating your family. To a new country that sounds very nice but which you are uncertain how to locate on a globe. Inhabited by a diverse set of local factions with ideals you don’t currently subscribe to, whose cuisine includes a lot of ingredients that are not part of your normal diet and make you a little queasy when you think about them. Where you don’t know the history or customs or laws or speak the native languages, and do not know anyone, or what the rules are for migrating there, or what form of transport can get you (and your stuff) there. In addition, you will need to find and obtain land and build a place to live. Oh – and half the family does not want to go.

I believe that this description is a bit more realistic in terms of imparting an understanding of the depth and breadth involved in this type of effort. It is not the kind of description that Marketing would recommend (see ‘journey’), but it is the kind that may help better prepare to not only to arrive at the destination intact, but to appreciate living there once you have.

On a journey, we are not really expected to be focused on our destination. Successfully relocating however requires us to be focused not only on our destination, but on all the aspects of continuing our lives there, including all our future aspirations.

So what really is the difference between a ‘journey’ and a successful ‘relocation’? Planning.

In my opinion, ‘plan’ is the most important (and least adhered to) step in the Shewhart-Deming attributed Plan-Do-Check-Act cycle – and is among the most difficult tasks humans undertake. Planning simply isn’t something most of us engage in regularly – most of the things we do we just do – and then wonder later how we forgot our wallet (usually after the cashier has scanned our intended purchases), or are at the airport without a passport, or why we ran out of fuel. Mainly though, I suspect it is because planning requires we simulate the possession of something typically only true in fiction: the ability to predict the future.

I say ‘simulate’ because no one I am aware of is actually endowed with this ability (though Warren Buffet may be). Most of us have to do planning the old fashioned way – by engaging in lots of research to form a kind of educated anticipation of the possible changes, challenges, opportunities etc., determining what effect each might have, and deciding ahead of time what we should do about them. It is time consuming, exhausting, even frustrating. It is mapping out every path, attraction, hazard, expense and travel method we expect to encounter or need. These are not things we do before starting a journey; we take a journey to discover things along the way – which can be a lot of fun in life, but is not typically a sound business methodology.

Often, when we get lost (sometimes even while on a ‘journey’), we feel the need to assign blame. Humans by nature want to assign blame when any type of expectation falls short; we can’t help it. When things do not go as expected, it is virtually impossible to resist saying (or at least thinking) that ‘it happened because of X’ (try it if you don’t believe me, next time you are faced with the situation). Many times it does not even matter if the reason something failed cannot actually be X – it only matters that we have a reason to point to.

When an organization does not realize desired results from ITIL, it is not unusual to see that blame placed with ITIL itself. In reality, blaming something like ITIL for this outcome is no different than cooking a meal following recipes found in Mastering the Art of French Cooking and blaming the book when the result does not taste like it did when you went to Alain Ducasse au Plaza Athénée. The book provides techniques and recipes – but you have to correctly plan the meal, source the ingredients, obtain those resources, have a properly outfitted kitchen, have time to do all the cooking, and have the skills to produce the results you are seeking. Absent all this, it might make you feel better to blame the book – but it won’t make your meal taste any better.

If you did lose your way during an ITIL journey, all is not lost. You just need to work your way from Do, Check or Act back to Plan, and invest the time and effort needed to determine the best way to relocate. Don’t misinterpret me here; I am not suggesting this will be simple – the time and effort required will relate directly to just how far off the path you strayed. But if you want to find your path again, it is the best – and often times only – way to do so.

Should you be considering what to do about ITIL, the path you take is of course up to you. If you want to explore ‘The Road Not Taken’, go on a journey. If you want to adopt and adapt ITIL for the benefit of your organization and customers, consider instead ‘relocating’ – and plan ahead…


The following two tabs change content below.

Michael Keeling

Michael has been providing consulting and guidance in IT Operations, ITSM and SIAM to enterprise level organizations in many industries for more than 20 years, and has extensive background in data center and service desk operations, technical writing, mentoring, cause analysis and workflow improvement. He is known for bringing the view of a detective to these efforts, perspective he credits to education in crime scene investigation and over 10 years designing processes and performing risk management in the private security sector prior to his career in IT. A confirmed realist that believes no project can be truly successful unless all involved parties are grounded in reality, Michael is always prepared to paint ‘the elephant in the room’ bright yellow when appropriate….