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: olaqefap
New Today: 7
New Yesterday: 33
Overall: 231655

People Online:
Visitors: 117
Members: 0
Total: 117



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

Definition of a Problem impact

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

Joined: Mar 16, 2006
Posts: 12
Location: Rennes, Brittany, Fr

PostPosted: Thu Feb 22, 2007 7:35 pm    Post subject: Definition of a Problem impact Reply with quote


In problem Qualification, the Priority is the result of Impact x Urgency (in a matrix). I made the assumption that this is the same definition as for Incident management. So, the impact of a problem is the impact of the underlying incidents. But I still do not know how to define the impact !
Have you got keys for that ?

Back to top
View user's profile
Senior Itiler

Joined: Aug 11, 2006
Posts: 262
Location: Netherlands

PostPosted: Thu Feb 22, 2007 8:03 pm    Post subject: Reply with quote

For instance:
* Number of users

1. Individual user
2. Department
3. Unit (as in: set of depts)
4. organisation
Back to top
View user's profile Visit poster's website

Joined: Mar 16, 2006
Posts: 12
Location: Rennes, Brittany, Fr

PostPosted: Thu Feb 22, 2007 9:00 pm    Post subject: Reply with quote

Just after talking with some colleagues : usually a work-around was found so the impact could also be defined in terms of :
- risk of failure of the work-around
- loss of performance
Back to top
View user's profile
Senior Itiler

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

PostPosted: Fri Feb 23, 2007 7:02 am    Post subject: Reply with quote

The priority of a problem should be different to a priority to an incident

mainly because the focus in each area is different

The incident focus is on restoring service
The problem focus is finding out why the incident happens

For example, the problem is find out why the 4 web servers keep BSD every 10-20 days.

The work around is of course reboot the servers in question to restart the process

If the 4 web servers are not all crashing at the same time so that the web service is stilling (but with 2-3 out of the 4) then the priority may not be the highest

If the service is out while using the workaround, then the priority may be higher - depending on who is using the service and what the service is for

For example: a network printer server which prints on 11x17 color has crashed. The printer service is used 1 a quarter to make books or magazine. And the service is due to be used this week. If there is no alternative to printing the magazines, then yes the priority would be higher, but if there is an alternate service which will do this then the priority may be lower
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile

Joined: Feb 28, 2007
Posts: 4

PostPosted: Thu Mar 01, 2007 5:24 am    Post subject: Impact of Problem Reply with quote

I agree with measuring the comment of impact by number of people or size/impact of the issue to the overall corporate environment. I also agree with the comment of Problem priority is different from Incident. Problems severity/urgency/priority is a different set of criteria from Incident in my mind. I would look at impact, urgency of the incident response AND frequency of the incidents. If it only happens every 30 days, but you have an issue that happens daily, then the problem for the daily repeat incident should be higher. Another maybe to take the Severity + Urgency = Priority, prority number from Incident and add it to a frequency measure to find the priority for Problem.

Back to top
View user's profile

Joined: Apr 17, 2007
Posts: 36
Location: Cape Town

PostPosted: Thu May 03, 2007 6:49 pm    Post subject: Reply with quote

I would look at impact, urgency of the incident response AND frequency of the incidents. If it only happens every 30 days, but you have an issue that happens daily, then the problem for the daily repeat incident should be higher.

A reasonable assumption, but not always true. Just because you have an incident that happens daily it does not mean it has any significant impact on the business or users. For example, you have a network link that goes down every morning at 04:23. The NMS system generates an incident automatically, and eventually it is logged as a problem. However, your organisation is 9-5pm and no-one is actually affected by the incident. So whilst you'd want it solved, you are probably going to be much more interested in solving the monthly crash of the finance system during the end of month financial accounting.

So IMO the urgency, priority, severity (call it what you will) of a problem is inherently linked to the impact on the business, and should be classified as such, i.e. in exactly the same way as an incident should be classified. If you agree with that logic, then the problem will initially have exactly the same priority as the underlying incidents.

After some investigation that priority might change which is perfectly reasonable because as John pointed out, problem management has a different focus to incident management. Although ultimately they have the same goal: to ensure that a service meets its SLA.

Priority changes may come about for different reasons. A single PC regularly crashes during presentations. Generally within a 200,000 strong organisation this problem would have a relatively low priority - unless it is Bill's PC and he's fed up with BSD's during big PR events;-)

So equally you could calculate priority as:

    number of people screaming at you to fix it * Seniority of screamers

As with everything in the real world, whilst you can use analytical methods to calculate priorities, the real priority will be defined for you based on how important management perceive the problem to be. Moreover you will soon know from experience what is serious and what is urgent.

Back to top
View user's profile
Senior Itiler

Joined: Mar 29, 2007
Posts: 123
Location: FRance

PostPosted: Thu May 03, 2007 9:40 pm    Post subject: defining problem priorities Reply with quote

Hummm, let me put here something that might look a little simple , but sounds very logical in the ITIL "Philosophy".

Based on your Service Catalog and SLAs, you should be able to determine which services are most critical to your business.
I would rather use the level of criticity to assess the impact level, in conjunction with risk factor (that you can call urgency).

Whether there is an alternate solution for providing the service does not always count that much. Let me take an example on this: in order to answer HIGH AVAILABILITY requirements/commitment in the SLA for a business critical service, we have a redundant piece of architecture in place; there is a problem identified on one of the 2 components; as long as it is not fixed any availability incident on the other component will shutdown the supported services and be harmful for the business.

As for the number and business level of users impacted, I'd like to tell a story as I do most of the time when running an ITIL training (that will also illustrate that experience is also - mainly?- made of mistakes).

More than 10 years I was heading the Infrastructure Dpt for a chemical company. One day, we had to face 2 different problems at the same time, that were requiring the same support people:
* Problem 1: the Messaging System was down . Location: Europe-MEAF HQ - population impacted: 150 users, including the European VP, and 80% of his staff (Directors at European Level) - More than 100 tickets opened.
* Problem 2: a single printer in a plant was not working, its backup either. Location: a rather small plant - population impacted: supposedly 2 users - only one ticket opened.

Guess what? We did focus on the messaging problem , leaving the printer one for later on. Frankly speaking, who there would have made a different choice???

The printer just happened to be used to print some Safety Data Sheets that were legally required for transportation of our products. Because these papers could not be printed, no truck couls leave the plant with the products (chemicals) and after a few hours , the queue of trucks waiting to enter the plant was about 2 miles long, police had had to put measures in place to reroute the traffic on different roads, the Head of "State" had called the Regional Manager....
Even worse: the business SLA called for customers having ordered before Noon to be delivered before noon the next day, otherwise there were entitled for financial compensation... I do not remember how much, but can tell that we lost a significant amount of money on this...

Needless to say, we were not completely ITIL at that time (although pretty advanced in some areas), and were missing a few pieces but mainly the piece that was lacking most was business knowledge and understanding. That's a reason why I put so much emphasis today in the business process and IT services linkage to be captured and registred ... in the CMDB (service catalog and SLA also) , so people dealing with incidents and problems can react to the best benefit of the business...

That's a rather long post, but I hope you like the story...

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