What is a priority matrix?

A priority matrix is a technique in IT service management (ITSM) that can be used to determine the priority of one task over others. As the title suggests, it uses a matrix to determine the priority that contains pre-defined values for two different characteristics, with one on each axis of the matrix. The priority is determined by mapping the situation being faced to these values in the matrix. The outcome of using a priority matrix in this way is that teams can consistently define the order that they should deal with tasks and actions.

A priority matrix provides an easily communicated overview of how the organization has defined what its priorities are in day to day management of issues and challenges. Using a priority matrix means that high priority tasks can be easily identified and promptly actioned, whilst allowing tasks with a lower priority to be dealt with at a slower pace but still within an acceptable timeframe. A priority matrix can also help to change the attitude and behaviors of support teams, and help them to learn how to correctly prioritize tasks and actions.

A priority matrix typically uses the characteristics of ‘Impact’ and ‘Urgency’. These simple terms can be challenging to apply in real-life situations, so a good practice is to supplement a priority matrix with guidelines and examples. Some organizations refer to a priority matrix as an ‘Impact and Urgency matrix’.

What are the benefits of using a priority matrix?

Using a priority matrix will help you to deal with tasks in the best overall order for the business. This includes managing incidents, problems, changes, and projects. Determining the most appropriate priority using the matrix will allow your staff to be consistent in how they decide what task to address in which sequence. This will provide them with the confidence to do what they think is right, as the priority matrix will be used in the same way by all staff. In turn, this will improve the satisfaction of the customers for your services. If you share the priority matrix with your customers, then they will be able to understand why particular incidents are dealt with before others. A priority matrix can improve relationships between IT, ITSM, and the business. If you develop the priority matrix as a joint effort involving all of these parties, then each will be able to better understand each other’s perspectives for prioritizing work.

Articulating and documenting how Impact and Urgency are used to determine priorities using the matrix will help to remove any uncertainty about how IT decide which sequence to work on tasks. Using a priority matrix can also help to avoid IT favoring one part of the business or one individual over another when determining task priorities.

A priority matrix is particularly of benefit when support teams become overloaded, with more tasks that they can deal with at the same time. Unless an agreed matrix is used to determine priorities, there is a risk that staff can ‘cherry pick’ what they want to work on, which can result in delays to resolving urgent and high Impact tasks such as incidents. Using a priority matrix to determine when an incident is a major incident will avoid the situation where high levels of resources are assigned to an incident which has been prioritized by pressure from the business but in reality, does not have a high Impact. The knock-on effect of relying on user pressure instead of a priority matrix is that other incidents that should be a priority are pushed down the queue.

When should you use a priority matrix?

All organizations should use a priority matrix in every ITSM process that is task oriented, where decisions have to be made about which task to work on next. This includes the following processes:

Using a priority matrix for all these processes to determine what to work on next will avoid the situation where high levels of resources are assigned to a task which has been prioritized by pressure, or by lack of information.

A priority matrix should be included in the definition of every process step where a decision has to be made about which task to work on next. The priority matrix will assist that decision in a consistent and transparent way. Every ITSM process should be examined to locate these decision points, and an appropriate priority matrix designed and implemented. The design should include all involved and affected parties, this is likely to be IT, ITSM, and the business. The Impact to the organizations day to day business should be the driver for determining the highest priority tasks from the matrix.

The most common process where organizations use a priority matrix is the incident management process, where it is used to determine the priority of incidents. This is an ideal process to learn about how to define and use a priority matrix, as for most organizations the incident management process handles the highest volume of tasks, and the workload usually exceeds the capacity available. However, benefits can be made by including the use of a priority matrix in the other processes listed above. Ideally, the priority matrix should be included in the initial design of these other processes, to avoid subsequent re-work and changes to toolsets.

Impact versus Urgency in a priority matrix

Ideally, tasks should be prioritized using a combination of factors including Impact, Urgency, size, scope, complexity and resources required for resolution. However, including all of these factors can be complex to model and challenging to understand. Hence most examples of a priority matrix are s simplified version that only considers Impact and Urgency to determine priority.

The precise definitions of Impact and Urgency in a priority matrix will depend on the process where the matrix is used, the characteristics and requirements of the organization, the business processes that the process supports, and any contracted service levels that are expected to be achieved. To provide improved understanding, the following definitions are for using a priority matrix to determine the priority of an incident in an incident management process.

