A zombie idea is a proposition that has been thoroughly refuted by analysis and evidence, and should be dead — but is still walking among us. In the service management world you will once in a while meet some of those nasty creatures. In this blog I explain how to recognize and ultimately destroy them.
More than 50 shades of grey
I was recently asked by my wife to give the radiator in our kitchen a new colour, namely grey. In the paint shop, on my request for grey radiator paint, the salesman handed me a little booklet of 5 pages each with 5 columns and 6 rows of miniscule rectangles in a different shade of grey, so 150 in total, with the peremptory demand “Here, choose!”.
An impossible choice. “What would you recommend?” I asked. The salesman had been asked that question often. He opened the booklet on the third page and pointed to the first rectangle: “This is asked for a lot, especially for radiators. Never had anyone come back, who wasn’t satisfied with it.”
Thus it became that shade of grey. Even though I was quite sure that the popularity of this shade had nothing to do with its distinctive look but was all due to its position in the middle of the book and the comforting thought that everyone else had chosen it. This phenomenon is well known in consumer psychology and has been given a beautiful name: “Overchoice“. The consumer with choice overload and who is pressed for time will simply choose the first safe alternative that comes along.
A service desk agent is constantly working against the clock: Taking new calls, registering tickets correctly, immediately trying to find a solution and if that fails, assigning the ticket to the appropriate team …. Thus you don’t want to give a service desk agent any choice overload.
The “Overchoice” trap
And yet this frequently happens. A prioritizing based on the ‘priority = impact x urgency’ algorithm is a painful example of this. This algorithm is still prominent in the 2011 ITIL service operations manual and unfortunately not as an ‘in-memoriam’. Thereby the following guidelines are given: in determining the priority one must take into account how quickly the business needs the solution, the potential financial impact of the incident, the possible impact on the reputation of the business and the potential impact of the breach of law … Duh? How quickly does the business need a solution? Ask the user and he/she will answer you: now! What is the potential financial impact of the incident? Check with 5 people and you’ll get 6 different answers. It’s the poor old service desk agent, who then also has to stop and think about the legal impact of the incident and the impact on the image of the company.
That prioritization based on ‘impact x urgency’ is a horror for our service desk agent under time pressure and under this choice overload he will do what a consumer does: pick the first safe alternative that comes along. Just like I and so many others opt for the grey rectangle on the top left of the third page, the service desk agent will invariably opt for the same impact and urgency codes. Over the course of time the prioritization in such systems becomes flat as a pancake.
The silver bullet for killing this stubborn little monster is the ‘impact’ x ‘service criticality’ algorithm. Not every service is as important or critical, the damage in case of unavailability of the SAP service or the SharePoint service will not be the same; let’s say that in most cases SAP has a higher ‘service criticality’ than SharePoint. We determine that ‘service criticality’ in advance and it’s defined in the ITSM tool configuration. Each incident is linked to a service, so the service desk agent certainly doesn’t need to worry about determining the service criticality. He only determines the impact and you can initially easily keep that simple: impact on 1 or more users, service unavailable or just degraded, combined with a maximum of 4 simple choices.
Converting the priority into an ‘exact’ time limit is the sledge hammer with which you completely neutralize this zombie. ‘Exact’ means that the ITSM tool is able to calculate the resolution time taking into account support hours and holidays. Away with flat queues, your second and third line can now work on the most urgent incidents on the basis of an objective queue.
Urgency – how to deal with it
And what of ‘urgency’, is that concept now dead and buried? Not if you apply this concept correctly. The above algorithm implements your SLAs, your arrangements with the business. It says for example, that if an individual has no access to SAP (impact = medium), we will fix it within the 8 hours. In most cases, this is quite acceptable for the users. But for the financial controller, who has to complete his financial reporting at the end of the month, those 8 hours may be an eternity too late. It’s then that the urgency flag comes into play. The SLA determines a target time against which we want to have resolved the majority (e.g. 90%) of the incidents at the latest. The queue ensures that we start solving the incidents that are closest to the target date. Using the urgency flag we can place an incident at the top of the queue and with that one incident we will be able to start even quicker, without us having to ‘misuse’ the SLA parameters for this, such as impact or service criticality.
As long as this ‘priority = impact x urgency’ algorithm is in the ITIL books, this Zombie idea will continue to plague many a process design and out-of-the-box ITSM tool configuration. If you experience reluctance in your organisation to get rid of this unfortunate algorithm, then quote Steve Jobs: “Don’t be trapped by dogma – which is living with the results of other people’s thinking”. And if that doesn’t help either, then quote Robert Kirkman (author of The Walking Dead): “If it’s dead – fucking KILL IT”.
By Wouter Wyns, Service Management Architect at Xurrent (formerly 4me) | 8 juni 2016