Problem Record Criteria

[tolman101]

Hi all,

I'm trying to figure out how to get started with Problem Management, and I figured that the Problem Record criteria would be a good place to start. I thought it would perhaps be the way to start thinking about when we need a PR. Then we would know how many PR's we might expect and if we have the resources to cope.

Does anyone have any thoughts on this?

cheers, Matt

[JoePearson]

Hi Matt
If I read you right you are thinking of defining the criteria for creating a Problem Record. That's a good step, but you'll have to steer it to answer how many resources you need.

Why does ITIL recommend distinguishing incidents and problems in the first place? So that you (management) can make a decision to split resources between getting incidents (user service) resolved as quickly as possible and getting problems (root causes) resolved as well as possible.

You could look at your incident logs and identify
1 - incidents that were fixed with workarounds. These are obvious candidates for raising as problems. There may be similar but less obvious cases where the incident was fixed, but there was some concern about quality - basically any case where the incident staff know or suspect that a root cause has not been addressed.
2 - repeat incidents. They may be a better resolution to some incidents than frequent password resets or frequent server reboots. An issue you may face here is that identifying repeat incidents is itself a Problem Management activity that you might require some planning to justify
3 - trends of incidents. Similar comments apply.

You can also look at proactive problem management, like analysing stats and logs for quality issues that could be raised as problems even when there has been no Incident yet. But the above could be enough to start with.

Take care with how you go forward - don't raise all of these as problem records if that will create the expectation that they will be worked on (ie enter problem control, the process of finding the root cause). Maybe you don't have enough skilled staff to do that. And that's your final criterion: a Problem is something the organisation decides to invest resources in fixing to a better quality and depth (root cause) than incident resolution.

Joe

[eisbergsk]

Hi there...
I've mentioned this in other posts, but I love the sound of my own typing

Based on the incident volumes recorded in your Incident mgmt DB/Service Desk tool, bite off a chunk you can chew.
Here, that translates to 'Severity 1' (high severity) incidents, which works for a number of reasons (high enough profile that you can stress the company's business and deflate 'why are you picking on me?' and other silo-like attitudes.) Based on the past 6 years of doing this I can say that it pays off, too. And yes, I'm it for PM.

If I ever get this chunk chewed and swallowed, I'd like to address incidents that cannot be solved at first point of contact. These are more expensive to the company than incidents handled at 1st point. These can be divided by region, group - whatever it takes to reduce it to reasonable size. I also have an established process that can be followed if the role is ever expanded to other people doing this. but hey, I'm an optimist.
Best regards,
/Sharon

[tolman101]

Thanks for the tips guys. I have searched through the PM section a little closer and picked up quite a few tips to get going. I thought I would start with the following criteria and then expand on it as we move forward...

High impact/urgency Incident is recorded
Monitoring events that might lead to a future Incident
Workaround or temporary fix is not available
Repeat Incidents
Unsustainable workaround

Also something that sounded very interesting was a post from Frank Guerino suggesting a cooperation between the PM and the Product/Service Owners to add some strength to the process.

[Marcel]

Matt,

Before you start working on your criteria to raise a problem ticket, you should decide how incident and problem management link together. As you can surely find in other posts on this forum, there are different approaches. The main scenarios (with combinations in between) are:

A) An incident is resolved by incident management, all the way till service restoration, even if this means that incident management has to develop a solution or work-around, or even has to find the root cause. Problem management is an "after-the-fact" thing that starts once the service is up and running again and that is mainly focused on preventing the incident from happening again.

B) Problem management can kick in at various points during the incident management process, e.g. when it is a major incident (requiring the best-skilled staff to work on it), or when no work-around or solution is available. The incident ticket remains open till problem management comes back with the work-around/solution (i.e. the problem control part of problem management has been completed; there is a known error with a work-around/solution), which is then implemented, after which the incident ticket can be closed. Problem management then continues with error control to eventually eliminate the root cause.

Based on these scenarios, you will probably see that different criteria apply. In scenario A, you will only raise a ticket after a single incident with a major business impact (high severity), after repeated incidents that have a significant accumulated business impact, or when proactive measures are required to prevent incidents from happening (e.g. based on trends found by event management). The criteria you listed with regards to the availability of work-arounds or temporary fixes, would only be relevant if you implement incident and problem management in accordance with scenario B.

Bottom line: determine your scenario and then define the relevant criteria.

Marcel

[tolman101]

Hi Marcel,

Thanks for your input. I would be say that senario B is the way that IM and PM would link together in our organisation. The two processes would run in parallel. I believe that this is the ITIL way too.

Best regards, Matt