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 ?

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),

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.

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.

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

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

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