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

Is your Service Desk a SPOC or a SPOF?

One of ITIL’s benefits is identified as the ‘one language’ to be spoken within IT; and often people indicate this is an objective at the start of a course (I want to learn what this ITIL is I keep hearing about) or the benefit obtained at the end (now I know what the others are talking about). ITIL does introduce a lot of definitions (have a look at the full glossary-of-terms: 55 pages !) and as a good methodology should , it also contains a lot of acronyms. So let’s start with explaining the ones I’ve used in the title:

•    SPOC = Single Point of Contact
•    SPOF = Single Point of Failure

The Service Desk is supposed to be the Single-Point-of-Contact for Users on a day-by-day basic (i.e. for incidents and service requests). Although mistakenly (IMHO, another acronym although not ITIL-specific) the book reference its primary aim not so much to be a SPOC but to restore normal service to users (which is the incident management objective and only part of the service desk’s activities).

The reason is simply (and mostly well-understood and reasonably implemented in your average organisation): instead of letting the Users having to hunt around and find someone in IT who can help him, they can contact the service desk for anything and everything. From there the correct service process and function will be engaged. As such it is not only the single, but also the FIRST point of contact and this makes it very important, if not critical in the perception of service.

Imagine company A with you-beaut IT: the latest-and-greatest in desktops, the latest-and-smallest in laptops, massive fully-redundant internet-pipes ... but no service desk to speak of. When something goes wrong you, the user, has to find an IT person and when you finally do, you’ll get a response like ‘yeah, what do you want ... you touched it didn’t you? ... I don’t have time for that ... I’ll look at it this afternoon, maybe, if I feel like it!’

Company B on the other hand has IT equipment that is a bit longer in the tooth, not as powerful or modern. It does break (occasionally) but if it does you can call the service desk. There your phone-call gets answered within 30 seconds by a friendly voice who tell you that ‘we are aware there are currently some issues with the e-mail service and according to the latest information we’ve received it should be fixed in the next 15 minutes’ (and it is: say what you do – do what you say).

Now, I reckon that when it comes to user satisfaction, company B is going to give company A a run for its money. Not because their IT is better, but their service is (or at least their service desk). This is the role that the service desk plays: in the perception of the value of a service. Hence we need to make sure it is resourced properly and that means not necessarily with junior technicians (who have to do a tour-of-duty on the service desk before they’re allowed to touch a server or a piece of network equipment).

After all, it is the service desk operator which needs to differentiate between user A and user B calling to tell them their e-mail is not working. On the face of it two similar incidents, but with user A screaming down the phone that they are a manager, that it is a disgrace and that they demand someone to fix it ... right now! However, user A doesn’t actually need e-mail that much for their work (it could easily be -temporarily- replaced with phone-calls, faxes or face-to-faces). 

This in contrast to user B, who addresses the service desk a lot politer, almost apologetic for the fact that email is not working and hope they haven’t caused any trouble. User B actually performs their tasks using e-mail (for instance receiving orders from clients).

The service desk not only needs the communication skills to deal with the angry user A, but also the business-skills to understand the relative impact & urgency of both user, the service-knowledge (including SLA and service catalogue) to determine how to respond to this. Any technical skills might help in the initial diagnosis, but so does the knowledge\known error database.

Without these skills and the true service attitude (always remember that without IT most organisations would still exist, but without those organisations most of us wouldn’t have a job!) your service desk may still be a SPOC, but it might very well also be a SPOF. 

OK, perhaps not a single point of failure but certainly the first, visible one. And you only get one chance to make a first impression, and those first impressions are normally what tips the favour in any satisfaction survey.

the ITIL Zealot
July  2012