Joined: Mar 16, 2006 Posts: 12 Location: Rennes, Brittany, Fr
Posted: Thu Feb 22, 2007 7:35 pm Post subject: Definition of a Problem impact
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 ?
Joined: Sep 16, 2006 Posts: 3347 Location: London, UK
Posted: Fri Feb 23, 2007 7:02 am Post subject:
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
Posted: Thu Mar 01, 2007 5:24 am Post subject: Impact of Problem
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.
Joined: Apr 17, 2007 Posts: 36 Location: Cape Town
Posted: Thu May 03, 2007 6:49 pm Post subject:
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.
Posted: Thu May 03, 2007 9:40 pm Post subject: defining problem priorities
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...
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