Posted: Fri Mar 06, 2009 4:49 pm Post subject: Incident to Problem
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.
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?
Joined: Mar 04, 2008 Posts: 1884 Location: Newcastle-under-Lyme
Posted: Fri Mar 06, 2009 10:12 pm Post subject:
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
Joined: Sep 16, 2006 Posts: 3190 Location: London, UK
Posted: Mon Mar 09, 2009 7:25 pm Post subject:
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
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
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum