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.
Joined: May 30, 2006 Posts: 2 Location: Bangkok, Thailand
Posted: Wed May 31, 2006 1:58 pm Post subject: Incident Priority
Hi all,
We are implementing the Incident management process and have got some problems on defining the Priority matrix and Impact and Urgency criteria. Could anyone provide any suggestion on..
- Aside from the number of sites/users, what other criteria should be used to measure the impact ?
- What criteria should be used to measure the urgency ?
- Aside from H/M/L impact, has anyone also defined the 'No Impact' impact ?
Joined: Mar 12, 2005 Posts: 255 Location: Melbourne, Australia
Posted: Wed May 31, 2006 2:25 pm Post subject:
I've designed priority schedules with impact values decided as a weighted function of scope (no of users etc) and scale of impact, where this is usually something simple like (in order of seriousness),
* user affected - (end user is disrupted but can continue working)
* user halted - (end user cannot work)
* business affectes - (A whole business function or process is impaired)
* business halted - (a business process or function cannot operate)
Personally I think urgency cannot be arithmetically derived from any parameters. It's a function of how long a resolution can wait and available resources. For example, an end user rings with an incident that has halted their ability to work, but they are going on leave for five weeks and it does not need to be done before then. That would be a low urgency.
Also final calculation may include an overrides from SLA or client profile information. Eg., where VIPs get a point bump, etc.
It can be as fine as you want to make it, but I would place two caveats:
Try not to get more than 8 discrete priority values - less if feasable.
What ever you calculations try and ensure you get an even spread that does not bunch up all your incidents in a narrow range.
Remember priorities set the order in which things are done - no more really - deadlines are usually set by SLAs.
Finally, calculated priorities are a guide, key staff should be able to override these manually - but should also be required to include an auditable explanation of why.
Joined: May 30, 2006 Posts: 2 Location: Bangkok, Thailand
Posted: Wed May 31, 2006 4:56 pm Post subject:
Thanks for your suggestion. I like your idea. Actually, we also think about the criteria you mentioned, but consider some of them as the impact or urgency criteria in different way as you.
Joined: Oct 26, 2007 Posts: 295 Location: Calgary, Canada
Posted: Tue Dec 08, 2009 3:30 am Post subject:
Priority basically determines the course of actions you will be taking... Personally, I hate seeing/working with more than 3 levels of priority. P1 for your emergencies, P2 for regular incidents, P3 for nice to have/can wait/best effort kind of stuff. Priorities need to be meaningful and associate with business need and specific actions.
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Mon Dec 14, 2009 5:56 am Post subject:
rjp wrote:
* user affected - (end user is disrupted but can continue working)
* user halted - (end user cannot work)
* business affectes - (A whole business function or process is impaired)
* business halted - (a business process or function cannot operate)
These are rather IT oriented criteria. I have also seen one/several/many users disrupted as a criterion for priority.
But it is the importance of the function to the business at that point in time that should determine the priority. The more severe the threat or cost to the business, the higher the priority. That is why impact and urgency determine priority. There is no simple way to label or characterize priority except "do this first", do this next".
Take the "user affected" which you may be proposing to be lower priority than the others: if that user is putting together a major contract bid document that has a tight deadline, then even slowing down their work may put you at risk of serious losses, not to mention writing off months of effort already gone into the bid.
If you want to characterise events as shorthand for determining priority it is better to do it at the impact stage. You still need the capability of recognizing exceptions there, but at least you will have recognized that urgency varies in a different way. _________________ "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
I have some question about Incident Prioritization topic and I want to have your' suggestion on my question. The questions are the following:
- What is the benefits of Target Resolution Time on Incident Prioritization?
- What is the bad thing if my company not have a Target Resolution Time on each priority?
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Tue Dec 15, 2009 8:15 pm Post subject:
Peter_hades,
there is a widespread misconception that the priority assigned to resolving a particular incident will, in some (magical) way, determine how much work will be required to achieve that.
The truth is that the time required to resolve an incident is governed by the skill, diligence and quantity of human resource applied to it, tempered by the time taken by machines to process instructions and the time taken by external agencies to deliver necessary components and services.
Target resolution times can only be meaningful for defined issues and so you must define the nature of incidents that have target resolution times. you can do this at many levels, but priority is not one of them.
However this has not stopped thousands of organizations going ahead with priority based targets and very few of them have analysed what they may be committing themselves to. If you stick to averages, say over a rolling month, you can get away with it most of the time, especially if you have swathes of "press of a button" resolutions every day.
In practice, whenever they severely fail in this target they wriggle with a special case plea because the type of problem was outside their usual experience. Smart sites biuld this caveat into their SLA. _________________ "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
Last edited by Diarmid on Tue Dec 15, 2009 8:36 pm; edited 1 time in total
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Tue Dec 15, 2009 8:23 pm Post subject:
Sorry to double post, but I forgot to mention that priority is about determining how resources are allocated to tasks. This has an impact on how soon they are completed, but that is as far as it goes. _________________ "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
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
