ITIL is certainly based on sound
principles, and – properly embraced and adopted – can bring real value to an IT
function and hence to the business it supports. Having said that, I do wonder
if we might have lost the plot a little bit…
I draw a parallel with Prince2,
the similarly accepted default project management standard. Developed primarily
as a tool with which to run large public sector projects, it occupies the kind
of standing to which ITIL is now close. The problem with it, though, is that at
a fundamental level it doesn’t work; it guarantees nothing. If Prince2 did
exactly what it said on the tin, then why do so many projects adopting it still
fail – and massive value public sector projects in the UK continue to do so
spectacularly?
Looking at ITIL (and keeping
Prince2 in mind), there are some obvious concerns about where we are with it today.
It’s
getting more complex. ITIL started as a number of volumes (the
‘library’ in its title). The move from Version 2 to Version 3 has seen a
significant increase in the numbers of books in the library, and an increase in
the numbers of processes and procedures proposed by it. Proponents may argue
that this is necessary to reflect the current IT world, to ensure better
services etc. They may be right. They may not.
Has
it become an intellectual exercise in its own right? This explosion
of breadth and depth within ITIL could potentially be seen as becoming an
intellectual exercise in its own right. ITIL has now an industry of its own.
One can imagine the clamour to be part of ITIL v4 (should there be such a
thing) where the numbers of volumes expands once again, the qualifications
burgeon, the specialist consultants multiply…
An
excuse, not a tool? Adopting ITIL guarantees nothing. Just like
Prince2. Are we embracing ITIL more as an excuse than a tool? Does it allow us
the opportunity to actually not think about the situations we face on the
premise that ITIL will fix it? And if it’s not quite there, do we go further in
our over-engineering to pursue an idealised vision of a ‘real world’ where
simply nothing goes wrong? There are no silver bullets.
I think ITIL – or at least the
principles behind it, rather than the ‘thing’ itself – offers true value.
Indeed, adopting some of the underlying principles are essential in providing
solid IT services. But have we lost our way in that the adoption of ITIL becomes
the end in itself, rather than the true outcomes for which we strive – and for
which ITIL may not be the best tool, or the only tool, or indeed the right
tool. Are we asking ourselves the right questions? Maybe ITIL has some kind of
shelf life – like an old movie actor known by everyone, yet everyone also knows
they are past their sell-by date.
Heretical stuff.
I recently saw a job advertised
where there was non-negotiable application criteria that demanded an ITIL
qualification. Adoption of such a crude instrument could actually lead to
the preferential recruitment of people with specific pieces of paper
(qualifications) over those who have the real scars of battle in providing good
quality IT services. What would you rather have, a soldier who had a diploma in
rifle shooting, or the best marksman in the world minus the diploma?!
At the very least we owe it to
ourselves to take a step back from our ITIL programme, processes, initiatives
and metrics, and ask ourselves some fundamental questions.
·
What is important in IT in relation to our
business context?
o
What do our customers actually care about – and
what don’t they? You aren’t a Bank, so do you need security like Fort Knox?!
§
Do we really
know what is important and fundamental to our Users? We need to ignore all
‘received wisdom’ on this one and just ask them. Make the questions as binary
as possible.
§
Are there things we spend time and focus on
which they don’t want, need, read etc. – because if there are, then maybe we
should stop them. Our service proposition could get simpler!
§
What components of ITIL (and associated
elements) currently in place could they actually live without?
o
What elements of IT for which we are responsible
cause our customers pain and aggravation?
§
Again, do we really know? We may assume that we
are failing them in some areas because our metrics tell us so – but they may
not care.
§
Ask them what they would change if they had the
chance – I guarantee that a significant proportion of what they suggest will be
basic, non-ITIL, service fundamentals e.g. make it easier for me to get a new
PC..!
·
What problems are we actually trying to solve? Do
we know? We may think we do…
o
The output from asking the business about what
is important to them will help – and any pain survey conducted certainly will!
This should give us a starting list of what
really matters.
o
What ‘internal’ IT problems are we trying to
fix?
§
These should be easier to identify, right. After
all, they’re right under our nose…
§
We should know where we take too long, where
quality is poor, where performance (in all its guises!) is inadequate, and so
on. The important thing here is not to start with an ITIL manual or list
of ITIL processes, otherwise you’ll end up with a list predicated on ”Oh, we
haven’t got one of those / aren’t doing that”.
o
Articulate the problems we are trying to solve –
both business and IT – in simple language,
and identify what will look different after we’re solved it.
·
What are the truly essential ITIL service
components from an IT perspective?
o
What would happen if we stopped doing ‘X’?
§
This is tricky too. This is also where we need
to be ruthless. But the bottom line is that by stopping doing one thing we
might just free up our resources to fix something much more important.
§
For example, we ‘do’ Knowledge Management to a
‘level 2’ competency and our instinct tells us we need to get to level 3. But
what if we stopped doing it altogether? What would we lose? And what would we
save / free up?
o
What do we really need to do that we aren’t?
§
This is about core, bread-and-butter ITIL
processes. Like Change Management. Not doing it? Shame on you! One you can’t
live without, I’d suggest. But even then, even if you are doing it, is your
approach appropriate to your need? Are you gilding the lily for the sake of it?
What does ‘good enough’ look like – do you know?
Questions, questions, questions.
But without questions, we don’t get to answers.
And here’s the rub. I suspect
that, if we undertake such a review, if we strive to find out what is really
important in the context of our ITIL-related, service provision processes, what
we will actually find is that we need less ITIL than we thought – fewer
processes / less complex ones – and more bread-and-butter management. We will
expose weaknesses that cannot be addressed by adopting ITIL or for which ITIL
has no solution. We will learn how to become that expert marksman, and use the
diploma for target practice!
Whither ITIL? Well it’s going
nowhere fast – and probably neither should it. But we should perhaps consider
putting it back in its box and re-teach ourselves to recognise what we truly
need to get done.
-*-
About the author / copyright
Ian Gouge is widely experienced in business-driven
Information Technology, culminating in significant achievements majoring on
organisational and process change, and with a proven track record in turning
around / re-engineering IT functions. He possesses in-depth experience of
change, transformation, IT delivery, customer and supplier engagement, and
broad International exposure. Also the author of management books on the topics
of IT Strategy and Project Management, the impact on IT of e-Business, and the
IT Organisation.
This material is copyright of Ian Gouge © 2012. All rights
reserved. Any similarity to actual IT or business organisations is entirely
coincidental and unintentional.
Any redistribution or reproduction of part or all of the
contents in any form is prohibited other than the following:
·
you may print or download to a local hard disk
extracts for your personal and non-commercial use only;
·
you may copy the content to individual third
parties for their personal and non-commercial use, but only if you acknowledge the
author and blog as the source of the material.
You may not, except with express written permission from the
author, distribute or commercially exploit the content. Nor may you transmit it
or store it in any other website or other form of electronic retrieval system.
No comments:
Post a Comment