The Impact of the incident is the measure of the disruption to the day-to-day business of the organization. Note that this is the Impact to the business, not to an individual user, hence it reflects how critical the loss of service is to the business.  As this can be challenging for a service desk agent or a toolset to evaluate using the priority matrix, many organizations apply a simple metric to determine Impact based on the number of users affected by the incident. The Impact is directly proportional to a number of users influenced by the incident.  Hence the highest Impact incident in the priority matrix is one where all users are affected by the incident, and the lowest is where just a single user is affected. This can create issues for critical services with a low number of users, so a better approach for assessing Impact in a priority matrix is to use the percentage of users affected for the affected service or services. Hence the Impact is highest if 100% of users are affected, irrespective of the actual number of users. This better approach is particularly useful where critical services are affected at evenings and weekends where the number of users is much lower than during normal weekday working times.

Urgency is a necessary speed to resolve the incident. This is often associated with service level targets for the affected services, where Urgency in the priority matrix increases if the contracts include short incident resolution times. Urgency can also depend on the criticality of the service affected by the incident.  Where this approach is used the priority matrix should include the different service criticalities, and information on the criticality of each service must be available so that the correct assessment of Urgency can be made. Some toolsets can perform automatic calculations to determine the Urgency based on these factors. Urgency for certain services may vary over time, for example, payroll services at the end of the month, however, this can be challenging to include in a priority matrix unless automatic calculations are available.

 

Example priority matrix

The design of the priority matrix will vary by organization and by process. Here is an example of generic priority matrix for determining the priority based on Impact and Urgency:

In this simple priority matrix there are:

For example, consider an incident that is affecting all users of a service that has a low criticality, such as a service for reserving meeting rooms. The incident has a high Impact as it is affecting all users. The Urgency is low, as the service criticality is low. By using the priority matrix to look up these values, the priority of the incident will be set as 3 – this is the value where the High Impact column intercepts the Low Impact row. This priority as determined from the priority matrix would then be assigned to the incident record so that support staff can see what the priority is.  

Understanding priorities

When a priority matrix is used it is still important for all staff involved to understand what drives the priority. For example, in the incident management process the priority matrix often uses just Impact and Urgency to determine the incident priority. When designing the priority matrix most organizations have no difficulty in defining the different levels of Impact and how to assess them, but defining Urgency can be more challenging. You need to decide in the real world what counts towards these factors. Rather than just defining values for urgency, it is a better idea to stand back from the priority matrix itself and discuss for your organization what drives priorities. There are usually five different aspects that should be considered and understood when designing a priority matrix:

It is important to use these factors to model different scenarios using the priority matrix to validate that the matrix will give you an appropriate priority. If it doesn’t do this, then you need to review the values in your priority matrix as well as the values for the conditions that determine them. You may find that you need more than one matrix, for example, one priority matrix that is used at critical business periods, and another that is used the rest of the time.

To illustrate this, some organizations determine impact in the priority matrix based on what levels of the organization are affected. For example, considering the organization, a location, a department, a team and an individual.  This supports making an assessment using the priority matrix of scale of the risk if the task is not addressed.

How many priorities should you have?

A priority matrix can support any number of different priorities. However, the recommendation is to have no more than five priorities, and many organizations have just three. This is because, complexity and confusion increase as the number of priorities in the matrix increases. Most people readily accept the concept of a high priority, a low priority, and a medium priority, each with an associated numeric value. When your priority matrix includes more than three values then it can be difficult to associate appropriate words with each priority.

Usually, the value for a priority is higher when the priority is lower, and vice-versa. Hence in a priority matrix, a priority of 1 is the highest and should always be dealt with first.  This can be in conflict with other numbering systems such as security levels, where the highest number presents the highest priority and the highest risk to an organization. It is very important to understand what is meant by each numeric value in a priority matrix, as this avoids confusion.
 

Examples of different priorities in a priority matrix

In your own organization, it is a good idea to provide staff with examples of the different priorities that can be derived from a priority matrix. This will help with understanding and is more likely to result in staff using the priority matrix intelligently.

Taking the example priority matrix provided earlier, there are five possible priorities, with a Priority 1, abbreviate to P1, as the highest.

Critical priority tasks

