Pink Elephant
The IT Service Management Experts

Troy's Blog

The Hitch Hiker's Guide to the ITIL Galaxy and Beyond
Don't Panic

Home

Author

Troy Dumoulin Photo

Troy DuMoulin, VP, Research, Innovation & Product Development

Troy is a leading ITIL® and IT governance authority with a solid and rich background in Executive IT Management consulting. Troy holds the ITIL Service Manager and Expert certifications and has extensive experience in leading IT Service Management (ITSM) programs with a regional and global scope.

He is a frequent speaker at IT Management events and is a contributing author to multiple ITSM and Lean IT books, papers and official ITIL publications including ITIL’s Planning To Implement IT Service Management and Continual Service Improvement.

 

The Guide

"This blog is dedicated to making sense out of the shifting landscape of IT Management. Just when we thought we had a good handle on managing technology, the job we thought we knew is being threatened by strange acronym’s like ITIL, CMMI, COBIT, ect.. Suddenly the rules have changed and we are not sure why. The goal of this blog is to offer an element of sanity and logic to what can appear to be chaos."


Hitch Hiker's Guide to the Galaxy

"In many of the more relaxed civilizations on the Outer Eastern Rim of the Galaxy, the Hitch Hiker’s Guide has already supplanted the great Encyclopedia Galactic as the standard repository of all knowledge and wisdom, for though it has many omissions and contains much that is apocryphal, or at least wildly inaccurate, it scores over the older more pedestrian work in two important respects.

First, it is slightly cheaper: and secondly it has the words DON’T PANIC inscribed in large friendly letters on its cover."
~Douglas Adams

Syndicate

Troy On Twitter

Recent Entries

Categories

Links

Other Blogs

Archive

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

 

Posted by Troy DuMoulin on 01/15 at 10:48 AM
  1. Well thanks for sharing this useful piece of information. It is really very helpful.

    Posted by server management service  on  05/30  at  03:22 AM
  2. Page 1 of 1 pages

Name:

Email:

Location:

URL:

Smileys

Remember my personal information

Notify me of follow-up comments?

Please answer the question asked below:

A, B, C, D, E, _, G, H. What letter is missing?