Practical tips for Process Manuals

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 1^st, 2^nd and 3^rd 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

What is wrong with ITIL training?

ANSWER 1: EVERYTHING

• ITIL Training is just another way for consulting and education firms to get your money
• ITIL Training just focussed on the process theory and facts
• Multiple choice is an inadequate way of testing someone’s capability

I guess from a negative perspective the above statements are true (to a degree). ITIL V3/2011 has made the training path more complex: whereas before it was Foundations and then either Managers or Practitioners, now it is Foundations, either Lifecycle or Capability, or some kind of combination of those and then Expert ... In particular the distinction between Lifecycle and Capability is very unclear with large areas of overlap (for instance Service Operations vs. Operational Support and Analysis) and even more puzzling gaps (little or no CSI in the Capability Courses, limited Strategy, no Design Coordination ...). APMG could have done a better job with positioning the courses, and limiting the options.

The second (negative) argument is that ITIL training is (just) focused on theory. Again there is some truth in this, mainly as most courses will be followed by an exam, which focuses on the theory (see next point). But from Intermediate up, each course is supposed to provide more than 50% practical, interactive exercises. The exception is the Foundations which does require a lot of theory to be explained, and unfortunately due to market pressure, predominantly in a 3 day / 20 hour time span.

I think the 3 days are about the maximum what a ‘novice’ (or manager) can bear, so if we don’t want to tinker with the time-element of the Foundation course, then perhaps we should look at the content. Years ago a rumour surfaced that the Foundation course might be split in two: one basic with Operations & Transition; and one more ‘advanced’ with Strategy, Design and CSI. I thought this was a great idea, but unfortunately it never materialised. 

Most consulting\training firms, or in-house training organisations will have developed an ITIL Overview or Introduction which provides the basics in one or even half-a-day. And because there is no exam-pressure you can focus on the key-concepts.

And therewith we come to the biggest argument, which is that the exam ruins a good course. I think no-one will deny that multiple choice exams are an awfully inadequate way of testing someone’s capability (no matter how much 'Bloom's taxonomy you throw in). And unfortunately the ITIL multiple choice exams are no exception. At Foundation level the question often require knowledge of specific, theoretic factoids. Something that could be easily found in the ITIL documentation (, pocket guide or glossary-of-terms) and therefore hardly a necessary skill or capability. It should focus on the larger concepts of Service Management, the lifecycle and the key processes, perhaps with small (one or two paragraph) scenarios.

The Intermediate exams are slightly better with ‘scenario-based, gradient-scored’ questions. These questions at least relay the message that not all answers are wrong or right, but that some are ‘more right’ given the circumstances. But unfortunately then a significant number of questions still rely on knowing the exact, ITIL way or in other words more factoid book remembering, rather than true understanding.

Taming the Beast of Information Overload
http://www.foundationnews.org/CME/article.cfm?ID=1003:

And at Expert level this becomes an even bigger issue as the difference between the answers becomes smaller and the correct answer (at least in my opinion) almost always is ‘it depends’. With an essay-style question you can get points even if you made the wrong choice, depending on your ‘defence’ of that choice. With multiple choice it is an all-or-nothing. And sorry, I may be overestimating my own ITIL power, but if after 20 years of almost daily working with the material I still score a 0-point answer (on the MALC), I actually believe there is something wrong with the question, rather than with me or the theory.

ANSWER 2: NOTHING

I admit that all of the above arguments hold an element of truth. However, I think that in the end it is up to both the course candidate and provider to achieve a satisfactory outcome.

The provider of the courses needs to work within the syllabus (and exam requirements) but most courses give ample opportunity to add examples, exercises, discussions and other elements to ensure understanding and provide practical guidance.

The candidate also has a responsibility. If they just come to the course to be a few days away from work, or expect to find a silver service management bullet that will be spoon-fed to them (oops, mixing some metaphors), it will be a disappointing experience. The candidate needs to be open to learning, participate in the course, question everything (most trainers will welcome the challenge of questions as this will allow them to expand on the theory and provide insight for not only the questioner but the other participants too) and ensure the course enhances their understanding. I think it should be mandatory for candidates to create a next-steps plan after each course (and for their managers to demand, verify and control these).

The exam is just a bump in the road, and fortunately with thorough understanding of ITIL and a modicum of learning the exam can be easily passed (perhaps not with a 100%, but passed nonetheless).

In a future blog I might address the various type of training (on-line, classroom, blended) and well as the customisation or training and creation of a training path (with overviews, simulations, accreditation etc.). But I’ll leave you with a musing on the difference between education and training: education is more theoretic\school-based whereas training has a practical connotation. After all you wouldn't want your teenage-daughter to come home from school raving about the sex-training she had that day!

the ITIL Zealot
May 2012