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: Lblawfhz
New Today: 35
New Yesterday: 33
Overall: 231683

People Online:
Visitors: 86
Members: 1
Total: 87 .



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 Mgmt --> Problem Mgmt
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Incident Mgmt --> Problem Mgmt

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

Joined: Feb 01, 2006
Posts: 15
Location: Leeds, UK

PostPosted: Wed Feb 01, 2006 8:47 pm    Post subject: Incident Mgmt --> Problem Mgmt Reply with quote

Hi guys.

I'm trying to implement an ITIL-like structure here, and I'm having a bit of trouble. We sell software (and very occasionally, complete solutions including hardware) and support it, mostly X.400 stuff but a couple of other interesting products. We have a service desk staffed by four techies, above which is a Support Manager, and I guess our support calls are pretty standard for software support.

The problem is that mapping the generic processes defined in ITIL to our business is really proveing to be quite difficult for me to get my head around!

The Incident Management process involves detection/recording, classicifation/initial support, investigation and diagnosis, resolution and recovery and incident closure. But when does an Incident become a Problem? Am I the only one having trouble understanding this? I'm supposedly ITIL certified, for crying out loud!!

Lets say the investigation / diagnosis phase reveals, atfer some explanation, that the issue is caused by a corrupt Message Store (X400 terminology), an easily resolved fault. The way we work at the moment this would probably not even go in the database, although I know this is bad news.

