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.
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
Jun 1, 2007
Incident Priority - What Everyone Should Know
Subscribe to:
Post Comments (Atom)
13 comments:
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?
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.
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.
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!
"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.
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!
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.
Hi doctor - thank you for this article. Here it is 2017 and I've just found it. It appears to hold up to my understanding of IM in ITIL (certified in Foundations in 2013).
I'd like to copy your work here--graphics and text--into an internal document for use in my employer as a reference to how priorities are determined. Do you allow this?
Hi doctor - thank you for this article. Here it is 2017 and I've just found it. It appears to hold up to my understanding of IM in ITIL (certified in Foundations in 2013).
I'd like to copy your work here--graphics and text--into an internal document for use in my employer as a reference to how priorities are determined. Do you allow this?
Of course, Apjohn2, glad if it helps.
Hi doctor,
Is it correct according to ITIL best practices, that when a prio 1 Incident is being registered, to lower the priority once the situation gets better and the impact and/or urgency are not that high in the meantime, but still the incident is open and a fix is under implementation?
This is often the practice in large service organizations, I have seen a lot of it. In the end it messes up your statistics and you end up short in management reporting.
I am strictly against these practice. If you resolved - put the ticket into status "resolved" and open a problem ticket to tidy up and do RCA.
In this particular example you mentioned I would probably resolve a ticket and create another one of lower priority. But this is a rare case. Usually incidents are binary phenomenons - either there is impact or there is none. If you kept only one ticket, which was Pri1, and resolved it when it came to Pri4, then your Service Desk tool has to be able to remember your previous priorities and impacts in order to have good SLA reports and statistics.
Otherwise when you ask for a report of all Pri1 tickets last month, this one won't come up.
Is it an ITIL practice to lower fown the priority of a case if the impact and urgency has been reduced?
Post a Comment