It’s About Priorities, Not Service Levels

For the past twenty-odd years, I have been a consultant specialising in IT user support and its management. Organisations call me in to help them quickly improve support delivery, and staff productivity and job satisfaction. Over the years, I’ve had some fascinating engagements. This was one of the more memorable, because of its weirdness. And it has highly significant lessons for how we see, use and follow two key concepts in IT support, namely priorities and service levels.

Excellence among mediocrity

When I met Joe, he was running probably the most effective second-line desktop support team of the many in his company. It was among the best I’ve ever seen, before or since. Joe was exception writ large.

The company in question was and is one of the larger utilities which had engaged me to advise on improvements to second-line service levels. Poring over the statistical reports, I realised they had good reason to worry. The tables suggested that in over a dozen desktop support groups serving offices all over the country, mediocre demand and workload levels meant their technicians were not under much pressure. Nevertheless, average output per man was low. It typically took days for a second-line escalation to even get assigned, let alone resolved. Missed service level targets were commonplace. The IT management thought it might be a motivation problem. I suspected something more organisational.

The depressing picture was the same, in location after location. Except in the one where Joe was in charge. They had the same headcount per user, the same relative workload, the same mix of demand as every other team. But Joe’s group’s throughput was so fast, it didn’t just achieve its service level targets, it consistently, almost mockingly, blew them away. No other team came even close to Joe’s excellence. Output per man was higher, as were speed of response and fix, and both staff and customer satisfaction.  Compared to those of its peers, and indeed to those of IT second line groups I knew of in other companies, the figures Joe produced were astonishing. I had to visit that office and find out what was different.

Smiles, reggae and cakes

When I arrived, I was shown into the local IT workshop. I had been expecting to find a frenetic buzz of activity to match the reported productivity. Instead, I found the opposite – there was an atmosphere of unhurried calm and a room full of smiles. A tray of cakes lay on a bench in the centre of the room. One of the technicians perched on the windowsill, gazing into the street below, gently nodding his head to the cool reggae humming from a little squawk-box in the corner. Another sat before his screen, editing an imaging script. Things were getting done, yet without the stress and interruptions so common in support.

I wanted to see if this was a masquerade to bamboozle the visiting consultant, so I went on a couple of jobs with a couple of the techs. The reception they got from the users was somewhere between genuine friendliness and being welcomed like the homecoming of a minor local rock star. I conducted my own unaccompanied interviews with some users and the reaction seemed to be universally congratulatory. In years of consulting to IT support departments, I’d rarely seen anything like it. I showed Joe the statistical spreadsheet that evidenced his department’s excellence and asked him how the hell he did it.

“Ah yes”, he explained, “it’s because we have a very different approach to all the other teams. You see, in this branch, when an enquiry comes in from the service desk, we deal with it straight away.” That was it. That was Joe’s killer service secret. His team waltzed all over the service level targets by prioritising work according to its intrinsic importance, rather than when the service level stipulated it to be due.

Deliberate Delays

In the other desktop teams, procrastination was rife, endemic, even institutional. This was partly because they took the service level targets at their word. Four hours means four hours. This led to the ludicrous situation of deliberately delaying important work. An enquiry comes in that matches the criteria for a four-hour fix; ‘system unavailable, user unable to work’. The enquiry is immediately escalated to the second line. There, a technician considers the enquiry and estimates that it will take him around ten minutes to resolve. This means that for the next three hours and fifty minutes, the technician can legitimately occupy himself with something far less important, before finally attending that downed system – and yet still make the service level target and be considered successful.

To me, this is a failure, an abdication of our purpose, pure and simple. If the user cannot work, he needs service restoration now, not four hours from now.

The problem is clearly rooted in the targets and the way they were designed. Service level targets can lead to failure because they are the wrong approach to a more fundamental problem, namely workload prioritisation. And yet this misunderstanding is built into the functionality of pretty much every ITSM system on the market. What is worse, many of these systems call this built-in service level categorisation by the entirely false term of ‘priority’. Put another way, most commercial ITSM systems have within them the seeds of your service failure.

Service level targets are not priorities

A priority is a way of ensuring that the most important thing is the one that occupies the next nanosecond on the ribbon of time that stretches from here into your future. It is the precise opposite of the perverse and ridiculous double-think of traditional service levels, which dictate that something that needs doing right now may not need to be started for several hours yet.

The service level target is frequently a key part of the support ‘process’ – and yet it was the very antithesis of process that made Joe’s group so successful.

In MITUS, the Methodology for IT User Support, you can have service levels for reactive work if you want to, but MITUS does not provide for them, because they tend to make the service too slow. MITUS concentrates instead on what I call ‘true prioritisation’. Support customers are prioritised at business level even before they call. The impact of the enquiry is then assessed on arrival, and these two parameters plot a unique priority for it. Cherry picking is forbidden, so the most important work is done first, by resources that have been planned and ring-fenced according to the workload history. Outstanding work from yesterday has its priority elevated at the end of the day, so that by default, and subject to other parameters, older enquiries are kept more important than newer.

The other part of that is to ring-fence resources needed for reactive work. Anticipate the enquiries coming from the Service Desk and allocate staff to deal with that workload. Rotate the staff for job variety. Now you know exactly how much resource you have left over to deal with that other, proactive, or project work.

Practicality and customer relations

You probably ignore some service levels yourself. You have to, for the sake of practicality and customer relations. If your support service is typical, I’ll warrant you have a prescribed service level for some types of reactive work that has an allowed fix time of several days or even weeks; but nobody ever mentions that to the user. “Hi Mr User, thanks for your enquiry – just to let you know that we won’t even be looking at it until, ooh, probably after the next new moon.” Where on earth did such a service level come from? If it sounds potty, that’s because it is, and because it is indeed potty, it has no practical use. So what, that at the end of the year, you can look at all the enquiries with a service level target of four weeks and find you fixed them in an average of three, or five? What does that tell you? Precisely nothing.

Prioritisation is instinctive, empirical, practical, obvious, and serves the users. Service levels, conversely, are routinely bureaucratic, constructed, contradictory, statistically useless, based on 1980s’ computer maintenance contracts and serving the IT department. Yet guess which of these approaches is advocated by ITI-you-know-what?

I’m presuming you’re like me, and prefer to set up your support service so that it does the most important things first, in the interests of your customers, the business and its computer users; and by doing so, also benefiting your support staff.