For a few days now I have been
pondering what to write about for this new\my next blog. In this ever-changing
world there is actually remarkably little happening in the service management
space. I guess we’re all waiting to see what AXELOS will bring to the party
next year (or perhaps we're secretly plotting a defection to COBIT).
Mostly people are providing
(excellent) examples of how to actually apply the service management concepts,
or they are bashing the (perceived) rigidness of ITIL, especially compared to AGILE or
DEV-OPS. And in particular on that last topic, I have felt the need to ‘come to the rescue’ of ITIL to explain how its generic concepts apply, even in the
modern, fast-paced world of DEV-OPS.
At the core of ‘my’ argument is that
ITIL is a best practice, and my favorite definition of that is: “common sense... written down”. Now admittedly common sense isn't always common (and in
ITIL's case doesn't always immediately make sense either) and it definitely isn't written down.
The thought behind this is that we
need to move from ‘best-effort’ to ‘best-practice’. Best-efforts are
individuals doing their individual best. In itself nothing wrong with it, but individuals
are just that, and best-effort often means that different people are dealing
with the same issues in a different way. The end result of that is a differing
experience (for the customer) and something that is not repeatable, consistent
or guaranteed.
Those last two words (repeatable
& guaranteed) are key in delivering a service. Customers want to be able to
rely on the value provided, which is why we negotiate SLAs etc. and try to
provide measurable targets. After all: You
cannot manage, what you cannot measure.
But in extension: You cannot measure what you cannot define!
And this is one of ITIL's greatest
strength, it defines processes and concepts (like Incidents, Problems, Events,
Changes, CIs, SLAs, …) within the IT service provider, allowing them to become
measurable and manageable.
So, defining something allows you to
make it (more) manageable, and then writing it down allows you to share it with
others, making it repeatable & consistent.
I think most people understand the benefit of ITIL here: the one language, the structure and definition of the
processes are all very helpful in building a more effective and efficient
service organisation.
However, the writing down bit is
where things often go wrong with ITIL. It manifests itself as procedures,
flow-charts, RACI-matrices, forms and that often becomes bureaucracy.
Now, I've lamented before that we
need a level of documentation (a pilot landing a plane without a checklist is
.. scary) and that ITIL actually doesn't specify how big procedures need to be
(80 pages, 8 pages, 8 paragraphs or 8 words). In this context I've referred to
size, risk and complexity are factors that determine the amount of
documentation that is applicable.
I guess we all agree that ITIL needs
to be adopted, based on your organisation and objectives. As much as we look
for a prescriptive silver bullet, this was never what ITIL was intended to be.
It has always been positioned as guidance to help you.
In determining HOW to adopt ITIL, it
is important not just to understand WHAT ITIL is defining as best practice, but
-more importantly- WHY ITIL thinks
this should be done.
And I believe that a lot of the
detractors of ITIL are focusing on the WHAT (and sometimes on very specific
phrases in the publications) and not on the WHY.
So, take DEV-OPS. Change Management
is all about (the WHY) delivering new\better value to the business and
minimising impact (of not changing or badly changing). DEV-OPS (or AGILE), in
my opinion, is not different to that, it is just focusing on rapidly changing.
Traditional ITIL may perhaps focus on preventing all (or at least most) errors
(through assessment, CABs, testing, ELS, …) but that is just an interpretation.
There is nothing wrong with making a
‘fast change’ (emergency change would be the defined concept) is that provides
a better value to the business.
And now we’re getting closer to the
title and thus the message of this blog. I believe that almost everything we do
in life is based on a risk-reward judgement: is it worth the risk (of failure)
to obtain the reward?
Often we try to make this
measurable, and then again often in financial terms (ROI, TCO). But in essence
this can be a very subjective, individual judgement.
And we don’t like individual
actions\decisions in the service management world, or at least we’re trying to
make sure that different people make the same decisions, and preferably the
right one (although who is to judge which decision was right in the end).
To me, this is a key principle
behind ITIL: it is not a silver bullet, a straight-jacket of procedures to be
followed, a regimented framework which will avoid errors at all costs (through
design, transition and operation). But it is a framework that allows an
organisation to collect better information (measurements) which will lead
individuals to make better (, more consistent, repeatable) decisions through
which to deliver more value to the customer.
Now, no-one is perfect, and I don’t
think ITIL (processes or rather their documentation) should be something that
an individual should hide behind, afraid to make a decision.
After all a process never covers all
eventualities and if people follow process-for-process-sake it’s the equivalent
of announcing that the operations is a success, but the patient died (but look
at the stitching … beautiful, consistent, text-book)!
With service management, we also
need to create a culture of people understanding the WHY and giving them the
ability, confidence and security to make decisions.
Even if those decisions are wrong. I
often say that I don’t mind people making mistakes, as long as they were
deliberate mistakes!
Deliberate mistakes you can learn
from, and the next time you will change your frame of reference, and make a
better decision. ‘Random’ mistakes however have no inherent learning built in,
and there is no guarantee the results will be better (or worse) next time.
Most of this is based on an anecdote
of IBM CEO Tom Watson. There are various versions of this, differentiating in
time, people\departments involved and the amount at risk, but this version
explains the message quite well.
Trust your people, and use ITIL as a
tool (, framework, guidance) for them to structure their work better, and to
provide them with better information, to make better decisions and deliver
better value.
the ITIL Zealot
September 2013
September 2013
