Problem raised to investigate an incident

Discussion on issues related directly or largely to ITIL problem management.
Post Reply
User avatar
mvbc85
Newbie
Newbie
Posts: 2
Joined: Tue May 17, 2016 8:00 pm

Wed May 18, 2016 3:05 am

Hi guys,

I'm new to ITIL and I'm currently working in reducing our huge queue of open problems.

I've noticed that a lot of these problems were raised after a single incident only because the user was not happy with closing the incident until more investigation was done regarding the root cause.

Is this the right way to proceed? These are usually low priority incidents so the problem never gets any attention and it just sits there forever.

It seems like the problems should not have been created in the first place and maybe the user should have been told that sadly other incidents have a higher priority and we just can't do a root cause analysis on this at the moment.

Any advice on how to tackle this type of situations?

Thanks for your help :)


User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3639
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Wed May 18, 2016 2:24 pm

You have been hit by one of the most common mis usages of ITIL processes.

First. :Lets talk about Incident Management (IM)

IM goal is to restore the service. Not provide an explanation as to why it happened.
The action that is taken to restore the service is usually all that is required

Service disabled.Server rebooted.
Done. next Incident

Problem mgmt is time consuming and may not result in a solution as the reason may never be known.

The process for PM is in two parts - Reactive and Proactive

Proactive - is when yo look at tyour infrastructure and find Single points of failures or weak IT assets that can or will cause incidents and replace them

Reactive is taking the conditions of a incident (set of incidents) and try to find out the why it is happening.

The way it should go is as follows

An incident is created - the team working on it works to restore the service.
As part of that - they say.. hey this incident should be looked into as a problem.

This is a problem record candidate

The PM Manager would have a set of criteria as to what Problems are going to be worked on - and how much time is to be spent on each and record how much time has been used trying to find the underlying root cause.

Incidents have SLAs
Problems dont.

So if there are 200 PM candidates, the PM manager - says you work on these 3 or 4 and rejects the rest.

This should be stated in your policy documents
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
User avatar
mvbc85
Newbie
Newbie
Posts: 2
Joined: Tue May 17, 2016 8:00 pm

Thu May 19, 2016 12:56 am

Thanks a lot for the reply, UKVIKING

It all makes sense, and hopefully we'll get to a point where we'll be able to work like that.

For now the main question that I have is about managing the user's expectations.

Should the team push back and let the user know that finding the cause for a low priority one-off incident will not happen?

Or should problems be automatically raised as soon as the user request it and then the Problem Manager have the task of communicating with the user in the case that their problem will not be worked on?

In this case all the users are within the same company, so I would expect them to understand if they are not at the top of the priority list, but maybe that's just wishful thinking
User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3639
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Thu May 19, 2016 1:55 am

First, are you an internal service desk or do you provide services externally.

Either way, you need to produce a document explaining the purpose and goal of IM and PM

In addition, PM work should be well defined
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Post Reply