Process for Process' sake

One of the most heard (negative) comment about ITIL is that it introduces bureaucracy. If have dealt with this topic before, but recently I was reminded again of how people sometime implement (and follow) process for process’ sake, without an understanding of the reason for the process, and thus the outcomes required.

Let’s start at the beginning, or rather with the theory. ITIL defines a process as

A Process is a set of coordinated activities combining and implementing resources and capabilities in order to produce an outcome, which, directly or indirectly, creates value for a customer or stakeholder

As many other people\trainers do, and as you can see from the highlighting\bolding above, the easiest way to explain a process is that it coordinates the activities you’re supposed to do (which makes it easier than ‘making it up as you go along’, more repeatable and manageable than ‘just doing what you think you should be doing’ and all those other behaviours we don’t want to see in Service Management.

To me this is the key of a Best Practice (something which is accepted and used), or rather the opposite of best effort. Best effort means that each individual is doing his or her best, but often without any structure, documentation, management. Introducing a process of coordinated activities means everyone will do those activities and everyone will do them the same way, thus creating a repeatable, manageable process.

Therefore the first characteristic of a process is that it is measurable. After all if you can’t measure it, you can’t manage it and the coordinated, uniform nature of a process allows it to be measured (of course this is also where\when we introduce bureaucracy but that has already been dealt with in another blog).

A second characteristic of a process is that it has a trigger. In other words, we don’t just do something, whenever we want, but based on a particular trigger we start a particular process. I have a visual image of ITIL whereby all 27 process manuals (or 26 or ...) are standing on a boardroom table ... which process to follow? Fortunately above each process is an arrow indicating the trigger for that process: a call to the service desk triggers incident management, a submitted RFC triggers change management, the 2^nd Monday of the month triggers service level management (reporting). 

Maybe this is why the Strategy & Design processes in ITIL are so much more difficult to define. Cause where the Transition & Operations processes are quite linear (one trigger, one set or flow of activities, leading to one outcome), the Strategy & Design ones have multiple triggers, flows and outcomes. Again, I digress.

The last two characteristics of a process are that it has a defined outcome (the reason for the process in the first place) and a customer. Or stakeholder, there is some confusion here as it is not always the ‘business’ customer we mean here, but someone who wants the outcome of the process (after all why would you perform the process if no-one wanted the outcome).

And this is the ‘trap’ of ITIL. Because ITL defines the process, trigger & activities perhaps we sometimes to blindly just ‘implement’ what the book tells us, without considering the outcome or customer. This is the WHY of ITIL which is no readily apparent but certainly within the context (see by blog on that). Or perhaps after we have created a process (taking the outcome and customer into account), we proceed to merely follow the process, reviewing the KPIs but never verifying the original outcome, objective, customer and\or CSF\KGI.

It has now become process for process sake. My stock analogy for this is: ‘the operation was a success, but the patient died ... but look at those stiches, textbook!’. 

The other day I got a reminder phone-call from my dentist. This is a nice service they deliver as mostly I make my appointments 6 months in advance and this why I get reminded and it gives us the chance to reschedule if it is no longer convenient (from their side it avoids patients not showing up and thus increases utilisation and thus business revenue).

However, in this particular instance my previous appointment had been cancelled, and we had only rescheduled it to one day later. Thus receiving the phone-call reminding me of an appointment booked less than 24 hours before now didn’t add any value (or outcome), but instead felt like ‘process for process’ sake’.

the ITIL Zealot
July  2012