5 Reasons for Slow IT Support

Slow IT Support is everywhere. It doesn’t have to be that way, but it often is, with fixes taking days when they should take minutes.There are several reasons for this; in my experience, these are five of the most common.

In my 25-year consultancy and training practice, I specialise in how to best manage IT Support – not ‘Servicedesk’, not ‘customer experience’, but IT Support as an end-to-end function. To measure the state of IT support, I conduct occasional industry surveys and top those statistics up with various client engagements; and of this I am convinced – as an industry, we used to be a lot better at IT Support than we are now.

The thing is, good IT Support is not just “a little bit” or a few percentage points better than mediocre support, it is better by multiples. If an enquiry is not fixed at first encounter, it goes to another line of support, and there the time-to-fix lengthens – but not by a little, by a lot. In many organisations, the second- and third-line time to fix is typically measured in hours, days, or weeks, when it can and should be mere minutes. Corporate IT Support these days is slow. Not just a bit slow, but taken as an average, exasperatingly, outrageously, embarrassingly, wastefully, expensively, business-impedingly, unnecessarily slow

1. “Good IT Support Doesn’t Matter”

For IT Support to be good, it is essential that it be given the clear message that the delivered service level actually matters. Sadly, that is not always the case. Our official blunt instrument of measurement, the ‘Service Level Agreement’ (SLA) often gives the wrong message – like giving a four-hour-fix target to something that will take ten minutes, thus endorsing unnecessary delays. Or not being used to make management decisions about service improvement. Add to that local technical workgroup heads who pay no attention to their staff’s productivity and just act as another technician rather than leader, and effectively the message is “look busy, but how much you turn out and how quickly are of no management concern.”

Industry wide, IT support second-line productivity is 35% lower than it was in 2006. You need three technicians to do the work of two a decade ago. This is bad – we’re letting it slip. Instead, show them that what they do actually matters, and they’ll do it.

2. Demotivating Backlogs

IT Support staff arriving at the office are confronted daily by a mountain of work they will never conquer. At the end of the day, the mountain will be the same size it was when they arrived, probably pretty much the same size as this time last year.

The entrenched backlog screams pointlessness at your people all day, week, month, year long. It doesn’t matter how much work Joe does, he’ll never win. So he just does what he feels comfortable with, typically far less than his capability or capacity. He can claim a job and leave it there to deal with later, thus making decisions on user productivity that have financial consequences that should be way above his pay-grade. He cherry-picks the jobs he fancies, so the difficult and boring jobs just get older and older. And nobody dares call the user to ask if that job they logged six months ago is still outstanding.

IT Support service backlogs are universally bad. Get rid of them and of the procedural factors that create them.

3. Siloism

We’ve always had a silo problem in IT, ever since we’ve been paying people increasingly more the further away from the customers their job is, and paying least of all to those who deal with customers several times an hour. Take a look at any ITSM system; every group has a queue. Every individual in every group has a queue. Some individuals or groups have more than one queue. An enquiry can visit the same queue more than once before resolution.

IT consists of an array of ‘functions’, each set up to do a specialist technical job and, with the exception of the Service Desk, typically seeing user support enquiries as an interruption to that core function. Sometimes we are even forced to have an ‘Incident Manager’ to chase support enquiries through the office and make sure people are doing their jobs, for Pete’s sake. That should be utterly unnecessary.

All this is of course built into ITIL; yes, my claim is that slow IT support is actually endemic in ITIL. Furthermore, this queue-mindedness is why any claim ITIL may have to be ‘Agile’ or “DevOps ready” is frankly laughable. Think queue, think bottleneck, and bottlenecks produce delays. Our concentration should not be on the silos and making them function appropriately, but on the work-unit and its throughput. Let’s concentrate primarily on what we’re supposed to be doing, not on the bureaucracy we’ve built to do it.

4. Lowered User Expectations

When poor performance is met with low user expectations, you have a stable situation. It can stay like that for years until somebody notices that business purposes are not being served. The users will get by in the face of slow IT support – they’ll help each other, hire their own technicians, convert a user into a local computer expert, go ‘Shadow IT’.

Put simply, if your service is rubbish, just so long as the users expect it to be rubbish you’ll get away with it. And consequently, you may never even get to know that your service is rubbish.

If we do not stay in touch with and ultimately set user expectations, the users will set their own. If they set them higher than IT can deliver, outsourcing becomes a very real possibility. If they set them lower, IT can slip blindly into irrelevance.

5. Fear of Success

The 2008-2009 recession brought this one into sharp relief. Staff don’t want to lose their jobs. So they see it as not in their interest to finish their work, because they fear cost-cutting managers will then start making layoffs. This comes up in interviews I conduct with IT support staff as part of my consultancy engagements. Anecdotally, I notice this particularly in the health and education sectors.

The irony is, there may be no need for layoffs – quite the contrary, in fact. There’s plenty more they could do if they finished the reactive stuff – self education, service variety, secondments, projects, etc. It’ll take measurement (which you can learn about here), because you’ll need science to prove the reality. But the vicious circle means it’s difficult introduce these things because people fear being too productive.

Let’s not forget that most production-IT fixes can and should be produced in minutes. There should be no significant backlog. And most organisations can achieve this, but it will need a change to culture and methods, and particularly in the quality and skills of technical workgroup heads. We should embrace that change, because the business needs it.

There will be resistance. You will need strong, capable and determined managers to carry it through. Comfortable niches will have to be dislodged. But the payoff benefits everybody.

Your Staff Will Love It

Many times I’ve had the opportunity to take a failing IT Support service to success and although that of course serves the business, another truth seems universal – that despite fearing the change, when it happens, the staff love it. Suddenly, they are part of something successful. They gain the respect of their customers, peers, employers, and managers. They see their own growth in the necessary and accompanying expansion of their skillsets. They no longer need to conceal their work-rate, and that new honesty is spiritually liberating. There’s no backlog, but that’s no longer a threat. They know how much work is enough. Success is endemic and every day is a new boost to staff confidence and morale.

Go for it. You know where I am if you could use help with the change. You can also learn more about fixing slow support on my two day seminar ‘How to Lead an IT 2nd or 3rd Line Support Group‘.