This may seem a little ITIL 101 for some of you, but I think there is value in covering some of ITIL’s basic concepts in detail. ITIL asserts that you Prioritize issues (Incidents, Problems, Changes, etc.), and work on the highest Priority issues first. You then work your way down the list of issues until you get to the lowest Priority, but Priority is not derived from a single source. Priority is determined by the intersection of two other values: Impact and Urgency.
The concept of Priority being calculated by setting a ticket’s Impact and Urgency fields is so well adopted that I would argue most ticketing systems follow this convention. How Impact and Urgency determine Priority is quite often configurable in the ticketing system’s administration panels and most often follows this schema:
In the example above, Priority 1 issues can only be generated if both the Impact and Urgency are set to level 1. Priority 5 issues can only be generated by Impact 3 and Urgency 3 issues.
The problem with this schema is that it results in 5 levels of Priority. If you do as ITIL recommends and work on Priority 1 issues first, and then Priority 2, and then Priority 3, etc. then there is a very good chance you will never get to Priority 5 issues.
A more balanced table might be:
This example only results in 3 Priority levels and might be easier to adopt by the organization.
Regardless of how you calculate Priority based on Impact and Urgency, everyone must agree on the definition of Impact and Urgency. Surprisingly, there can be quite a bit of disagreement on the definition of these terms.
The degree to which the business is affected by the issue. For Incidents, it can often be measured in terms of the importance of the service and the degree to which the business is affected. A good example would be email being completely down. I think everyone can agree email is a top tier application for most organizations, and it being down is pretty impactful. I would consider email down an Impact 1 type event.
The speed in which the issue needs to be addressed. If email goes down on Saturday morning for a company that does zero work over the weekend, maybe the Urgency isn’t as high as if email goes down on Monday morning at 10:00am.
Let’s look at two scenarios to dig further into Impact and Urgency.
Let’s say that the company’s payday is every Saturday with the payroll batch job running Friday night. On Friday morning the Payroll group discovers that the application that runs the batch job won’t launch.
What is the Impact? I’m going to be pretty pissed off when my bank account shows me I that have no money when I want to go out partying Saturday night. And this affects every employee of the company. Definitely high Impact.
What is the Urgency? The clock is ticking on this one folks. You might have 10 hours to get whatever is wrong fixed. I would call this high Urgency too.
Again, payday is every Saturday with the payroll batch job running Friday night. Sunday morning the Payroll group discovers that the application that runs the batch job won’t launch.
What is the Impact? It is the same as in scenario 1. This is a tier 1 application that affects everyone in the company.
What is the Urgency? Maybe not so high. You have at least 5 days to get it working. I think we can let this slide a bit and not have an “all hands on deck” situation.
But what happens if it still won’t launch on Wednesday? Or if it still broken on Thursday? The point I’m trying to make is that Impact and Urgency need to be constantly reevaluated for accuracy. As deadlines approach, the Priority should be adjusted accordingly.
Sometimes when we get the initial call about an Incident, we open a low Impact, low Urgency ticket, but as more information becomes available we find out that the Impact and Urgency need to be adjusted. This is the natural way of discovering high Priority Incidents. The first reports can just be the tip of the iceberg for a massive issue.
One last thing. ITIL says that you should take all your tickets and work on the issues in order from highest Priority to lowest Priority, but don’t be a slave to your Priority. If you are working on a massive Priority 1 ticket that will take 5 hours to fix and someone comes to you with a Priority 3 ticket that only you can address and will only take 2 minutes, take a break from the Priority 1 Incident and do it. Two minutes tacked on to a 5 hour project is miniscule and the 2 minutes you spend could make someone else’s life a lot easier.