Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: DSchaefer
New Today: 41
New Yesterday: 71
Overall: 146141

People Online:
Visitors: 63
Members: 3
Total: 66 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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.


The Itil Community Forum: Forums

ITIL :: View topic - Incident Priority
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Incident Priority

 
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk
View previous topic :: View next topic  
Author Message
Penny
Newbie
Newbie


Joined: May 30, 2006
Posts: 2
Location: Bangkok, Thailand

PostPosted: Wed May 31, 2006 1:58 pm    Post subject: Incident Priority Reply with quote

Very Happy
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 ?

Many thanks !!
Back to top
View user's profile
rjp
Senior Itiler


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

PostPosted: Wed May 31, 2006 2:25 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Penny
Newbie
Newbie


Joined: May 30, 2006
Posts: 2
Location: Bangkok, Thailand

PostPosted: Wed May 31, 2006 4:56 pm    Post subject: Reply with quote

Mr. Green
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.
Back to top
View user's profile
Timo
Senior Itiler


Joined: Oct 26, 2007
Posts: 295
Location: Calgary, Canada

PostPosted: Tue Dec 08, 2009 3:30 am    Post subject: Reply with quote

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.
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Mon Dec 14, 2009 5:56 am    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail
Peter_hades
Newbie
Newbie


Joined: Dec 15, 2009
Posts: 2

PostPosted: Tue Dec 15, 2009 7:52 pm    Post subject: Reply with quote

Hi guys,

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?

Thank for your kindness.
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Tue Dec 15, 2009 8:15 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Tue Dec 15, 2009 8:23 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail
Peter_hades
Newbie
Newbie


Joined: Dec 15, 2009
Posts: 2

PostPosted: Tue Dec 15, 2009 8:31 pm    Post subject: Reply with quote

Diarmid,

Thank you for your suggestion
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk 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 http://www.nukecops.com

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.