A task defined in the example priority matrix as a P1 has a high Impact and high urgency. These tasks are usually critical to the ongoing operation of the organization, or present the highest risk to it. P1 tasks from the priority matrix could include the following:

Examples of failures that could result in an outcome of a P1 from the priority matrix are full network outages, widespread virus infections, denial of service attacks, email outages, and full application outages.

 

High priority tasks

A P2 task in the example priority matrix has mid Impact and high Urgency, or high Impact and mid Urgency. These are tasks where it is important to get a quick resolution, but the effect to the organization is not as great as a P1 task. P2 tasks from the priority matrix could include:

Examples of failures that could result in an outcome of a P” from the priority matrix are partial network outages, localized virus infections, loss of some email functionality, and outages for non-critical applications.

 
Normal priority tasks

‘Normal’ priority tasks usually have priority P3 or P4 assigned to them from the priority matrix. These are tasks where

These are often routine IT issues, including printer failures, or application issues that only affect a few users. These issues still need to be resolved, however they are not as urgent to fix as tasks that have been identified using the priority matrix as having a higher priority. So if there are outstanding tasks with a higher priority from the matrix they should be dealt with before these P3 and P4 tasks

 
Low importance tasks

Tasks identified as P5 from the priority matrix have low Impact and low Urgency. These tasks are the lowest priority. They are minor issues where the users are still able to carry out their business activities. P5 tasks tend to be cosmetic issues or minor annoyances. Examples of P5 tasks that can arise from using a priority matrix are spelling mistakes in reports, or poor layout of content on a web page. They should still be fixed, but should never be prioritized above tasks with a higher priority.

 

Guidance for using a priority matrix

It is a good idea for every organization to build guidance for using the priority matrix. This guidance should include meaningful examples for the particular organization for tasks of each different priority from the matrix. The guidance for using the priority matrix should be updated over time as new examples are found, and any issues with incorrect priorities are experienced.

The guidance should include specific ranges where numbers are involved. For example, ‘where several users are affected’ is open to interpretation. Precise numbers that are relevant to the organization in question should be used in the priority matrix guidance. For example, ‘where more than 10 but less than 100 users are affected’. The guidance for the priority matrix must also be unambiguous. What is obvious to the person creating the guidance may be less obvious to the people who use the priority matrix.

It is a good idea to test the guidance in a ‘conference room pilot’. This is where different scenarios are presented to the staff who will be using the priority matrix. The staff determines the priority of the task using the scenario, the guidance, and the priority matrix itself. The designer of the priority matrix and the staff then review the outcomes, verifying that an appropriate priority has been derived from the matrix. If there are any issues, the guidance and the priority matrix itself should be reviewed and if necessary updated. All of the scenarios should then be re-run, as a change to fix one issue could inadvertently cause new issues with scenarios that previously gave an appropriate priority from the priority matrix.

Priority matrix and service levels

Many organizations have service levels that specify the time allowed to resolve issues, requests, and incidents. Where service levels exist the design of the priority matrix must take this into account, particularly where the service level for resolution varies according to the priority. If service levels dependent on priorities have been defined in a contract, then the priority matrix must include precisely the same priorities, otherwise there will be confusion. For example, if a contract has service levels with different targets for priority 1, priority 2, and priority 3 tasks, then the priority matrix should only be able to give an outcome of P1, P2, or P3. The contract should define in words what these different priorities are and what should be used to derive them. Ideally this should be in a priority matrix, as part of the contract.

Times specified to resolve tasks depending on the priority from the priority matrix will vary from organization to organization, but here is an example:

These times will be defined in the documented service levels, and would not be included in the priority matrix. It is a good idea to provide a link to the priority matrix from the service levels. Copying the priority matrix into the documented service levels can cause issues with consistency if there are subsequent changes to the priority matrix.

Incident escalations and the priority matrix

Incident escalations are mechanisms that help to resolve incidents on time. Escalations use the priority of the incident that has been derived using the priority matrix. In ITSM there are two types of incident escalation:

Functional Escalation 

Functional escalation is where an incident is reassigned to another support group, because the current group working on the incident do not have the necessary skills required to resolve the incident. Some organizations choose to reassign incidents to a more experienced support group after a predefined time interval passes, in accordance with the service level. The time interval typically varies according to the incident priority from the priority matrix, the interval is shorter for incidents of a higher priority.

 

