When I ask people whether they use the Information Technology Infrastructure Library
(ITIL), there seems to be a polarized view – some love it, think it’s saved them from
unnecessary pain, and support it; some run a mile, telling tales of fear, uncertainty and
misery.

How can a collection of things that seem to be such a good idea polarize users
to that extent? I think it’s all about the implementation.

ITIL claims to be the most widely accepted approach to IT Service Management in the
world, and has risen above other standards like ASPL and COBIT because of it’s nonproprietary,
comprehensive and process driven approach. The financial industry was an
early adopter; it started in Europe and is now conquering the world.

IITL focuses on four main objectives:

• An increase in the customer focus of IT organisations
• An increase in the quality of the IT services
• Reduction in overall IT Service Costs
• Improvement in process thinking in the IT organisation.

It does this through the definition of a common service management language and
standardized processes. Here’s the rub: ITIL doesn’t say ‘how’ to implement ITIL, and I
think that’s the root cause of the differing opinions.

ITIL divides the support organization into two big sections – Service Support and
Service Delivery, and a bunch of sub-functions and an irreverent summary of them
could be:

• Service Support - typically the management functions to keep day to day operations
running smoothly – has within it:

• Incident Management – think of them as the paramedics – they get the patient on
the stretcher, stand clear - all working again, service restored, hurrah,
chuck the patient to the Problem Managers and be done with it. With a focus of
service recovery they are not bogged down by the need to find root cause.
Mostly likely to be heard saying ‘Just reboot it’.

• Problem Management – the forensic department whose goal is to find out what
went wrong, make it all better and stop it from happening again. Problem
Management can get to dislike Incident Management as Incident Management
can trample all over and contaminate the scene of crime. Likely to say ‘We could
tell what happened if they hadn’t rebooted it’.

• Change Management – the troublemakers. Without change managers changing
things we know most of the problems the Incident Managers have to recover and
the Problem Managers have to investigate would not have happened. Everyone
dislikes the Change Managers unless they are Very Good. Likely to say ‘Calm
Down Dear… It’ll be OK, I had it tested’.

• Release Management – if the Change Managers are disliked, the Release
Managers are several times worse – they get to change lots of things at the
same time in large bundles. Need to replace every laptop in your organization to
run Vista? Bring in the Release Managers. ‘Trust me, I’m a Release Manager’.

• Configuration Management – every organization needs trainspotters and these
are they – happy when everything has an asset tag, and never happier than
when tending their Configuration Items in their Configuration Management
DataBase. A piece of software has a new security bug? You can ask the CMDB
for a list of everywhere that it’s running that piece of software, and then pass the
list to the Change Managers to fix.

• Service Desk – the acceptable face of the IT department – people you phone and
mail when it’s all gone horribly wrong. Their job is to ignore and frustrate you
unless you are Very Persuasive. Buying them chocolate can often help.
On the other hand, sitting in shiny offices with dark shades on in a darkened room are
the Service Delivery staff:

• Service Level Management – the lawyers of the IT department – if you want a
agreed recovery time for your service you speak to them – they’ll draft Service
Level Agreements and Operational Level Agreements, negotiate underpinning
contracts with suppliers and maintain and improve IT business service quality. Or
they’ll make a pig fat by weighing it. ‘You want how much uptime!’

• Financial Management – You want another server, another building, to write off
deprecated equipment, a calculation of Net Book Value, and an understanding of
absorbed and unabsorbed costs – they are your pals in integer mathematics.
‘How many beans would you like to make five?’

• Availability Management – your friends in floating point mathematics – statistics,
graphs, charts, Service Outage Analysis, Fault Tree analysis, Component Failure
Impact Analysis, they are there to spot trends to save you from sleepwalking into
unavailability through predictable failures. ‘I’m telling you, that thing needs
replacing, now…’

• Capacity Management – crystal ball specialists to save you from sleepwalking
into unavailability through bad sizing. How much is your data/network/processing
growing each month – when will it all come crumbling around you? Someone in
IT needs to know the company business strategy and plan accordingly. ‘You
want it to do what?’

• Continuity Management – wizards and warlocks - when badness occurs how do
you get your production up and running again? They have cunning plans and
clever tricks, and regular tests to maximize the chances of your business
continuing even if a Very Bad thing has affected your IT department. ‘We’re
testing our business continuity, please report for work at this bunker tomorrow…’

IMPLEMENTING ITIL

The way to eat an elephant is, of course, one mouthful at a time (apparently, I have not
personally eaten an elephant, but you know what I mean). There is no one way to
implement ITIL – it just says ‘you should have this function’, now you, using your vast
experience of the IT industry have to go and do it.

There are broadly three ways to implement ITIL;

• One process at a time (could be a job for life followed by the presentation of a
carriage clock and retirement to a little cottage in the country)

• Clustered implementation of inter-related processes (for instance Service Desk,
Incident Management and Problem Management first, with other management
structures following later seems to be a popular strategy)

• All at the same time (a recipe for overwhelming a support organization, or
causing elephant induced indigestion and the aforementioned disgruntlement).

IT Service Management of course needs to consider the people aspect of the inner
workings of the IT organization – in the long term no-one changes their behavior unless
there are considerations for the performance system (this is not the ‘management
performance system’, that lovely thing that tips numbers into our bank accounts
periodically, defines vacation policies and if we’re lucky showers us with employee
discounts, I’m talking about the performance system that we work inside, whether we
acknowledge it’s existence or not – it’s the thing that drives us do wrong things even if
we know it’s the wrong thing to do - if it’s not implemented properly).

During the implementation the ‘how’ also needs to be worked out. This is both a
strength and a weakness – a strength in that you can implement ITIL to suit your own
environment, and a weakness in that two ITIL compliant organizations may not easily
be able to talk to each other if they’ve implemented ITIL defined functions completely
differently.

If there are Problem and Incident Management functions they both need an effective
Situation Appraisal and Root Cause Problem Analysis method defined and implemented.
ITIL doesn’t say how to do these functions; it just says that you should. ITIL helps
intercommunication by defining terms; “incident”, “service request” and “escalation”. By
extending ITIL’s defining terms and selecting the same method of Problem Analysis as
many other ITIL compliant organizations you can create advantages for yourself and
your customers that are bigger than the sum of the parts.

ITIL – HOW IT SUPPORTS THE IT SERVICE INDUSTRY

Given that ITIL was originally forged when British government determined that the level
of IT service quality provided to them was not sufficient, and has been developed over a
number of iterations, the thinking is proven and refined.

By ITIL keeping vendor neutral, it has given organizations the flexibility to implement
ITIL where they see the best benefit for themselves, which in turn starts with a clear set
of improvement objectives.

By providing a comprehensive set of best practices and consistent definitions of key IT
terminology and processes across the industry, it is being taken up by an increasing
number of large support organizations – and the probability of it becoming a global
standard increases every day.

Reproduced by kind permission of White Kepner-Tregoe Inc
http://www.kepner-tregoe.com/pdfs/KTPDFs/ITIL2007.pdf