Bureaucracy
is one of the greatest threats to the ‘application’ of ITIL. Actually there are
many things wrong with even using the word ‘application’, but one of the common
mistakes I see people & organisations make is throwing themselves into
writing process manuals (, procedures, work instructions …) and ending up in a
world of documents that hardly anyone uses (or even knows of).
First
of all never forget that this paperwork only comprises ONE of the four Ps,
namely the PROCESS one. You cannot forget the other: PEOPLE, PRODUCT &
PARTNERS, which together make up a Service Management organisation. I often
remonstrate that out of these the people-aspect is the hardest one to establish
and this most certainly will not happen through the creation of documents
(alone).
Yet,
having said that: ITIL excels in describing processes and expects (and in some
cases demands) that these processes are formalised in order to provide agreed,
uniform, guaranteed and repeatable outcomes. Note however that nowhere in the
ITIL publications it mandates a particular level of details or volume of this
documentation. I always borrow from PRINCE2 which describes tailoring as a requirement and states
that it is not about deciding WHETHER to use the best practice guidance, but
rather HOW to implement this. And further it identifies that this
implementation (roughly translated it means the amount of rigour and
documentation required) is based on the SIZE, RISK & COMPLEXITY of an
organisation.
Thus
ITIL is introducing a level of documentation (one could say bureaucracy), but
PEOPLE need to understand the need for this. You would not want your pilot to
announce that he\she has found a new way of landing the plane, but rather that
he\she is following a tried-and-tested procedure (with the co-pilot auditing
this) to provide the best possible outcome\value to you as a passenger.
In
this article I will provide two ways of quickly establishing procedures and
work instructions. PS: I will be using the terms process manual, procedure,
work instruction and documentation without prejudice. I do have certain
thoughts on this, but the theory seems to be somewhat ambiguous on this topic
(in particular across various frameworks). It does make sense in your
organisation to develop succinct definitions for each to make sure people
understand which is which.
My
first suggestion is a top-down approach based on a RACI matrix. Personally I think RACI matrices are the best things
since sliced-bread as they show in one matrix, diagram, page, view … both the
activities (of a process) and who is doing them (, involved in them,
informed about them etc.).
So:
start with the ITIL process activities. These should easy enough distilled from
the theory, where each process is described in a number of steps\activities.
Next put your staff (or teams) on the other axis of the matrix and determine
who is R(esponsible), A(ccountable), C(onsulted or participating) and I(nformed) for/about the activities.
For
writing the work instruction, focus on the RESPONSIBLE parties only. They are
the ones performing the activity and thus in the best position of creating the
documentation. If there is only one person\team responsible this can remain
relatively ‘light’, but if there is more than one party involved not only do
they need to agree on the procedure of HOW to perform the activity but also on
how to transfer responsibility between the groups (for instance functional
escalation in Incident Management between 1st, 2nd and 3rd
level support on ‘investigation & diagnosis’). You would expect more rigour
and thus more detail in these work instructions.
Finally
the Accountable person for the activity will need to sign off on the
documentation produced.
As
a second suggestion you can start bottom-up (and not use best practice theory
at all, but rather current practices). Ask each team to identify the team’s top
5 activities by volume (what are the things we do x times a day?). Assign one
activity to each person within the team and get the work instructions written
in one afternoon.
Do
this 3 times and the result of 15 work instructions will likely document the
activities that the team spends 80% of their time on. There will always
be 20% of activity that is done less often, that won’t be well documented ...
don’t sweat the small stuff.
Of
course you do need some cross-team coordination and ownership, but at least you’ll
have some documentation to start with.
Both
methods are only half the battle as once documentation is created it will need
to be maintained, reviewed, updated, improved, communicated etc. I am mainly
looking towards the ‘owner’ (accountable person) to do this, but there are some
ways in which you can ‘institutionalise’ this.
New
staff should, as part of their induction and probation, not only be trained in
the work instructions, but used as an ‘unbiased’ observer. Let them spend some
time on reading (all) the documentation and then discuss with them what makes
sense & what doesn’t. Perhaps repeat this again (and the end of probation)
when they know how the actual work takes place (and make them update it).
Similarly
when staff has gone to (ITIL) training, they should ‘apply’ their knowledge by
reviewing the relevant procedures and suggesting updates\improvements based on
their experience (practice) and new knowledge (theory).
All
these suggestions make staff responsible for creating the documentation and
thus hopefully instils a sense of ownership\acceptance. This as above all, all
staff should have the culture, awareness, attitude and understanding that the
work instructions are there for a reason (like the pilot’s checklist) and that
not only should they be followed, but actively used. Staff should be rewarded
for suggesting changes to existing work instructions and\or promoting the use
of them within their teams.
But
that brings us back to the PEOPLE element, which as I mentioned is the hardest
one of all. More about that some other time.the ITIL Zealot
October 2012
No comments:
Post a Comment