ITIL Priority matrix



It is no secret that starting from a certain level of maturity in IT companies begin to register requests in special systems, trackers. This allows you to understand who is doing what, analyze the current situation and work already done, and a lot of useful things - with the right way of setting up the business, the benefits noticeably outweigh the bureaucracy. The order of execution of requests is governed by priorities.

For many, many years of work in supporting various IT systems, I really liked the system of four priorities, which will be discussed below. This system has shown itself so well in practice in a wide variety of projects that I am genuinely surprised when I come across other approaches to priorities. So I am willing to put in a certain amount of effort to popularize these prioritization. So that they are more often used by everyone and more often found in life.

TL; DR or immediately about the essence

If you do not have special reasons (which you are ready to clearly formulate in writing), then use the following priorities in supporting IT systems:

# Priority Definition Informal definition
1 Critical The problem entails a shutdown or complete loss of the System's performance. The main functions of the System become unavailable and the situation is critical Everything is broken. Stakeholders give up all other things and begin to solve this problem, usually work is carried out in an emergency (i.e. round-the-clock) mode.
2 High The problem entails a significant loss of the System's performance. Critical functions of the System become unavailable, and there is no applicable workaround, however, the System remains operational to a limited extent, and work on the solution will be carried out during business hours. The problem is really critical, but everything is not so bad as to go into emergency mode.
3 Moderate The problem entails an insignificant loss of the System's performance, which results in inconvenience in work or the need to use alternative or workaround solutions The problem is critical, but allows manual or other workaround
4 Low This problem does not entail a loss of the System's performance. This is a minor error or inconvenience, an error in the documentation, etc., which does not interfere with the conduct of operations in the System. The problem should be resolved, but is not critical. Oddly enough, most of all requests go here.


These priorities must be properly understood and used by all IT employees involved in the maintenance process.

Business users of IT systems should be prioritized automatically based on their specified query properties, based on relevant, but objective, properties. For example, on criticality and degree of influence:

Priority Total Per department Per user
High 1 2 3
Medium 2 3 4
Low 3 4 4


Moreover, for specific systems, the criticality can be indicated right there. For example, for an ERP system, these may be ranges of expected losses: over 100 million, from 1 to 100 million, up to 1 million. It may be appropriate to use modifiers like "VIP-person is involved" that increase or decrease the priority. The matching matrix should be kept simple and transparent, but it should not allow unnecessary high priorities.

The reason for this apparent "discrimination" is discussed below.

ITIL Priority matrix

ITIL impact urgency priority matrix

When we write regulations ourselves, we set the "rules of the game" ourselves. And it makes sense to establish such rules, not just anyhow, but to make it as convenient and efficient as possible. This is a matter of experience, but you have to start dancing from something. Further, it is already to dot in place. Let's talk about how to prioritize. Let's start as usual with the main thing - with the answer to the question "why is it needed".

We need priorities in order to distinguish from the total mass of requests those for which we want more active action. Thus, we can:

Streamline the work of the performer - tasks with a higher priority should be solved earlier. Introduce different target metrics into the SLA, depending on the priority, which, on the one hand, will show that tasks with a higher priority are being solved more urgently, and on the other hand, will allow you to evaluate how well these rules are being implemented.

It is convenient to have 3-5 priorities. Usually this is enough for all occasions, a different number of priorities is rather exotic. For the priorities to work properly, there should be 5-10 times fewer requests with a higher priority than the previous one. It turns out a kind of characteristic ladder (see fig.). And then the request with a higher priority, due to its exoticism, will attract natural attention to itself and will not get lost in the general mass of requests of a particular performer. It is assumed that, under normal load, each performer has an average of 5-15 open requests, and half of them require action from someone else. Then, with high priorities, each performer will have on average no more than 1-2 requests, and it is completely clear from which end you need to get down to work.

I would also like to have such priorities that are logical and well understood by all participants in the process. Because changing the priority too much can change the target performance metrics, and if one of the parties does not agree, then there will be a conflict that we would like to avoid. Changes in priorities should occur when the scale of the problem being solved changes or when new information appears that significantly changes the initial setting of the problem.

