Troy's Blog

ITIL Implementation Roadmap (Incident Management / Service Desk) – Part 3

A Relatively Quick Win

Most organizations will start with fixing the Incident Management process and the Service Desk function first. I use the word fix on purpose since just about every organizations already have these basic support elements in place at some level. Making small changes such as applying a policy of end-to-end Incident Ownership makes a significant improvement in the process. From another perspective it is difficult to address the more proactive processes within IT unless you stop the Service Desk Horror stories and the CIO from getting consistent calls from the business about issues that have been dropped by IT Support.

The interesting thing about the comment, “Service Desk Horror Stories” is that it is rarely the Service Desk which is dysfunctional. In an organization where the ownership for an Incident ticket is passed to the group handling it the proverbial clock starts ticking from the beginning each time it is bounced from group to group. If no one owns the ticket through its full life-cycle there is no interested party monitoring the user experience.

What ends up happening is that the incident is received at the service desk, it logged as a ticket into some tool which is then assigned into the black hole of IT where it is not seen or heard from again until someone with enough authority escalates it to Sr. Management attention. This situation is often perceived as the fault of the Service Desk agent which leads to unfortunate name calling of the Service Desk function and in extreme cases an outsourcing decision. The irony of this situation is that while they have outsourced the front end of the process to an external provider no one has fixed the black hole issue. All that has been achieved is getting someone else with an external brand to yell at.
The processes and functions related to supporting the business are a core element of the IT organization as well as the most visible process to the end user.  Most organizations have a formal support function established with a process to fix things already in place at some level of maturity.  Improvements in this process are relatively quick to obtain with high benefit to the business customer.  The implementation of this process is typically seen as a quick win relative to other processes without requiring major organizational change.  For these reasons, Incident Management is almost always a starting point for an ITIL implementation program.  Examples of typical levels of implementation would look as follows:

1. A formal function is in place to receive user calls and register them in a call tracking software. There is no real distinction between incidents, service requests, and informational requests. Reporting accuracy is limited due to the inconsistent classification and update of records. At this level of maturity there are little to no process dependencies.



2. The next level of maturity is typically represented by the following description.  In addition to having a formal function in place to receive user calls, a defined process has been established which documents how calls are received and classified in accordance with documented policies.  Incidents, Service Requests and Informational Requests are registered as distinct process objects.  Defined polices include:


1. An agreed prioritization model considering impact and urgency
2. An agreed assignment, escalation and notification model
3. An agreed record classification structure, which includes a component, type, item classification as well as a closure code indicating a probable source of the incident.



3. A mature implementation of Incident Management includes the previous examples and is practiced consistently across all functional areas.  The process is seen as an organizational activity as opposed to the job of the Service Desk.  Incidents are registered from other areas that do not have a user impact, including computer operations and network management events.  The Service Request process is seen as a type of change request and is dealt with in accordance to the policies defined under Change Management.  The definition of “Significant Incident” and the trending of repeat incidents are done in support of Problem Management.  Obvious dependencies for an Incident Management process at this level include Change and Problem Management.

While many organizations start with the Incident Process they also address the Change Management Process in parallel.

On the next post we will look at Change Management.

Troy’s thoughts what are yours?

“The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair” ~Douglas Adams