In the mid-nineties, the original IT support guru Noel Bruton, began formulating a new method for managing IT support. Was he close to creating something we now call Lean IT support?

It must have been the early nineties, because my family and I departed Stockport in 1995; and it was definitely Stockport’s main Post Office in Great Underbank where it happened.

I had started my practice as a consultant specialising in IT support management in 1991, and I was constantly studying other industries for what they could teach about improving IT support. I found myself getting obsessed with that busy Post Office, and in particular, why there was always a queue there. It was like the regular helpdesk problem (‘servicedesk’ wouldn’t be popular for another decade), when there was always a queue on the phones and always a backlog of support calls. So one afternoon, I took myself down to the Post Office and watched. What I learned made me produce this slide….

Noel Bruton Lean IT diagram

…and I’ve been teaching it ever since.

The necessary queue
There is system in the Post Office. You don’t make much money selling stamps, so you’ve got to keep your costs down. One thing you can do is to make sure there is no resource standing idle because that wastes money. I noticed that the constant in the Post Office was the length of the queue. When the queue got beyond a certain number of customers, they opened another sales window. When the queue dropped below that number, they closed a window.

What was going on? Intentionally or otherwise, that Post Office was, in effect, passing part of its cost of sale on to the customers by making them pay with their own time. Meanwhile, the queue guaranteed that there would always be another customer waiting to be served by one of the open windows. So the manpower behind the counter would always be at maximum use and thus producing the maximum return for the cost of those open windows.

I didn’t realise it twenty-odd years ago, I had codified an approach to Lean IT support. And thanks in no small part to good old Stockport Post Office.

Slack, skills, rotation
But for this to work, there had to be at least three other factors. One was slack – there had to be slack resource ready to man the windows should the queue length increase. But that implied the second factor – that this slack could not be sitting idle, or that would be waste, so it must be occupied doing something else, which meant that staff who worked on sales counters must be multi-skilled. And the third factor was rotation – Stockport’s postal workers must be ready to rotate between different functions.

To the customer, the queue in the Post Office looked like a bottleneck, a service failure – but it was in fact the absolute opposite. It was a way for the Post Office to guarantee that production was constantly fed with the raw material of a customer to service.

Just-In-Time
With people queueing to be served by a limited number of windows, here was a clear parallel with first-line support. But it was more than that. It was an inverse expression of something that was already established in manufacturing, namely ‘Just-In-Time’ (JIT). Under JIT principles, a process is producing a constant return, by not having to wait for raw materials; but also not having waste caused by over-supply.

So I began to translate this to the helpdesk. What were the factors that caused queues outside the helpdesk? That led me to Erlangs and Queuing Theory and a set of calculations for quantifying and controlling that flow. It led me to see support workflow as a series of events that have known or adjustable capacities that can cause, exacerbate, or alleviate backlogs and queues. That’s what the slide begins to depict.

Support production line
In other words to see IT support, from service desk to closure, as a production line. And from there, it’s a short hop to applying JIT techniques to the various components of that line. This was because there were queues not just outside the first line, but inside the whole enquiry-handling apparatus.

It was time to go deeper.

Workload arriving at a first line of support such as a service desk is part of a pattern reflected all over IT. Workload arrives at second line too – would the same algorithms work there?

As it turns out, no they don’t. This is because downstream resolving agencies, like network support, applications maintenance, and so on have other priorities built into their core purpose. When a support call arrives here, it must necessarily interrupt those other priorities. That interruption can cause a delay to the escalated support call, because naturally, the resolver’s core purpose must take precedence. That’s why networks take so long to get back to you…

Those downstream groups need different algorithms to help them cope with their core function and yet service support requests swiftly nonetheless. So I worked on a further set of numerics and processes for other resolving agencies, along with how these would interact with the algorithms I already had for the first line.

Codified
So all that time ago, I had developed a complete methodology for efficient IT support workload throughput without queues and without backlogs. I’ve been teaching, professing and installing that methodology ever since.

I didn’t have a name for it back then, because the name hadn’t been invented. However, the name has since arrived in the IT lexicon, brought over from what JIT morphed into – it is ‘Lean’. Although I didn’t realise it twenty-odd years ago, I had codified an approach to Lean IT support. And thanks in no small part to good old Stockport Post Office.

And yet after all this time, decades later, ITSM as an industry philosophy and tools-market is still telling us we have to have queues all over the place. No we don’t. We’re being misled. We can have Lean IT support, which is less bureaucratic, faster, cheaper, and better for the users and the business in terms of both quality and service outcome.

Lean IT support how-to
There are numbers involved. You have to know how many calls your first liners can take in a day and how many of those they will escalate elsewhere. Once you know that, you can plan your resources to avoid queues. Erlang quantification will be essential, for your incoming calls, arriving emails, portal engagements and any other ways the userbase consults the first line, where a queue can build up.

Second line groups will need to know the typical number of enquiries being assigned to them, as well as how much actual manpower (not elapsed time, but technician activity) it takes to resolve such an enquiry. You can’t be accurate all the time because of the variety of the circumstances, but a healthy dose of the Pareto Principle will see you though.

Where you’re trying to get to is to isolate the reactive work and ring-fence the resource just for that. Like the Post Office, rotate your staff between functions.  Now your project, maintenance, and development effort need not be interrupted.

Discipline
Finally, discipline. Deal with the top priority calls first. Absolutely NO cherry-picking, because that forces backlogs to grow. Make sure you keep an eye on those numbers, and that your staff continue to achieve them. And if a backlog starts, deal with it immediately; because if you let it grow, it will suck the life out of your service level.

One last thing. Let all IT staff know that it’s OK for them to finish their work. Some are still scared that if they finish, you’ll make them redundant. Don’t let them worry about that, because there’s plenty more work for them to do, in helping the users become more productive through IT.

If you want help with this, I’m available as your LEAN IT Support consultant and trainer.

Noel Bruton is an independent consultant, trainer and bestselling author specialising in IT support delivery. He is an originator of much of what we now call ‘IT support’ and his ideas are reflected in mainstream IT management models. Learn more at noelbruton.com.

Guest post by:

Noel Bruton

IT support trainer
Articles mentioning Noel Bruton

More like this

, ,

No comments yet.

Have your say

%d bloggers like this: