I have been doing Problem Management for a couple of years. We need to draw a line in the sand on when is a Major Incident really a Major Problem. Does anyone have any guidelines that you use on determining when a Major Problem is really a Major P

[mindyhynes]

Does anyone have any guidelines that you use on determining   when a Major Problem is really a Major Problem?

[Michael Fry1]

When you need to provide Root Cause Analysis to the customer as to what happened, why did it happen, and what changes you are making to prevent it from happening again. We don't 'work' the Incidents from Problem Mgmt, but once resolved, we might relate them to a Problem for record ref, and provide RCA. Problem mgmt shouldn't hold up Incidents from being resolved, but a Change might.

[mindyhynes · Accepted solution]

Okay, 2 examples for you that resulted as major problems.

1)   Water leak in a closet

2) External - 3rd party vendor had an outage

[Michael Fry1]

Not everyone does it the same, but . . .

1) water lead in a closet: were systems affected? did any Incident(s) get triggered because they went down/damaged/etc from the water? does affected customers need RCA or simply water pipe broke? if affected systems, parts need to be ordered, systems fixed - seems like Incident Mgmt to me until resolved.

2) External - 3rd party vendor had an outage. - guessing you are doing their monitoring and a bunch of Incidents got created, but do you owe them a reason why this happened (thinking RCA), probably not.

All of this makes me ask, are you using Parent/Child under Incident Mgmt? You could link all the tickets together (like Problem Mgmt) but Incident Mgr owns them until resolved.

Again, many doing it differently. Incident mgmt owns them until resolved, then Problem Mgmt provides customers with RCA - when and where needed, mostly P1s.

[johnbarber_now_]

Hi Mindy,

The difference between incident and problem is key here. Incident = Current Service Degradation or Outage that need to be resolved, Problem = Correlating many INT's around a single specific root cause of those incidents.

So it is a major incident as long as there is a service impact as soon as one restores service back to "normal performance" the incident is then over. If say it happens again an 4 hours later, one would log a new incident. If you know which PRB then caused both incidents, one would associate the INTs to that PRB.

A Major Problem then is a culmination of the Incident data, and using that incident data you can determine what would qualify to you as a Major Problem in your organization.(For example, How many INTs are associated to the PRB, what is the Priority of the INts getting associated to the PRB)   If you have interest in determining PRB priority using associated INT data, then please see my comment on this community post:

https://community.servicenow.com/thread/230880

Hope it helps,

John B