How integral is the service desk for successful problem management?
To be truly effective, problem management needs high quality information in the incident record; information that is recorded at the very front line of the Service Desk. This isn’t happening and, to make matters worse, ITIL isn’t helping either according to Paul Offord, founder Advance7.
Problem management activity has traditionally been of a reactive nature, focusing on determining the root cause of a major incident after the event. This leaves IT support on the back foot, stuck in a cycle of fire-fighting and incident autopsies. While proactive problem identification and investigation is a defined activity, most problem management teams never seem to get around to it due to the pressure to follow up on major incidents.
There are three principle areas of problem management activity: first, incident autopsy; second, dealing with ongoing and recurring problems; and third, the proactive detection of recurring problems. But the performance of the Service Desk has a significant impact on the success of the second and third stages. Time pressures and lack of training often mean that the Service Desk only records scant information about an incident when logging a call and loosely or inconsistently applies incident categories. The resulting Incident Record may then be escalated to Second Line Support and eventually to Problem Management with the same details recorded during the initial Service Desk call.
Take the case of the Indian call centre that accessed systems based in the UK. Call centre agents complained that they experienced intermittent failures. The Service Desk categorised the repeated incidents as a network issue because UK users of the same system didn’t complain and Indian users had experienced some issues related to the network connecting to India. Descriptions of the problems in the Incident Record were vague, focusing on the user type, the time of day and how often. The issue quickly escalated, dragging in people from service delivery, the network team, the network provider and server support. After several months the service delivery team phoned a call service agent, asking them to explain the problem. The call service agent described three faults, all of which were obvious application errors and unrelated to the network.
I’m astounded just how much effort an IT support operation will put into incident recovery or problem investigation based on the scantest of information in the Incident Record or without any further checks with the user. What is even more tragic, is that I see organisations making this fundamental mistake over and over again.
I’ve been frustrated by the rate of progress toward proactive problem management but I think things are about to change. Problem Management is maturing and there is a growing interest in the proactive role. Recent changes at a high street bank signpost a positive future. They have split their problem management team into reactive and proactive, thereby avoiding the issue of only ever dealing with the fall-out from major incidents.
An important element of proactive problem management is problem detection through the analysis of incident trends. This has proved difficult since the total number of incidents can be thousands per week and analysis with reporting tools is thwarted by three factors:
a) Poorly defined incident categories;
b) Poor use of incident categories when logging Service Desk calls;
c) Use of free text fields to record critical information.
Poorly defined incident categories derive directly from ITIL, and although I do believe that ITIL is an excellent guide, in this area it is categorically wrong. ITIL suggests a top level of categorisation as being based on causing technology. This may be valuable for incident closure, but how can the Service Desk possibly know for certain at the time of logging an incident that the cause is hardware or software?
First we need to address the quality of the problem description. Ambiguity can easily arise, for example, an Incident Record that has the description: “Word document is slow to open” could mean many things. The user could be double clicking on the Word document in Windows Explorer, or Word is already started and the user chooses ‘File’ then ‘Open’ from the menu system, navigates to the document and then double clicks on it. From a problem investigation point of view these two scenarios are very different.
Before the Service Desk escalates any issue for investigation, First Line Support should check the quality of the information in the Incident Record.
A second step to take is to tackle problem categorisation. Incidents should be logged with a category based on the user’s experience and not the predicted cause. The top level should be:
• Performance (response time/throughput issue);
• Availability (service unavailable);
• Fault (error message);
• Incorrect Output;
• Functional (service is below expected functionality).
This approach overcomes the need for the Service Desk or First Line Support people to try to determine the cause up front. They will still have to make some level of assessment when the Incident Record is queued to Second Line Support, but at least the Incident Category won’t send them down the garden path. This approach also makes it more likely that multiple occurrences of the same issue will be identified rather than multiple Incident Records being opened, each with a slightly different category setting. Data recorded in this way and combined with service information would simplify the identification of incident trends and the detection of problems. Ultimately, incident categorisation based on predicted causing technology is simply not going to work.
The quality of the information captured by front line Service Desk people has a large impact on reactive and proactive problem management. The Service Desk and Problem Management teams need to work closely together. This will drive down the number of Incidents and enable Problem Management to provide the Service Desk with known error and problem information so that calls can be turned around without escalation to other teams.
Paul Offord’s Service Desk Wish List:
1. Add a quality gate to Functional Escalation procedures to ensure that First Line Support checks the quality of the information in an Incident Record before it is escalated to Second Line Support. The Incident Record should be checked for correct categorisation and quality of the problem description as outlined above. This action alone would probably save a large company a fortune in support cost.
2. Reconfigure the Service Desk system to add user experience orientated categories and subcategories for incidents as outlined above. Use these categories when opening incidents.
3. Change ITIL Service Operations Incident Management to suggest that opening incident categories are based on user experience and closure categories are based on cause or recovery action.
Indian call centre
• High priority Incident recorded as a network issue;
• Network problem causing intermittent application faults;
• Team of six working on the problem;
• Considerable time and money spent on investigation;
• After several months it was discovered that the user was actually receiving a JavaScript error;
• There was no detail of this fact in the Incident Record.
