Incident to Problem

[Phil Howlett]

We are about to roll out some notes to IT support users on how to promote an incident to a problem and what the criteria for this should be.

The users will be requested to use an email form to the IT Problem Management Team and we can then assess the information received and either or accept/reject and open the problem record if necessary.

Does anyone have a similar process in place and if so, what criteria do you use (repeat incidents, impact, users affected, time lost etc).

Many thanks for any responses.
Phil.

[ErnieB]

We have two criteria.

The first is simple--any non-critical incident which cannot be completely resolved within 3 business days is automatically raised as a problem. Incidents which are resolved with a work-around are also automatically raised to problem status.

The second involves repeat offenders. Any incident which occurs more than once results in opening a problem report. There are exceptions, of course, such as password resets and the like. Most problem reports opened for repeat offenders are closed, after review, with no action taken. The rest are worked as problems.

Impact, users affected, time lost, and other criteria are not used. The basic reason is to keep things simple. Adding many criteria can cause confusion as to whether an incident should be raised to problem status.

It's important to keep true incidents in the incident management process. If too many are incorrectly converted to problems (in order to reduce queue length or increase turn-around time), the weekly review of problems becomes a many hour ordeal that no-one wants to do.

[rjp]

Don't view PM as simple a 'fourth' level of incident escalation.

Work being done, is 'by definition' Problem Management when those doing it are investigating the root cause of an incident and applying changes to erradicate it.

In real Incident resolution, praticulary that concerning small break/fix incidents with standard changes applied, Problem resoultion is ocurring. Incident resolvers should be able to log and record this work in the Problem Management process.

You need a planned Problem Management process for intractible service disrutpion incidents, and for types of incidents which are ocurring repeatedly , regardless of the effectiveness of any available workarounds. But you also need to acknolwedge that often the only way to resolve an incident is to resolve the underlying problem, and allow that work to procede smoothly (and un-officiously) without undermining the difference between Incidents and Problems.

In short, the definition of a Problem is not: A service disruption that goes on too long or has too high an impact to be tolerated.

A Problem is the root casue of one or more incidents.

The critera you have described for creating is fine if you are actually switching to problem resolution at that point, but it sounds ecxlusive in a bad sense. What a about incidents that obviously need to be resolved "as problems' from the moment they are reported?

[taiger]

Hi,

we're thinking of making a problem record when an
incident has occurd that has ( or had ) a great impact on the
business when the root coase is not clear.

though it may be an incident, it might be an incident
that you're not want to see again.
In my opinion in this way you are working proactively

regards
Frank
_________________
"if you aim at nothing, that's what you're likely going to hit"

[Jules]

RJP said:

[rjp]

Jules,

to clarify... it was not my intention that a break/fix resoultion to an incident be logged in a PM record instead of an IM record - but that where appropriate problem management (and indeed change management activity ) of a simple nature should be recorded without overly officious procedures.

Eg. Someone reports a dead desktop. Incident resolver spotting scorching on the power supply correctly identifies the root cause (power supply shorted out) and implements a standard (pre approved) change by replacing the part.

Incident, Problem and Change Management activity has taken place here. I was suggesting all facets of the activity should be captured - not the IM activity alone.

However, this is merely an 'idea' and I am aware there are some gotchas here, and that, equally, it would not be sutiable in all environments.

[Jules]

RJP

Thanks; yes, I see where you are going, but I dont recognise a root cause analysis, hence no Problem process. The guy has an Incident - and found the fault - and from that he can jump straight to a Change.
In this example, I feel the best way to determine if a root cause analysis was done is to ask if the 'resolution' did anything to prevent repeat incidents of that type. So root causes might be:

*overheating lack of ventilation - (check environment)
* under spec equipment (review change process for adding periphs).
* manufacturing fault (identify batch, contact manufacturer)
* mechanical damage (secure cables)

- resolutions in ()

Preventing repeat incidents is one objective of Problem of course.

[Guerino1]

