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.
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.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
Posted: Fri Jun 09, 2006 11:54 pm Post subject: Incident Priority Definitions
Hi there, I've just joined this community, and it looks like a great place to exchange knowledge and information!
I would like some input on priority definitions. I have taken the 1-5 priorities and listed them as major, high, medium, low and planned. I'm now giving each of the priorities a definition, ie the definition of a major incident is "business stopped". I'm struggling to come up with a suitable definition for a medium priority incident, somewhere between "business interrupted" for high priority, and "impact issue" for low priority.
Can anyone offer me some inspiration for a medium priority please?!
Posted: Tue Jun 20, 2006 4:46 am Post subject: Re: Incident Priority Definitions
KiwiChick wrote:
I would like some input on priority definitions. I have taken the 1-5 priorities and listed them as major, high, medium, low and planned. I'm now giving each of the priorities a definition, ie the definition of a major incident is "business stopped". I'm struggling to come up with a suitable definition for a medium priority incident, somewhere between "business interrupted" for high priority, and "impact issue" for low priority.
Can anyone offer me some inspiration for a medium priority please?!
Cheers!
Kiwi Chick
The first advice I always give is minimize the number of impact/severity codes. You are calling yours "Priority" but priority is normally expressed as High-Med-Low and is different from impact/severity although the two should generate a parallel response, i.e. High impact=high priority.
I like the categories in Change Management applied to most all process areas (Incident, Problem, etc.) Major-Significant-Minor-Standard, where in the case of Incident, Standard is a non-service impacting request. So other than Service Requests, you really have just three.
I like your "Business stopped" for Major. I really don't see how that is much different from "Business interrupted" though.
Major: Impacts multiple departments, IT Services or customers. Has major financial impact on the business. (Core router down, transaction server failed, etc.)
Significant: Impacts fewer customers, IT Service or business function with lesser financial impact. (Not something like above examples, but more impact than below... Email unavailable to 5 people)
Minor: Impact few customers, no financial impact, workaround usually available. (Printer down, can't get to xyz website)
Joined: Mar 12, 2005 Posts: 255 Location: Melbourne, Australia
Posted: Tue Jun 20, 2006 9:55 am Post subject:
KiwiChick...
I think the source of the difficulty may be a confusion between impact and priority.
Impact is an assessment criteria, priority is a setting based on assessment.
In ITIL impact is not the only assessment criteria, it also recommends using urgency.
A good example of the difference is: A user calls in and reports that their entire desktop system has crashed. And let's say this is a very important user who is key in the business. That would be a high level of impact. And normally you wouild assing a high priority.
But let's that when calling it in, that user also tells you they are off overseas for four weeks leave. Suddenly it's not urgent that you attend to the incident. So long as it's resolved by the time they return.
Priority is the setting that decides what gets attended to first. In the above case, there will be a number of open incidents, of lesser impact, that you may wish to do before the high-impact one, because it isn't urgent.
Finally, many sites have totally arbitrary factors affecting their priorities - these are called SLAs. So that while you may calculate impact based on things like number of users affected, there may be an SLA clause that overrides the priority and decrees that another incident affecting only one user (say the CEO) takes priority.
So, because priority is simply the setting (not measurement) that says which 'cab leaves the rank first', plain old numeric values are fine and 1 to 5 is a perfectly workable range.
Come to think of it, there is another solid reason for sticking with simple numeric values: Priorites change. You can move the value up or down. If you bind them to definitions that becomes, well odd to say the least.
Coda: Here in Oz it very common to use the term 'Severity Level n' instead of 'priority'. In typical Australian fashion this gets shortened to 'Sev Lev n'. But it works just fine. When someone says we have a 'sev lev 1' you know to pay attention. (Actually I think it would be cute to use 'DefCon' )
*chuckles* Ooh... and announce it over the company tannoy *puts on nasal voice: "We are at Def Con 1, I repeat, Def Con 1. All hands on deck!".
Seriously though, I'm not going to chime in with anything hugely useful on this topic as we desperately need to rejig our priortisation schema. It just seems to confuse/annoy the technical staff although the users seem okay with it. Part of the issue is we don't yet have a defined change management process so our priorities are kind of all thrown in together *shakes head*.
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