Problems Implementing the Incident Management process

[kimberlito]

Hi all
In your opinion, what are the major problems of implementing an Incident Management process? Is it the organization culture (people resistant to change)?

I dont think that implement an incident management process is just about getting an ITIL compliant tool and thats it!

Any experience or ideas?
Tanks in advance
_________________
Kimberlito
Service Desk & Incident Management Project Leader.
ITIL Foundations Certified

[dam]

Hi kimberlito,

It’s not possible to answer to this question, the first problem is that you have to have a clear idea about WHY do you want to implement the incident management process.

To improve your customer level of satisfaction?
To be more efficient in problem solving?
To be able to measure the quality of the service you provide?
To improve the internal company’s governance?

Once you have some clear objectives in your mind implementation obstacles become much more evident.

Good luck,
DAM

[kimberlito]

Tanks for the anwser dam,

My biggest goal in implement incident management is, as you said:

- To be more efficient in problem solving;
- To be able to measure the quality of the service I provide;
- To improve my customer level of satisfaction.

and...

I want to make RULES. In my job, there are no rules. Everybody enters my office and ask me "Hi Rui, please I need this, I need that, etc. etc..." and in some cases, my mind cant save all the requests wich result in forgotten incidents!

The main cause is that I work with Pharmacists, ie, very intelligent people, but with very little knowledge in IT, but... They are scientists! Thei dont have to be specialist in IT! They have to be specialist in Chemistry, matemathics, etc.!
And thats it!

Once again, tanks for your reply
_________________
Kimberlito
Service Desk & Incident Management Project Leader.
ITIL Foundations Certified

[Guerino1]

Hello Kimberlito,

We find that the biggest biggest problems associated with implementing Incident Management are "terminology" and "understanding". Very few practitioners we've come across truly understand that enterprises already perform Incident Management all day long, every day, in each and every environment. As a result, they fail to communicate that what they're trying to achieve is "not" to implement a new concept but, rather, to take what is existing and standardize, centralize and optimize it... as well as helping everyone understand "why" you would want to achieve all of this.

Believe it or not, even the ITIL authors didn't get that Incident Management is an old concept and that it is already performed all day long by all groups, in all environments, in all enterprises. As a result, the ITIL documentation all focuses on implementing very limited forms of Incident Management, in the Production environment, only. This limitation adds to the confusion, when trying to convince an enterprise that they should do something in Production but not in all other environments... or that they should do something in IT but not in other parts of their business.

In any case, we find that a practitioner who understands how to educate stakeholders and provide solid justifications for "understanding" has a much higher probability of success than one that doesn't. The experienced practitioner will be able to get existing stakeholders that they're really not doing anything that is much different than what they're already doing. Instead, they will simply be "formalizing" what they're already doing, by centralizing where they create, track and manage their information, so that the greater enterprise can benefit from such information.

By the way, the "why" of implementing ITIL is rather simple... ITIL is about "transparency" and getting consistent data about your enterprise so that you can use it to "steer" your enterprise. That is, to constantly optimize and improve your enterprise. Leaders cannot accurately drive the enterprise without accurate data/information about it. ITIL provides the information that helps feed the dashboard that the driver requires. What many practitioners fail at is translating this why into a solid business case that shows a true financial return on investment (ROI). I believe that understanding how to create and write business justifications is also a very critical part of being successful.

Anyhow, I hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL Platform

[dam]

Hi kimberlito,
I truly agree with Guerino1, that has raised a very crucial point. When you decide to adopt ITIL you are not reinventing the wheel, just trying to organize a well established incident management practice.

How to proceed? I give you my point of view.

You (or your management) understand that service support needs to be improved.

How can you improve the level of your service support? ITIL gives you some good ideas, but don’t forget that to make your project successful you have to be able to demonstrate to the outside world (management and peers not directly involved in support activities) that your project is improving things.

The only way to do this is to produce numbers that speak for you.

Indicators
Metrics
Key Performance indicator
Critical Success Factors

To be able to do this you have to track all the activities of the service desk. (on paper, on an excel sheet, using a dedicated tool etc…)

If you work out this in a simply but clever way (setting up a couple of good metrics to follow, like average resolution time of an incident by priority, % of incident resolved directly by the service desk with no functional escalation) you can produce a positive retro-action:

Motivate your peers to track formally all their support requests (and so get into the process you have established) because you will use this information to produce stats. So “no more cases will be treated if not tracked ”

Motivate management to invest in your project because they see numbers that speak and even hopefully, trends that motivate (like average resolution time decreasing after six months)

Then the more you get interest and appreciation around what you do, the more you can ask to the others.

Hope this can help,
DAM

[kimberlito]

Guerino1, Dam, tanks for your replies.
I really appreciate your answers.
Good point of views.
_________________
Kimberlito
Service Desk & Incident Management Project Leader.
ITIL Foundations Certified

[Marcel]

In addition to the valid points already addressed by others, I would like to share a few practical challenges that I have encountered in almost every organization where I was involved in implementing an ITIL based incident management process:

1) IT staff often has a hard time differentiating between incidents and problems as per ITIL’s definitions. ‘Problem’ is the common word in spoken language to indicate something is broken that needs to be fixed, but in ITIL ‘problem’ has a very specific definition. It takes a lot of repeated communication to make people understand these concepts and it is important that the ‘messengers’ who bring the store are very consistent in their use of terminology.

2) For a long time you will find people leaving incident tickets open until the root cause has been resolved, even though a perfectly fine workaround was already put in place. Again, this is the result of not differentiating properly between incidents and problems. You will need to put metrics on incident resolution time and follow up with groups/people that frequently miss the target resolution time. This may help you detect the situation I described.

3) Incidents are often categorized using schemes like CTI (Category, Type, Item). Make sure that your CTI is a consistent global structure that is maintained centrally. The various stakeholders can provide inputs, but these will need to be reviewed centrally before they are entered into the structure. If you don’t do this, you will soon end up with a mess that will make it difficult to create valuable reports across the board, as many groups will try to set up ‘their’ piece of CTI only to meet their own needs.

4) Some organizations try to enforce certain behavior through the tools they implement, for example by making fields mandatory. I have seen this fail in many cases. There certainly are some things you want to enforce through the tool, but often it is better to enforce things through procedures combined with reports that demonstrate adherence to these procedures. This will help you to make people accountable.

5) Many IT staff members consider logging tickets for incidents an administrative burden. Many will try to avoid it, while others just log the bare minimum with poor quality tickets as a result. Don’t be surprised to find tons of tickets where the resolution is described as ‘this has been fixed’ without actually saying what was done. Make sure that people understand why it is important to log incident tickets and to do it well. Plan periodic reviews with each group where you discuss the content of a sample of their tickets.