According to my many years of experience, a system of four priorities is very convenient. I have already given them in the article "How to write a good SLA". Well, at the beginning of this article. These are three main priorities (Low, Medium, High) and one extraordinary (Highest) for those very cases when everyone drops everything and begins to deal only with this problem to the bitter end.

This priority system is pretty intuitive. Less than three regular priorities to use is not good, scales poorly. More than three is no longer really needed, and Ockam did not order it.




ITIL incident priority matrix

It remains to justify the definition of priorities. This can be done in different ways. You can simply define without any justification. You can also justify. Without pretending to be universal, I will give one of the approaches. It is interesting only because it can be repeated for other specific conditions. The approach will be as follows. We will come up with a criterion that will allow us to single out those that require more attention from the total mass of requests. Then, from these selected ones, choose those that require even more close attention. The train of thought, I hope, is clear. And then we will make the definition of priorities from these criteria. To make the definitions clear, we will try every time to choose such a criterion so that it is as simple and understandable as possible.

I note right away that, by default, requests should always be opened with the lowest priority, and higher priorities should be justified in the request. Otherwise, the desired ladder will not work. Requiring a written justification for the higher priority is important because it forces the requester to ask themselves if the issue is really critical. Try it yourself and you will see that this is a very good filter.

Let's go back to prioritization. First of all, let's divide all requests into important and unimportant. All unimportant ones are mercilessly closed.

There are no unimportant requests. If the problem is not important to anyone, do not waste time on it. It's a matter of efficiency. The most effective way to solve unimportant problems is to admit the problem is useless and close the request. Never leave problems open for later. When you are ready to deal with them, then you will start. And if you suddenly do not remember, it means that it was not necessary. Close. Otherwise, no SLA will help. The world is imperfect, there is nothing to try to eliminate all injustices in it (see fig.). Although it is difficult to agree with this. My inner perfectionist also objected, but exactly until I confronted him with the fact that we would do unnecessary work in our free time from the main work. If your conscience is so tormenting, then mark such closed requests so that you can return to them later. When, for example, they suddenly cleared out a heap of all current problems and there was nothing else to do. But this should not happen, if there is nothing to do on a regular basis, then this means that some of the resources need to be freed up for something else, more useful.

Now we have all the important requests, let us single out the urgent and critical ones. Because not every important issue has to be urgent or critical. Quite the contrary, critical or urgent problems do not appear very often. If for some reason it seems to you that all the problems are urgent and critical, then just try to formulate in writing what is the importance and criticality of each. These are the ones for whom you do not have to struggle to come up with a reason for importance or take it impudently (you yourself do not understand, this is very critical!), Those will be critical.

Now, from the urgent and critical ones, we will choose those that do not have workarounds for solving the problem. Yes, it is not so rare that a particular situation can be dealt with without solving the original problem. Count with your hands on a piece of paper, collect a report in Excel, carry out a manual operation instead of a regular one, etc. These are all workarounds. Nobody argues that it is inconvenient to do this, and that it is necessary to solve the problem, because why do we need an IT system if it does not work. But if there is a workaround, you can spend more time on the solution. Therefore, if a workaround exists, then it should be used immediately. While the executor is trying to solve the problem in general, the initiator immediately, without wasting time, starts using a workaround. And if the initiator can afford to wait for the solution of the problem, then the problem is most likely not so important or urgent, for which he tried to pass it off, you can lower the priority.

This principle of parity is generally very important in the process of maintaining any IT systems. Neither side of the process should need more than the other. There must be parity. If one side says "well, then you yourself, and I go home, in the morning so that everything is done," then the priority must be lowered immediately and also go home. What is the point of working hard, finding a solution late at night, so that it remains unclaimed until the next working day? Either we all work, or we all disagree. This rule works especially well in emergency mode. Avral and need to go to work around the clock? Okay, the IT department is ready, if necessary, to work in this mode, for this it was created. Is the business ready? .. I don't even consider the opposite situation (when the business needs it, but IT is not ready). Such IT must be immediately dispersed in full force, since the IT department, who does not understand who is working for whom, is incompetent.