Hi Phil,

There is no hard and fast rule, here. What's important is that you're capturing everything and using it to drive controlled work.

Many of the companies we help with this problem, especially the larger ones, like to view Incidents as a way to record "disruptions" associated with an End-User's experience. They use Problems as a way of documenting a potential or known "defect" in a product, service, or environment that will most likely require "Change" at some point.


Most of the companies we deal with use three primary drivers for Changes: 1) Problems, 2) Risks, and 3) Requirements. They like to think of a Problem as something that is "known to be wrong" and that must be fixed to avoid it from reoccurring. They like to view a Risk as a "potential future Problem" that they want to avoid. And, they like to view a Requirement as a "request for something new" (Although, if you think about it, Problems and Risks that drive work are actually requirements, too). Incidents, on the other hand, tend to be viewed as drivers for Problems, Risks, and new Requirements.

FYI, there is no section to cover Requirements, in ITIL, nor does there appear to be a clear linkage between Risks and Changes. While ITIL is a great place to start, there appear to be some very significant gaps in it, as it doesn't cover the whole process associated with managing bigger picture IT operations. It's strictly intended for the support side of IT operations and, therefore, leaves things out of the bigger picture. Use your common sense to address that picture. Look to things like ITIL, RUP, MSF/MOF, etc. as guidelines and not defacto standards, since not one of them, alone, is perfect.

If you're interested in some of the reference information we have, please feel free to contact me, either through this site or directly. I'd be glad to help out.

Again, there is no hard and fast rule. Just common sense. Good luck with all of this.

Regards,
_________________
[Edited by Admin to remove link]

[rjp]

Frank,

good post, and I agree that practical concerns are paramount. On this forum I allow myself space to focus on the theoretical because it is an ideal space for it, and balances out the challenges of my more practical working life.

One (freindly) disagreement - ITIL does address 'requirements', in a few places - In the the Service Level Management chapter of Service Delivery, as well as in the Infrastructure and Application Management books.

Lifting management understanding of SLM from drafting SLAs and monitoring the 'nines', to the key process area where services are assessed, planned, and developed in partnership with the customers - within a formal business cycle - is a constant challenge for me, and one that has only seen small incremental gains.

[Guerino1]

I stand corrected. Thanks for the info. I will check it out.

Regards,
_________________
[Edited by Admin to remove link]

[Globis]

[entivo]

This is an interesting thread. We use CA Unicentre as our service desk tool where an Incident ticket can have a status of Open, Closed, Awaiting Supplier, Hold - Pending Change, Hold - Pending User, Fix In Progress, Researching or Service Desk Follow-Up.

It is suggested that an Incident status should be changed to Resolved when a new Problem record is opened to identify the root cause. After all, Incident Management is concerned with getting service resumed asap.

I am toying with the idea of including a new Incident status of "With Problem Management" to identify incidents that have triggered problem records because I don't think the end-users will understand the difference between incidents and problems and when they get an email stating that their incident has been resolved they will probably not be happy especially if they know they have been issued a temporary work around.

The trouble with this new status is that the incident remains open, when in reality it is resolved and merely being looked at by a different team.

Any opinions or feedback would be welcome.

[UKVIKING]

You can do what you want witht the tool

The use of a flag to say that the incident is still 'active' not closed and has been refered as a candiate for a problem record is a good thing

The problem (nice phrase) --- the issue I see is that a lot of companies intermingle incident and problem and forgot that incident management does have some diagnostic and troubleshooting

Problem mgmt should be used when the IM diagnostic and troubleshooting can not restore service (other than reboot - grin- which works with microsoft products always. TG MS is not used for flight control)

PM should be used to find 'real problems'.

NOTE: The issue about the bad power supply frying the computer. I dont see why a problem record / prob mgmt process beign invoked. Unless this is the Nth desktop in that office which has blown. then there is a 'problem'

And Changes can result from Incident as well as problems. They are usually called emergencies ;00
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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