Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
· Home
· Content
· Feedback
· News
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: Nikolaylrow
New Today: 5
New Yesterday: 26
Overall: 231716

People Online:
Visitors: 150
Members: 1
Total: 151 .



Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

NOTE: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - Incident to Problem
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Incident to Problem

Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  
Author Message

Joined: Mar 05, 2009
Posts: 13

PostPosted: Fri Mar 06, 2009 4:49 pm    Post subject: Incident to Problem Reply with quote

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.

Back to top
View user's profile
Senior Itiler

Joined: Feb 23, 2005
Posts: 458
Location: London

PostPosted: Fri Mar 06, 2009 9:23 pm    Post subject: Reply with quote

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.

Did I just say that out loud?

(Beige badge)
Back to top
View user's profile
Senior Itiler

Joined: Mar 04, 2008
Posts: 1894
Location: Helensburgh

PostPosted: Fri Mar 06, 2009 10:12 pm    Post subject: Reply with quote


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
Back to top
View user's profile Send e-mail

Joined: Mar 05, 2009
Posts: 13

PostPosted: Mon Mar 09, 2009 6:59 pm    Post subject: Reply with quote

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. Laughing
Back to top
View user's profile
Senior Itiler

Joined: Sep 16, 2006
Posts: 3597
Location: London, UK

PostPosted: Mon Mar 09, 2009 7:25 pm    Post subject: Reply with quote


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
Back to top
View user's profile

Joined: Sep 11, 2009
Posts: 3

PostPosted: Fri Sep 11, 2009 3:22 pm    Post subject: Reply with quote

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
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management All times are GMT + 10 Hours
Page 1 of 1

Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003

Forums ©


Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.