IT Service Management
Image: WPTidBits

Improving Your Service Desk

The Service Desk is “the single point of contact between the service provider and the users. A typical service desk manages incidents and service requests, and also handles communication with the users.” (ITIL Glossary). As such, an efficient and effective service desk is critical to both the performance of an IT function, and how IT is perceived by users.
But many service desks do not operate efficiently or effectively, and do not please their users. The traditional approaches to improving service desk performance - service software, advanced telephony, and outsourcing - have generally disappointed IT management and users.

What's required is a new approach to the role and methods used in service desks.

1. Value Demand and Failure Demand

John Seddon, in “Better Thinking About Demand”, describes Value Demand as the “demand for which the service exists to serve” and Failure Demand as the “demand caused by a failure to do something or do something right for the customer”.
In the case of an IT Service Desk, value demand relates to what ITIL (Information Technology Infrastructure Library) describes as Service Requests (“A request from a user for information, or advice, or for a standard change or for access to an IT Service” – ITIL Glossary) and Service Fulfilment (the process responsible for managing the lifecycle of all service requests - ITIL Glossary).
Similarly, failure demand relates to the ITIL activity of management of incidents (“unplanned interruption to an IT Service or a reduction in the quality of an IT Service”).
Looking at the role of the service desk in terms of these two types of demand has an important implication. It is common for service desks to see their role primarily as being incident management (“the process responsible for managing the lifecycle of all incidents; the primary objective of incident management is to return the it service to users as quickly as possible” – ITIL Glossary). If a service desk sees itself so, it tends to consider the handling of incidents as “business as usual” when, in fact, it is – or should be – exactly the opposite.

2. The Service Desk’s Mission

The mission of a service desk should be elimination of failure demand (incidents) and the delivery of more services (value demand) and delivering them better, faster and cheaper. Once it succeeds in this mission, the service desk can truly be said to have dedicated itself to serving its users.
If a service desk does not adopt a mission of this nature, it will find itself on a hamster wheel of incidents, always running fast but never getting to the end, and with deep and lasting user dissatisfaction. Such a situation has commonly led to the outsourcing of the function, at great opportunity cost to the employees, the users and the IT (and the broader) organisation.

3. Elimination of incidents (failure demand)

ITIL describes, in great detail, the activities, tools, measurements and roles and responsibilities related to incident management (and the related event management and problem management). This article looks at incident elimination, how it can be achieved and some common causes of excessive incident volumes. Elimination requires two concurrent strategies: incident prevention and incident pre-emption.

3.1. Incident prevention

Incidents are the manifestation of a problem in a way that interrupts or reduces the quality of a service. A problem can be “a cause of one or more incidents” according to ITIL. This points to how incidents can be prevented – by both preventing problems from being introduced with and into the service, and by fixing problems as quickly as possible once they have manifested themselves as incidents.
3.1.1. Problems introduced with the service
The ITIL framework provides a very good, and detailed, approach to the service lifecycle and is an excellent “text book”. From a service desk perspective, the most important consideration of a new service is “does it meet the users needs, and does it do so without error”. Unfortunately, this is rarely the case. Despite decades of development of our knowledge of how to produce “complete and correct” IT solutions, our execution is incomplete and incorrect to a greater or lesser extent. This puts enormous pressure on a service desk in terms of volume of work (failure demand) and user dissatisfaction.
It is an unfortunate fact that, in most organisations, service development resides in a different cost centre to service operations. This leads to poor solutions being “thrown over the wall” to the support teams.
The two main strategies for addressing problems introduced with the service are for the support desk to:
  • Establish a “gate” at the point of service introduction to allow it to confirm that the new service is complete and correct
  • Engage with the service development organisation to ensure that new services have “quality built in”.
3.1.2. Problems introduced into the service
Once a service is launched, it is often the service support organisation – to which the service desk usually belongs – that has responsibility for problem management and thus “fixing” problems. Or it may be the service development organisation that provides the people to do such work.
In either case, the complete change and release management process flow must be assured using the same principles as for a new service.
3.1.3. Expeditiously solving problems
Again, ITIL provides a sound exposition on problem management. From a service desk perspective, the key is that those conducting problem management should follow a systematic approach to problem solving (see “10 steps to solving your problems”).

3.2. Incident pre-emption

In the broader world of customer service and satisfaction, it has been shown that only one in 25 customers complain about a faulty product or service. In other words, if a service desk is alerted to an incident, then quite likely many more incidents related to the same core problem will occur in the future (next few seconds, next few days, maybe longer).
Strategies for pre-emption of incidents include:
  • Quickly advising users of the nature of the incident and how to avoid it (“workarounds”)
  • Adding triggers to services to warn of impending service interruptions (for example, from resource depletion)
  • Continuing analysis of common causes of incidents (for example, reaching the maximum number of concurrent users) to determine preventive action.

3.3. Expeditious incident resolution

It’s not always possible to entirely prevent incidents, and pre-emption still requires the resolution of the initial incident. But the more quickly an incident can be addressed, the lower the cost (in people, money, resources and opportunity lost) of its resolution. The way to speedier resolution of incidents is to remove the common causes of delay in incident resolution:
  • Queues: waiting for resources (such as test facilities), and; handoffs to other personnel (specialists, users for testing, release managers and others)
  • Rework due to poorly designed repair processes in which prevention and appraisal are starved of resources, leading to high cost of correction of errors created during incident resolution itself
  • Iterations and control points in the incident resolution process flow
  • Poor knowledge management causing “reinvention of the wheel” in that the same – or similar – “problem” is solved multiple times.

4. Delivery of more services better, faster and cheaper

Increasing volume of Service Requests (value demand) indicates that the service desk is providing needed services to its users. But the meeting of this demand doesn’t necessarily require additional resources, not if the desk focuses on expediting and automating service fulfilment.

4.1. Expediting service request and fulfilment

Service request and fulfilment processes can be sped up in the same way as incident resolution (above) - by reducing queues, rework, iterations and control points, and by improving knowledge management.

4.2. Automating service request and fulfilment

Many basic services can be automated quite easily, for example password resets, internal purchasing, and self-service HR. Automated service fulfilment is better (can be made “error proof”), faster ("immediate" in many cases), and cheaper (almost zero per service request).

See the BusinesSPM Project "Leighton Contractors Oracle eBS Support Transformation" for a real world example.