Incident to Problem Linking

[FuITILity]

Hi All,

Quick question regarding linking incidents to problems.

Should all incidents be able to be linked to either an existing problem, known error, or solution? And in the absence of any of these, a new problem should be opened, correct?

Thanks!

[Diarmid]

That is the view of many including some very knowledgeable and experienced people. However the word "should", in the sense of mandatory, cannot be properly derived from ITIL as it is not prescriptive.

(I take it that by "solution" you intend a known solution not yet applied?)

I am not fully convinced of this approach. There are practical issues to do with the overloading of the problem register for example. Sometimes the cause of an incident is obvious and, while this can be erroneous, assigning that judgement to a suitably experienced person can obviate the need for further investigation with little risk.

I suspect it may be a valid approach in a larger organization where formal recording often needs to be in greater detail to keep track of what is going on and to compensate for the longer communication chains.

Certainly it makes good sense to consider whether there may be a sufficient underlying problem each time an incident occurs, and going to the length of opening a problem record and performing formal problem analysis is one way to guarantee that you do this. But the issue should be considered as a balance of risk against cost, and I don't think these are the same in all organizations.

One other point, incidents that have had a significant (by your customer's definition) impact would require greater attention (e.g. always passing to problem management), but incidents with little impact are also good candidates if there is uncertainty about the cause and its other possible consequences.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

[FuITILity]

Diarmid,

Thanks for the response. Here is my dilemma. Our company has taken a "good faith" approach when a problem record should be opened. That is, we rely on a multitude of support groups to use their judgment when to open a problem record. We work in a complex and very busy environment and doing the right thing is often thrown out the window in order to stop the bleeding elsewhere. Nor can it be easily enforced. We've elected to place our problem management enforcement points within the support groups, rather than centralizing it at the service desk.

Sure, there are obvious incidents that don't need problem tickets (such as a circuit outage where the carrier is going to come back with a 'no trouble found' for an answer), but it would seem to me if we switched to incident matching as a source for problem tickets we would centralize our enforcement point for problem rather than distribute it to the support groups. Either there is a known error, open problem, or solution (and for the example above of the circuit outage the solution could be as simple as calling the provider).

I would think that a company adopting the ITIL framework would see a vast number of problems in the beginning of the program, and then these would eventually become known errors, solutions, or more importantly, resolved.

My major dilemma is trying to show the cost benefit of problem management, but right now I can't even be sure we have the problem tickets opened that we should have opened due to our faith-based approach.

Thanks. For what it is worth, our IT department is 2,000+ in size. It's hard to trust the guy in the next cube much less getting 2,000+ people to do the right thing.

[UKVIKING]

then you need the following

a problem mgmt policy
a problem mgmt process
a problem mgmt procedures

then you link it to the incident and the change mgmt problem
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[Diarmid]

...
a problem evangelist
a big stick
and a problem budget!!!!

Adhocery on that scale is very expensive.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

[Diarmid]

FuITILity,

if I may go back to your use of the word "should".

In winning hearts and minds (probably your biggest problem) on such a scale it may not be wise to resort to ITIL as "authority". Rather focus on what Problem Management is for and what its value is.

Then work on the importance of control and of consistency. Place the responsibility for decisions on raising problems in a small subset of the staff (the Problem Management team, section managers, function managers, whatever works) and make sure these staff are focused on applying the policy that John advised you to set up, and are fully trained for the role.

As I said in my first post, formality is more important in larger organizations. Keeping the rules simple will also help. It is sometimes better (cheaper and less risky) to have overkill for some situations than to risk missing important issues. A highly focussed problem management team can sort out the mundane from the vital much easier than 2000 separate minds with their varying level of understanding of the bigger picture.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

[FuITILity]

Once again, thanks for the feedback.

So we have process, we have policies, and we have policy. And I've got a big stick and executive management's approval to use it.

We do have a small problem team. We average bout 2%-3% problem-to-incident ratio per month. That seems low.

Diarmid - Are you suggesting the problem team should take a larger role in identifying problems/trends in conjunction with the support groups?

BTW - Our incident management process is half-baked so this doesn't help either.

Thanks everyone, appreciate all the help/suggestions. I've been told to fix this so that is what I aim to do.

[UKVIKING]

You need to upgrade the Incident mgmt process so that the Problem mgmt process actually does PM

There are 2 kinds of PM

Reactive - find a incident/set of // that meets the criteria for PM and then trying to solve it

Proactive - finding things like .. hey O/S that is set to expire, single points of failure, systems, o/s and applications that are buggy and full of faults

PM can also be sub diovided into Application PM / Code mgmt
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[Marcel]

Let me start with echoing some of what Diarmid said. All incidents are indicative of having a problem. So from a theoretical standpoint a new problem should be recorded for every new type of incident. The reality however is that most organizations face constraints that don't allow them to do that. You will have to make choices and it is probably wise to provide some guidance for those choices.

For example you may say that a problem must always be open for:

- incidents that have a single major impact (say Priority 1 and 2)
- incidents that have a limited individual impact but that have occurred at least X times or that are likely to occur at least Y times per month if no action is taken

These would be the hard criteria for initiating a problem investigation. For all incidents that don't fall in these categories you could say that a problem investigation may be opened based on a case-by-case evaluation of cost/risk/benefit. You may even be able to provide some aspects that people should consider when they are contemplating opening a problem record. I believe it would be very challenging to catch all situations with hard criteria, but the more hard criteria you have, the less discussion there will be.
_________________
Manager of Problem Management
Fortune 100 Company
ITIL Certified

[FuITILity]

Thanks all. That is the approach I am taking. All high priority incidents are getting problem tickets, and chronic issues are also getting problem tickets.

One of the biggest challenges I do have is getting the right data available so chronic issues can be detected. We are looking at some new reports that might help.