Hierarchical Escalation

Hierarchical escalation is when staff alert a higher level of authority about an incident, usually their manager and the service owner for the service affected by the incident. The trigger for when to use hierarchical escalation will depend on the priority from the priority matrix and the service level for the incident. If the service level is in danger of being breached, then the manager and service owner should be informed so that they can help to preserve achievement of the service level target for this priority of incident, and take pro-active steps to maintain customer satisfaction. Deriving the correct priority from the matrix is an important step, as this helps to avoid making unnecessary hierarchical escalations. This is particularly the case for high priority incidents, as many organizations want to alert management and service owners soon after they have been identified using the priority matrix.

For example, an organization might have a service level to respond to a P1 incident within 30 minutes, but if not resolved escalate to management at the 20 minute mark. This would ensure that management are aware of the priority 1 issue before the service level is breached.  In contrast, for a P2 incident with a 4 hour fix time the escalation might not occur until after 3 hours. A P3 incident with a 1 day fix time might not get escalated until the service level is breached, and a P4 and P5 may never have an escalation to management.

Where hierarchical escalations are in place, it is important to include testing the escalations as part of the scenario testing for the priority matrix. There should also be regular reviews of the escalations that have taken place, including support staff and management, to identify of there are any issues with the priority matrix or associated priority guidance that need to be addressed.

 

Using a priority matrix for incidents

Incident management is the most common process where a priority matrix is used. Just about every organization does incident management. Even organizations that don’t have a service desk still have to manage incidents. Designing and using a priority matrix to determine the priority of all incidents that are reported by users is essential for building and maintaining customer satisfaction. Moist of the time your support teams will have more open incidents that they have the capacity to handle. A priority matrix will help them to sequence their activities, working on the most important incidents first. For managing incidents, the priority matrix will use an assessment of how the incident is affecting users, both in terms of impact and urgency, to come up with the priority. Using the priority matrix in this way will ensure that the incidents affecting the business take priority, removing any guess work from support staff, and help to avoid them ‘cherry picking’ the tasks that they’d prefer to do first.

Most toolsets support the automatic allocation of priority to an incident by using an in-built priority. This can help to speed up the incident management process, although it can still be a good idea for the service desk staff to review the priority that has been automatically assigned using the matrix as they may have incorrectly input the impact and urgency.

Some toolsets allow for particular users, such as Directors of the business and critical users, to be identified as Very Important Persons (VIP). When an incident is received for these users, the toolset can automatically increase the urgency and/or impact for use in the priority matrix, enabling the allocation of higher than usual priorities for these incidents.

Toolsets also have features that can assess incident impact based on factors including the criticality of particular systems or services, times of day, and groups of users, which are then factored into the lookup of the priority matrix to determine the appropriate incident priority. The toolset will record these factors against the incident, which can be used to support the priority derived from the matrix in the event of any subsequent dispute.

It is a good idea to develop a procedure for the dispute of incident priorities. Whilst a priority matrix will simplify the assignment of incident priorities, the resulting priority is still dependent on information gathered from users and monitoring systems, and user expectations can vary. Hence there will be occasions when the priority matrix gives the incident a different priority to the one expected by the user. When this happens, the user must be able to dispute the priority that has been assigned from using the matrix, with the ability for the service desk to amend the priority if the dispute is upheld.

It must also be possible to change the priority of an incident during its lifecyle. For many incidents, the full impact is not known when first reported by a single user. The incident is given a low priority, as the lookup of the priority matrix uses a low impact. As more users report the same or similar symptoms, the impact increases, and the priority matrix would provide a higher priority. For this type of incident, where the known impact increases over time, it is important to continue to use the priority matrix to determine the new priority. Service desks can react to pressure from users to increase priorities without using the matrix. This can result in inconsistencies, and encourage unhelpful user behaviours.

 

Using a priority matrix for major incidents

A major incident is an incident with an extreme adverse impact on the business. This could be from excessive disruption to the services, or risk of subsequent disruption from events such as a virus attack.  It is standard practice to have a separate variant of the incident management process for these major incidents, which recognizes the necessary urgency to resolve the incident. Your priority matrix must be able to clearly identify which incidents are major incidents, based on the impact and urgency. Major incidents by definition have the highest priority. It is important to verify through scenario testing that your priority matrix can clearly identify which incidents are major and which are just high priority.  

