Incident to Problem

[IceCreamMan]

Firstly , let me intro myself. I currently work for an ISP in South Africa and have been recentloy appointed as PM. We are in the process of setting up all the policy ,process ,procedures etc for PM. PM was practised previously but not close enough to the standards hence the shake up.

Yesterday we had an interesting debate around the following point, both sides had valid arguments and left it up to me as PM to decide.

Do the incident(s) have to be resolved PRIOR to a problem being logged or can incidents be unresolved with a problem investigation running concurrently?

I dont want to influence any thinking so wont mention any arguments or the way i think it should be.

Cheers

[UrgentJensen]

Hi IceCreamMan,

Think about the definitions: an incident should stay open as long as the 'interruption to normal service' continues. The problem may have been logged in the mean time and run and run until the root cause has been identified and resolved/accepted.

You only close the incident once normal service has been resumed or an acceptable work-around has been implemented.

These two processes should run in parallel, not serial, though typically an incident may be closed before a problem.

Hope that makes some sense, I'm incredibly drunk at the moment.

UJ[/b]
_________________
Did I just say that out loud?

(Beige badge)

[Diarmid]

IceCreamMan,

think of the following scenario:

1. incident occurs
2. incident resolved
3. problem raised
4. new incident occurs related to same problem

Now, do you delete the problem, resolve the incident and then raise the problem again?

Worse still, if you raise a problem in anticipation of incidents, but before any have occurred, do you close and start again if an incident does occur?

What I am trying to illustrate is that your question implies an invalid relationship between incidents and problems. Incidents are managed as they occur. Problems are raised when they are identified (irrespective of incidents).

Perhaps there is a resourcing issue? then, generally, incidents take precedence.

Perhaps you hope to get more information out of the incident resolution? Then build that in to your problem management plan.

It also strikes me that very few, if any, incidents should be unresolved for long enough for it to matter. By the time you have sufficient information to decide that there is a problem, I would expect the incident to have been resolved in almost every case. And in the exceptional cases, incident and problem nearly become the same thing because the more you cannot restore service the deeper you dig.

Take another extreme scenario:

It's the third time this has happened since midnight.
We don't know why.
It takes three hours to get it up and running again.
Let's wait those three hours before we get down to problem analysis - I don't think so!
_________________
"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

[IceCreamMan]

Thanks for the replies. That is certainly my interpretation of it.

The "close incident" group were certainly very vocal about it and even furnished some white papers to illustrate.

Being a service organisation we have to be flexible and able to respond quickly if required.

Thanks again

PS: UJ , drunk on a Friday night ,whats the world coming to.

[UKVIKING]

ICM

Please use this concept

The incident team can open, deal with and close as many incident tickets as they like
It has no bearing on PM

The PM team - reactive - receive candidates for new problem tickets from the incident team or their mgmt. BUT It is up to the PM reactive team to decide whether the candidate receive meets the criteria for a new PM ticket

The PM team - proactive - ignores IM and the other PM group... they look for trend, single points of failure or poor design / equipment and try to come up with solutions


there is a couple of deep threads abotu PM
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[Bec74]

Hm mm we have a fairly vocal internal school of thought in my org. that like to close incident/s and open a problem ticket instead...without workaround or service restoration.

ITIL is fairly clear on this point and I agree with posts above.

Their logic (not mine though as a PM!) is anything from 'too many incidents' to 'been around for ages'.... when I question why these are in the queue for 'urgent fixes'.

In my view.. this is SL cheating at worst and hiding resource shortages at best.
_________________
If you cannot find a root cause, make one up. Either you will be right or everyone will scramble to disprove you.. either way you will be further ahead