Incident Priority

[Penny]

[rjp]

[Penny]

[Timo]

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.

[Diarmid]

* 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.

[Peter_hades]

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.

[Diarmid]

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.

[Diarmid]

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.

[Peter_hades]

Diarmid,

Thank you for your suggestion