Which priorities are defined as major incidents will depend on how many different priorities are included in your priority matrix. If you only have three priorities, then major incidents will always be P1. However, With just three levels of priority you risk invoking your major incident process on a regular basis.  It is much better to have a greater number of priorities in your priority matrix, reserving P1 for genuine major incidents that have an extreme adverse impact on the business. The different levels of Impact and Urgency in your priority matrix need to be carefully designed to come out with a P1 for all genuine major incidents. This requires careful analysis of your services, including assessment of their true criticality to the business, and also an understanding of how users utilize those services.

Using a priority matrix for problems

A priority matrix can be useful to assess the priority of problems as well as incidents. The considerations for problems are the same as for incidents, the primary axes for the priority matrix can still be Impact and Urgency. The assessments for each of these dimensions in a priority matrix for problems will be similar, however, the guidance and resulting priority will be different.  Impact for the priority matrix can still be based on the proportion is users affected by the particular problem, so that the priority increases as more users are affected. However, Urgency for the priority matrix should take into account more than just the criticality of the affected service to the organization. Other factors that should be taken into consideration when using the priority matrix are the feasibility of resolving the problem, the cost of resolution weighed against the benefit of resolution, and most importantly, the existence of acceptable workarounds. For example, a priority matrix could come out with a low priority for a problem that is affecting all users, but which has an acceptable workaround even if the service is a critical service.  In the same way, the priority matrix could determine a low priority for a problem that is affecting multiple users but where the cost of resolution is significantly greater than the benefit gained from fixing it.

This can be a complex area to model, hence most organizations that have adopted a priority matrix for problems use the matrix to provide an initial indication of the problem priority. Development teams have a finite capacity, and hence are likely to have more problems of the same priority than they can deal with at the same time. The initial priority derived from the priority matrix is jointly reviewed by user representatives and IT staff, taking into account the other factors and the other problems, including the time estimated to fix each problem.

Using a priority matrix for changes

A priority matrix can be useful in change management when there are more changes than the change advisory board can review in the time available. Impact and Urgency can be used in the priority matrix, just as they are for incident management and problem management. However, in a priority matrix for change management the Impact should be thought of in two ways: The adverse impact to the organization if the change is not done, and the beneficial impact to the organization of doing the change. This should be reflected in the priority matrix as there will be a mix of changes that resolve issues, changes that make improvements, and changes that add new functionality. The priority matrix can consider Urgency based on criticality, but for change management, the assessment should be based on how essential the change is to the organization. Some changes have to be made to maintain competitiveness in today's digital economy, others have to be made to resolve high impacting incidents.  Assessing urgency for the priority matrix in this way can also help with the scheduling of the change, ensuring that the most urgent changes take priority for implementation.

A priority matrix for changes can also help reviewers gain a general understanding of the change, as the matrix will illustrate the relative impact and urgency. The matrix can help to avoid the situation where IT is pushing to urgently implement a change that has limited value to the business.

Using a priority matrix for service continuity management

IT service continuity management is the process that restores service after major loss of service, often called ‘disaster recovery’.  A priority matrix can be very useful for organizations with a large number of systems. In the event of a disaster, it is highly likely that there will be insufficient resources to recover all systems at the same time. Decisions will have to be made on which to restore first, a priority matrix can help with these decisions. Ideally the priority matrix should be designed and tested before the disaster. The dimensions of the priority matrix will be Impact and Urgency, in the same way as the priority matrices used by other processes. The aim is to use the priority matrix to prioritize recovery for the systems based on business requirements. Hence the definitions of Impact and Urgency in the priority matrix need to reflect this. The definitions will be fully dependent on each organization. For example, for an organization that sells over the internet, all systems that enable the selling service would be allocated a higher urgency in the priority matrix, as these are more critical to recover. Impact for the priority matrix can be based on the number of users affected, which would be combined with Urgency in the matrix to give an appropriate priority for service restoration.

Summary

If used correctly, a priority matrix is a useful and valuable tool for every ITSM process. The priority matrix concept will help drive consistency and understanding, reduce reliance on individual knowledge, and challenge ITSM functions to focus prioritization of tasks based on business benefit.