For healthy IT support, go beyond the service desk

Let’s not underestimate IT user support. It is far and away the most important function of IT. Occasionally, some business department heads will need a software development project or to commission an infrastructure improvement, so calling upon IT’s project managers, developers and architects. But compared to IT support requests, these other interactions are relatively infrequent. This is because all computer users, not just their bosses, need IT user support all the time, tens if not hundreds of times a day. Please, no parking – this gate is in constant use.

Support’s business importance

Most employees use computers for their own productive contribution to the business. This means that if a computer user cannot work, then the company is losing that productivity in real time. By reactively minimising that productivity loss, user support is the main IT function responsible for nothing less than keeping the company going, incident by incident, hour by hour. IT support’s business importance is unquestionable. So it saddens me to see important industry frameworks like ITIL™ and COBIT™ so ineffectually skirting around and avoiding this truth for so long and limiting their support horizons to the service desk.

The absence of a proper IT user support strategy and definition from both ITIL™ and COBIT™ confuses the market and, I believe, jeopardises the health of this vital provision. Neither of those frameworks have a credible management solution for this IT support. They do not even define it as a service. What exactly is IT user support? Who owns it? Who is in charge of it? The closest either of those frameworks gets is something called ‘incident management’. Essentially, this is the chasing of an ‘incident’ through the various parties who might have a hand in resolving it in an attempt to deliver an expected service. Unfortunately the incident manager himself is often a figurehead too high up in the organisation to actually manage the detail of numerous individual ‘incidents’, or too low in the organisation for highly paid network technicians or developers to fully respect his proxied authority. Fortunately though, in a fully healthy IT support function, that embeds the importance of support in all parts of IT, the incident manager is superfluous.

Get a support strategy

IT user support does not stop at the service desk. In fact, ideally it does not even start there, but instead at the establishment of a support strategy. This is a set of senior decisions to consider the shape and function of the IT support machine, resulting in a universally-accepted declaration as to how IT support as a whole shall be delivered and where the responsibilities shall lie. In effect, it is a statement of what is to happen and who is expected to do how much of it.

Take as an example the accepted truth in many IT departments, namely that a given type of reported computer problem should be passed to, say, the network support group. That may be given policy, but where did that policy come from? Was it designed, decreed and declared by IT senior management? Or did it just come into being organically as standard practice born of ‘common sense’? The network group exists, so it seems obvious that a network problem should be assigned to them – and we don’t need a policy for the obvious – or do we? How many such assignments will we make to the network group? How much resource should the network group ring-fence to deal with those assignments? What is the impact on the network group’s main work, of having to deal with assignments coming from the service desk? There are questions here requiring rather more than ‘common sense’.

Healthy IT support

In a healthy IT Support function, those questions are ideally asked early in the formation of IT support and then frequently thereafter to cope with growth and changes in technology or business. They should be asked in all and any groups where reactive support will have to take place. Rather than leave it to common sense, we deal with it by laying down a policy at senior IT management level, so that the groups affected by IT support know how they are affected, and that there is a senior management expectation on those groups to organise themselves to take their share of the support burden.

IT support is not, and should not be simply a question of a portal to IT’s technical resources. That’s part of the job the service desk does, but it is not enough. IT Support is a big, cross-departmental, horizontal responsibility. It is about the whole of the journey of the support request, through all its ownership changes.

Because there are so many, simultaneous requests, we need a production line to handle all those journeys. This is why when I’m assessing or advising on the health of my clients’ IT support, I don’t stop at the service desk, but look at the whole IT support machine. There are managers all over IT, whose departments were created to provide one type of proactive, preventive or development service, and yet also have to deal with reactive support enquiries. If they are not set up to do that efficiently, there may be negative effects on everything else they do, as support demand takes resources away from systems maintenance or projects. It’s not just a matter of presuming to send a network-type enquiry to networks or a desktop-type to desktop. The healthy IT support function will be properly ready, at all levels and branches, for those impacts.


The good thing is, that you don’t have to go all the way back to bare bones and work out what your support strategy is before moving forward. You can start with the practical workings now and leave the strategising until later. Measure the impacts; speed up the ownership; orient the resources accordingly, to smooth the workflow. Help all sections of IT, not just the service desk, to know how to set their resources up both to cope with their main mission and to handle those reactive, assigned interruptions. That way you ensure the whole of your IT support production, not just the service desk, is as healthy as the business needs it to be. If you could do with a bit of external expertise, I have an Incident Management Shortcut service designed for just this.