Understanding the Incident Priority Matrix
Source: https://blog.topdesk.com/en/incident-priority-matrix
The tickets keep rolling in and they are all over the place. Of course, the blocked printer on floor 7 takes a back seat if all of the company’s internet is under attack by outage monsters. However, situations are rarely that clear-cut. How do you prioritise incidents on a detailed level?
What is Incident Management?
When it comes to Incident Management, you may already know that a task's priority can be determined with the equation 'Impact x Urgency'. But how do we decide in the real world what counts towards these factors? Essentially, there are four things to consider, which will help us map out a priority matrix:
- How is productivity affected?
- How many users (and what type of user – perhaps VIP users, or part-time staff) are affected?
- How many systems or services are affected?
- How critical are these systems/services to the organisation?
To use ourselves as an example (because we know our own organisation best): at TOPdesk we work with 5 ‘Impact’ levels: organisation, location, department, team and person. "Is this something that risks sinking the entire organisation, or something that makes John in Accounting mildly inconvenienced?"
As for ‘Urgency’, we have found that 3 levels are ideal for most organisations: critical, normal, and low. This is the priority matrix we work with (and that is also used in our tool):
By mapping Impact and Urgency on one axis each, it is quite easy to set up a priority matrix that will help the team successfully deal with Incidents in their proper order. As you can understand, it is sometimes called the Impact and Urgency Matrix.
It gives a great overview and means major tasks are dealt with quickly, while more minor tasks are still handled within an acceptable timeframe. As a bonus, it also teaches the team the right kind of thinking, so that they can start prioritising tasks correctly quicker.
Understanding different priority levels
From the formula given above, we can assign any number of priorities. We use up to P7, but this number can differ with the amount of urgency and impact levels you use. Let’s give some real-world examples of what these levels of urgency might correlate to:
Critical priority tasks
A task classed as ‘critical’ (P2 and up) would usually include the following:
- A very important system has gone down;
- There is little to no functionality and there are no workarounds;
- Data has been corrupted;
- The majority of or all users are affected;
- There are potential legal or regulatory ramifications.
Examples of these sorts of failures would be network outages, virus infections, order system failure, or email outages. Of course, there are many more other guises these critical issues could take, but they should usually include most of the above factors.
In context, examples of these kinds of issues would be if a workgroup server crashed, or if a classroom’s technology stops working. Of course, there is a plethora of issues that these factors could encompass, and they are often unique from organisation to organisation.
Normal priority tasks
‘Normal’ priority tasks usually have priority P3-P5 assigned to them and:
- Basic functionality is available, but with some restrictions;
- Workarounds are available, to some extent;
- Usually more than one user is affected.
These are often standard IT issues, such as non-functioning printers, or when certain vital applications won’t launch individual machines. Clearly, these issues are still important in allowing your colleagues in other departments to do their day-to-day tasks. However, they are also clearly not as urgent to fix as some of the other examples we have mentioned.
Low importance tasks
Finally, ‘low’ priority tasks (< P6) consist of minor issues where no functionality is affected and it’s really mostly a cosmetic issue or minor annoyance.
These sorts of issues are most likely to be things like spelling errors or typos on one of the organisation’s web pages. It does need to be fixed, but should not be prioritised above higher impact tasks.
How to act
At this stage, we use SLAs that apply to these priorities. These will vary from organisation to organisation. But as an example, say we can expect a response to a P1 issue within 15 minutes, and if unresolved, an escalation by the 30-minute mark.
For a P2 issue, we could commit to up to 4 hours as a reasonable fix time, with an escalation in the 5th hour if a solution cannot be found. A P3 task would receive a fix time of 8 hours, with an escalation if unresolved, and P4 would have a full 24 hours, et cetera. But again, these times vary from organisation to organisation.
__________________________________________________________________________________________________________________________________________
To discuss more about service desk priority management, why not register for Digital Transformation EXPO Europe, Register free now! __________________________________________________________________________________________________________________________________________