ITIL, the IT service management (ITSM) best practice framework, is now in many ways bigger than its “master” — IT service management. From its origins in the UK government, its use has grown rapidly in the last decade and ITIL continues to dominate corporate thinking in IT operations, IT support, and IT service delivery best practice.

There are many potential benefits from ITIL adoption, particularly around productivity, service quality, business reputation, and cost savings. However, ITIL is fraught with adoption challenges that could be prevented or at least minimized through better planning and execution.

The key ITIL adoption challenges and pitfalls (at a very, very high level)

• Focusing too much on the reactive elements of ITIL and ITSM (for some, however, this might be enough).
• Overstating ITIL and ITSM adoption levels – “We do ITIL.”
• Overstating ITIL and ITSM maturity – where IT infrastructure and operations (I&O) organizations often think that they are more advanced than they actually are – “We have a super-duper service catalog.”
• Not focusing on the customer and business outcomes.
• Lacking momentum post technology implementation project.
• Noticeable dissatisfaction with traditional service desk tools.

With people-related challenges to be found in most if not all of the above.

Want more detail on the challenges?

These are explored in greater detail in the Forrester report from which this high-level extract is taken:

• Planning Road Map: Adopting ITIL

It sounds like the start of a bad Christmas cracker joke. Maybe the title of this blog should actually be, “Why Should Buying An IT Service Management (ITSM) Tool Be Like Buying A Car?” but let’s see where this goes. I'll deliberately avoid talking about salespeople.

I sometimes talk about new application development in the context of acquiring a car: in that the business often says “we want a green car” to IT rather than saying “we want a means to get from A to B that is aesthetically pleasing.” What I realized responding to a Forrester client inquiry this morning is that the same is true in selecting an ITSM tool.

How should one buy a car?

Let’s look at ITSM tool selection in terms of needing a new means of transport/business support, as you might not actually need a car:

• Work out what you need it for (is the need for a car, tractor, plane, or pony?)
• Identify the features you need based on what you need to achieve rather than what is available (will you use 16 cup holders?)
• Identify what features you need/value most and don’t lose sight of them
• Work out what you can afford (this might impact the above)
• Speak to your “personal network” about their experiences with particular models and vendors
• Look at what is being said on the Internet (the social commentary)
• Consult aggregators of opinion and experiences (analysts and some consultants)
• Speak with existing customers (and not just the ones that the car sales person points you at)
• Ask for what you actually need
• Always, always have a test drive and kick the tires (that is a test drive by the people who will be driving the vehicle in their job rather than the people who watch them drive). Get a pilot implementation

Sorry but I’m “frustrated of Peterborough” (but not directly at IT for once).  Having just come off a half an hour call with two “major credit card provider” customer service staff, I’m frustrated to within an inch of screaming at someone. In some ways this blog is my outlet (but there is interesting stuff eventually).

You might think I'm overreacting, however, when one’s time is so limited these days, it is difficult to rise above the fact that I wasted 20 of the 30 minutes most likely because the “major credit card provider” has off-shored its customer support to save money (please note that the off-shoring is an assumption on my part based on my interactions).

But what has this to do with IT?

Hopefully you didn’t need to ask this question … I had an issue with a credit card service; many have issues with corporate IT services. We all call up, we all expect a quick resolution, and many expect to be treated in a customer, rather than supplier, focused manner.

Oddly enough, I spoke about this exact point at the itSMFUK London Regional yesterday … from an IT service management perspective (well specifically a service/help desk perspective). That we are now too focused on the mechanics of things (tool and process, AND scripts) and that, in some ways by virtue of this, we have “dumbed-down” the IT service desk.

This is not intended as an insult to service desk people, they have a difficult job: a job where they day in, day out, deal with the fallout from IT failures and the potentially unhappy customers. In an environment where there is very little “good news” or praise.

So what went/goes wrong?

Earlier this week, I attended the Hornbill User Group (or "HUG" as it is affectionately known) to listen to Malcolm Fry, IT service management (ITSM) legend and author of "ITIL Lite," talk about ITSM metrics in the context of ITIL 2011.

There is no doubt that metrics have long been a topic of interest, concern, and debate for ITSM practitioners (I wrote a piece a few years ago that is still the most popular item on my old blog site by a huge margin), and IMO I&O organizations struggle with the area due to a number of reasons:

• I&O is not entirely sure what it is doing (in terms of metrics) and why.
• We often measure what is easy to measure rather than what we should measure.
• I&O can easily fall into the trap of focusing on IT metrics rather than business-focused metrics.
• I&O organizations often have too many metrics as opposed to a select few (often led by the abundance of reports and metrics provided by the ITSM tool or tools of choice).
• There is no structure or context between metrics (these can be stuck in silos rather than being “end-to-end”).
• Metrics are commonly viewed as an output in their own right rather than as an input into business conversations about services or improvement activity.