Free Downloads

MindMaps:
ISO 20000: 2011
and
ITIL 2011 MMap
 

Templates:
Request for Change (RFC) Template

Major Incident Report Template

Posters:
ISO 20000/ITIL Timeline poster

    

Sponsored Links

 

Google

Jun 1, 2007

Incident Priority - What Everyone Should Know

As ITIL defines it, Incident priority is primarily formed out of it's Impact and Urgency. There are also additional elements, like size, scope, complexity and resources required for resolution.

So, most consultants recommend the simple matrix which will automatically calculate incident priority out of the simple value of Impact x Urgency.

Recommended granulation of Priority is 4 to 5 different values.
Usually the lower the value - the higher the Priority, thus Priority=1 is the highest one, and Priority=5 the lowest.
There are also some sophisticated methods for defining Priority, but eventually it all boils down to something like:


Picture: Standard Priority Matrix

Impact of the incident is the measure of how business critical it is. Since this is difficult to determine in shoes of overworked and underpaid 1st level operator, some simplifications are necessary here. So impact is usually directly proportional to a number of users influenced by the incident. If an up-to date CMDB is available, then it's easy to determine affected users from the Business Service which suffers from specific Configuration Item malfunction.

Urgency is a necessary speed of resolving an incident. Some incident management tools perform automatic calculations for Urgency based on Impact, SLA and OLA involved etc. Nice feature if you have it. If not, a simple workaround would be to educate Service Desk operators on a regular basis and to inform them on parameters of signed contracts. Incident Urgency for certain Services may vary in time (example: HR application during payroll calculation) and this additional complexity is easier to resolve by raising staff awareness level then to implement it in software tools.

Major Incident is an incident with extreme impact to business, or an excessive disruption of service. It will have Priority=1, and additionally, depending on your SLA and support process definition, it usually has additional attribute (checkbox is fine) that says this is a Major or Hot incident. All key Support Staff members attend to resolution of major incidents, and the project is strongly supported by Problem Management.

Also, should be said here that Incidents do not age gracefully. Data on that reside in the escalation schemes, based on Service Level Agreement (SLA) targets. If an incident owner can't deal with that, his manager has to be notified in time.



Update: Incident Escalation

Just a few words on Incident escalations. Escalations are mechanisms that help us to resolve incidents on time. There are two major types:

Functional Escalation - reassigning incidents to a higher tier support group due to lack of expertise. Also, this can happen after a predefined time interval passes, in accordance with SLA.

ITIL Incident Functional Escalation
Picture: Functional Escalation


Hierarchical Escalation - when a support employee can't deal with an incident, either due to lack of knowledge or insufficient time, his manager has to be informed in order to preserve SLA targets and customer satisfaction. In practice, this escalation type usually boils down to a simple notification to the manager.

Picture: Hierarchical Escalation
Picture: Hierarchical Escalation

7 comments:

mark said...

Aren't the priorities backwards? The articles indicates 5 is the lowest priority yet the graphic shows High Impact, High Urgency equals a Priority 5. Shouldn't it be a Priority 1?

doctor said...

Thanx Mark,

This post has been here for ages and you're the first to coment on this graphics.

I've straightened it up now, thanks again.

Anonymous said...

Good primer on IM. I've lived in that world at a large global financial company for a few years now. We actually have a multi-tiered set of priorities. P1-P4 which closely aligns to your chart. But, then we break out the P1s into 3 Severities - P1S1, P1S2, P1S3. All P1s cause a specific process to automatically be initiated and a P1S1 also engages a dedicated "P1 team" that manages the overal incident. This process work great as long as all groups are sufficiently on board. The key however is being able to properly identify the priority of an incident as early as possible. While not necessarily difficult from a technical perspective it can be very difficult when you have impacts to multiple orgs/groups who have differing operating models.

doctor said...

Aha, so the P1S1 is a Major Ticket. Works by ITIL, and you probably have your history/tool/organization reasons for this particular prioritization system.

Identifying incident prioritiy and classification is main responsibility of Service Desk, glad you brought it up.

Keeping a tidy Service Portfolio or at least a sensible Service Catalog helps a lot in impact assesment.

Thanx for dropping by!

alimck said...

"Reassigning incidents to a higher tier support group"

Service desk should still own all incidents until they can be closed.

Perhaps some clarification on 'assign' and 'own' is needed.

doctor said...

Alimck,

SD owns all incidents. I thought it was obvious from the graph where 3rd level resolves tickets, and then SD closes them.

Please have a look at Service Desk Article.

Have a nice day!

Edward Hammond said...

Establishing IT Security Incident Priority is not a service desk function: highest priority is the most serious threat against the most critical asset usually, so it’s 2-dimensional. Then, if you want to bring situational awareness into the picture this multiplier adds a third dimension, e.g. multiple incidents with a common factor might well have a higher priority than just threat potential and asset criticality ratings alone.

If they don’t come from the service desk, where do they come from? Asset criticality is a lookup in CMDB, and threat potential of an event type is a separate look-up table. Only the multiplier for situational awareness is manually assigned.

A bid dogmatic, sorry. Hope it makes sense.