I have a diagram from ITIL which shows a "circumvention/diagnosis" decision, which is eithere answered "no" (in which case more support should be allocated and the decision repeated) or "yes" (in which case it goes to Problem Management to create a Problem or Known Error. Doe this mean that every Incident will either be linked to a problem, or become one?

I was under the impression that for minor issues, Problem Management was not required, but I don't see how this is covered by the procedures defined in the Servcie Support book - as I say, these flowcharts seem to imply the permenant involvement of Problem Management.

Any help will be greatly appreciated, we're in trouble here - we have about 4 weeks to do a full ITIL implementation, everything from procedures to setting up the CMDB!
Back to top
View user's profile Send e-mail Visit poster's website

Joined: Jul 26, 2005
Posts: 42
Location: Northern Virginia, USA

PostPosted: Wed Feb 01, 2006 10:38 pm    Post subject: Reply with quote

Incident management’s task in life is to get the customer back working. If an incident occurs more than once, or is quite severe and could well appear again, then it is a problem. The goal of problem management is to cut down the workload of incident management. If there are less incidents, there are more people working, thus greater productivity. Darn, almost sounds like a business case!

I might add 4 weeks to implement ITIL shows a grave lack of understanding of what ITIL is. It requires a cultural change, akin to everyone having to learn a new language. Good luck!
Back to top
View user's profile Send e-mail

Joined: Feb 01, 2006
Posts: 15
Location: Leeds, UK

PostPosted: Thu Feb 02, 2006 1:47 am    Post subject: Reply with quote

The way that we work already was brought up to ITIL standards several years ago before I was here, but some key people left, and the support desk ended up with too much autonomy and it kind of got forgotten. So the way we work, the system we use and so on are not too far away from ITIL, there's just some procedures that need redefining.

We're donig this because the customer demands it (BIG customer), which is not the best way to lead an implementation, but what it does mean is that we only need to worry about the Service Desk, Configuration Mgmt, Incident Mgmt, Problem Mgmt and some Change Mgmt. Availablity and Capacity will have to come, but not yet thankfully!

You're gith about the good luck, we will need it - I think this is going to turn into a project of "How to make a company LOOK like it's working to ITIL standards". We'll see how long it lasts, hopefully long enough to ge the real implementation done!!
Back to top
View user's profile Send e-mail Visit poster's website
Senior Itiler

Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Fri Feb 03, 2006 11:06 pm    Post subject: Reply with quote


I think a key to your struggle is in the part of your qestion that asks when an incident 'becomes' a problem.

Incidents and problems are two separate things in ITIL, and an Incident never actaully becomes a problem. So there isn't a severity or impact threshold or a category, or any other event or measurement that provides a rule whereby an incident is then considered a problem.

Incident are raised and resolved. Problem management uses the incident records as (one) starting point in identifying, prioritising and investigating problems.

They run in related but separate processes.

You will still need to work out how you are going to implement each process in your own site - but have a second think from the point of view of two different things and two supporting processes - it might help.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger

Joined: Feb 01, 2006
Posts: 15
Location: Leeds, UK

PostPosted: Mon Feb 06, 2006 7:11 pm    Post subject: Reply with quote

Thanks for that. So in fact, it is more accurate to say that for minor problems with low urgency/impact, Incident Management is not required, at least not all of it. For example, we sell a lot of X.400 software, which is secure and robust messaging, an alternative to SMTP. Quite often, our customers will have a problem with one of our servers, but without urgency or impact. A lot of our customers are government / military departments with such low importance and such high system redundancy that systems are often offline for months. When this happens, we don't really need to implement workarounds and worry about the Incident, instead we just get straight on with the underlying Problem.

When this is the case, is the Incident left open until the Problem is solved, or should it be closed with the status "closed without resolution - no workaround required"?

Also, if an Incident is defined as a loss of service, and a Problem is the underlying cause of one or more Incidents, does that mean that every single Incident has to have a corresponding Problem? Surely if a user's keyboard falls out of the PS/2 port, it is slight overkill to invoke Incident Management and Problem Management...

Thanks a lot - this site seems to be getting a slightly larger patronage, it would be a good site with a few more attendees. We need a decent ITIL forum!
95% of computer problems are easy to solve, but most of the problems are in the other 5%
Back to top
View user's profile Send e-mail Visit poster's website
Senior Itiler

Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Mon Feb 06, 2006 7:59 pm    Post subject: Reply with quote


by definition every single incident will have a cause and therefore an underlying problem.

But the cause may be PBCAK (Problem Between Chair and Keyboard) - you may not want to set your Problem manager to investigating a faulty end-user.

(Though bear in mind if lots of end-users are struggling with something the incident is significant and the Problem might reveal an error in a manual, or training program.)

So yes, definitely, not all incidents will be sent to Probelm Management - It's OK to raise an RFC directly or simply carry out a change - it is recommended that only standard, pre-suthorised changes be carried out at incident resolution (usual simple break/fix replacements).

It also may be the case that incidents are never resolved, just for the reason you indicated - low impact or urgency. But it is the Probelm Manager's call to decide that a workaround is sufficient - and the stabilisation of the service levels in that way should be agreed by the customer.

Problems can - and should be raised were no incidents exist if the PM thinks there is a reasonable risk that unaddressed the problem is likely to result in service degradation (the proactive side of PM).

However it opens up a whole can of worms to not record reported incident and go straight to PM. And the big no no is that it undermines reporting on Service Levels which should be based on data that is complete as possible. Remember that IM is intended to support more than PM - it also provides critical information to Service Level, Availability, and Capacity Management. (Even if these aren't implemented take care in short cutting practices that may be required at a higher level of maturity.)

And after all filling in an incident record is not such a big deal. If it is a low impact / urgency incident, (and the customer agrees) you can then leave Incident resolution to one side and go straight to RCA - the main thing is that this is under standard process control, documented and an explicit decision (not just a quick arbitrary choice made by techies.)
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger

Joined: Mar 21, 2006
Posts: 18

PostPosted: Wed Mar 22, 2006 10:57 am    Post subject: incident vs problem vs change Reply with quote

Ok, I've done the foundation cert, worked primarily in the incident management area, dabbled with Problem man, and currently filling a maternity leave role as change manager....hopefully my experience (although limited) will help:
here's the senario - what I mention is not currently entirely practised, but probably should be - Quarter of the company's fleet of PCs due for Refresh. So a Change is raised due to the number of machines being replaced (approx 800) and change management ensure that risk and impact assessment has been appropriately applied, the timing of the rollout won't conflict with, say, the network transformation project currently taking place, etc. Release management ensure that the model of machine selected is suitable for business apps, current BOE and SOE, performance etc, who will support, job instructions and all the rest. This is all done, and machines are rolled out.

User of new machine calls service desk to log an issue - cd writer/DVD player won't read any discs. Logged as an incident as is only the one user, a one off occurance, Incident management. resolved with replacement of faulty DVD player.
2nd user of new machine logs the same issue with service desk. Still dealt with by Incident Management as still deemed to be a one off. Same resolution.

After a while, analysis is performed, and it was determined that there were multiple users affected with the same issue of the same model of machine. This is where Problem Management enter the picture - being REACTIVE in determining what the root cause is of this issue. The root cause is found, becoming a Known Error, and a change request is raised to correct the issue across the fleet.

Problem Management can also be PROACTIVE - ie, we anticipate there will be an issue with file server XXX due to it running out of space. What is the reason/root cause of this occurance, particularly if not evident on other file servers?

So incident management's number one priority is getting the user operational as quickly as possible with little thought given to how the issue occured in the first place. One group of people going through a high number of tickets per day
Problem management is looking at the bigger picture - if this is happening to multiple people, why is it so, can we do something to stop it occuring all together/lessen the impact/reduce the frequency, etc. different group of people who concentrate their efforts on deep investigation and permanent solutions.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion 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.