Let's go back to priorities. Do you need to prioritize something even more important? Yes, it seems to be no longer necessary. Then only a rush job.

Thus, we managed to split all requests into classes, and each next class of requests is rarer and requires closer attention and faster response, which is what we wanted:

important, but not critical requests (all new requests go here by default); urgent and critical (justification is required why); urgent and critical, for which there is no workaround (also of course with justification).

And of course the super priority:

we drop everything and deal only with this problem without sleep and rest.

The latter priority is usually allocated from the general row for the reason that they work on it around the clock, in contrast to all the previous ones, for which work is carried out during working hours. Subject to the principle of parity of necessity, this priority does not even need to be particularly determined. No one in their common sense will initiate a round-the-clock mode, if they really do not shut it down.

In total, we got four clear priorities. The wording of the definitions on the office (so that you can take it into your regulations and correct it in place), see the plate above.

You can take the names suggested by me, or you can take neutral numeric ones - the first (highest), second, third and fourth. And it happens that someone's hand does not rise to open requests with a priority called "Low". For example, I'm used to using both.




ITIL priority matrix

All of the above about priorities applies to those people who provide technical support on duty. Support staff should be familiar with the overall IT landscape and be able to prioritize objectively and consistently in accordance with internal regulations. It is better for business users of IT systems not to give the opportunity to choose a priority, but to set it automatically. A good approximation is the diagonal impact and criticality matrix from the classic ITIL priority definition. An example has already been given above.

Why is that? It's not about mistrust of users, they say, they are old and poor. It's just that for the user of the IT system, any problem that interferes with him personally will always be of the highest priority. Because it prevents him from doing his own work, and right now it is interfering. And after all, as always, it broke down at the wrong time, exactly when it was needed. Otherwise, the user would not have got into the system and, moreover, would not have contacted the support service. He already has something to do from his direct official duties. If he had a lot of requests, then he might have prioritized them. But in most cases, the user has only one support request. And the general picture of IT is unknown to him, and he is not interested, in contrast to the support staff.

And an ordinary user does not often contact the support service and, even trying to be objective, may simply fill out the request incorrectly, indicating the wrong priority, or even not specifying it at all, or indicating a higher priority just in case (it’s better to be mistaken in your own direction ). And so on.

Therefore, users will put any priority, just not the one that should be, and there is no reasonable force that would force them to set the correct priorities. So it's better not to give them the opportunity to make mistakes. Better to fill in a couple of required attributes in the request, and the output will be something pretty good that looks like a priority.

ITIL Priority matrix


An example of a priority matrix

The following table is a partial view of the priority matrix that you can create in the Priority Matrix application. If the service group was installed with content extensions, a predefined priority matrix is available with values similar to those shown in the table. Note that the variables in the priority matrix have both numeric and descriptive values.

You can create a priority matrix in the Priority Matrix application. The priority matrix predetermines the internal priorities for the service group passports, which define the given combinations of impact and urgency. After the service group agent fills in the Impact and Urgency fields in the passport record, the Internal priority field is automatically populated based on the values ​​in the priority matrix. Internal priority values ​​for passport records help determine the order in which passports will be processed.

The Priority Matrix is ​​based on the ITIL (Information Technology Infrastructure Library) concept that prioritizes impact and urgency in determining the relative priority by which elements of a sequence, such as service group passports, should be processed.

Impact is the potential impact that an unresolved problem has on an enterprise's ability to continue to effectively carry out its operations or provide services. For example, a server failure that supports a large number of customers can be considered a critical business impact.

Urgency is defined as the speed that is considered sufficient to resolve a problem due to a given impact. For example, an unresolved issue with a high potential for disrupting business operations (high impact) may have a low urgency if an interim fix or workaround is available.




Priority types

Internal Passport Priority is the priority assigned by the service group agent based on impact and urgency. In addition to the internal priority, the passport entries also include the reported priority and the specified priority. Reported priority is the priority reported by the employee who reported the problem to the service team. The priority indicated is the assumed priority of the passport, which is entered automatically based on the assigned classification. The values ​​of these additional priority types provide guidance to the service group agent in determining which impact and urgency values ​​to assign to a particular passport.