Priority determination of urgency, impact, and effect/complexity to determine resolution time on SLA

[Erna Putri Utami]

I want to ask about determining priorities for handling incident reports and service requests by IT. Because I only know that there is an impact and urgency matrix or an impact and effort matrix. How do I combine the three (impact, urgency, and effort) to determine priorities.

[Walter Buggenhout]

H @Erna Putri Utami,

I would say, basically in the same way as you would do with only impact/urgency. You define a series of values for each element you want to bring into a calculation, you determine a formula to calculate a number that then resolves into one of your priorities.

But - to be honest - bringing effort into the calculation to determine priority seems like a terrible idea. It would mean you have to make an estimate of the effort before you can even begin calculation your priority. Most likely, that is information you won't have when new tickets get created. 

Assuming for a moment that you somehow do have this information, how are you going to manage it? Suppose somebody a ransomware attack - it may be an enormous effort to get this resolved, but are you going to let that influence your priority with the issue (given probably half your company is not able to work anymore)?

If you want to use priority to determine which items you need to work on first, I would dare to consider keeping effort as a separate piece of information. Adding it as a field your items may help you decide which items to work on first when you look at stuff with equal priorities. 

Hope this helps!

[Erna Putri Utami]

Thank you for your response Mr. @Walter Buggenhout . I want to ask again, if effort really influences someone in completing a ticket, for example urgency and impact are both critical, if we use a matrix between urgency and impact then the priority is critical, where for example the resolution time for critical priorities is a maximum of 4 hours. But the effort is very difficult and tickets can be completed in more than 4 hours. Because this exceeds the time allotted for critical priorities, and affects the performance assessment of the person working on that ticket.

how about that? if you can help answer my question. I am very grateful.

[Walter Buggenhout]

To be honest, @Erna Putri Utami, a lot depends on what SLA commitments you engage into. If they are realistic, then I have no problems with those. If they are not, you will probably risk burning out your team ...

There's things you can control and there are things you cannot control. It is very common to split your SLA's into different targets:

• response time (i.e. how long you take to pick up a new request and let the customer know you have probably started investigating the request) is something you should be able to control;
• resolution time (i.e. how long it takes you to resolve the issue) is much more difficult indeed, since there is absolutely no way of knowing what strange things your customers may ask you.

In a service environment, you will receive different types of requests: incidents (things that are broken), service and change requests, ... It is quite common to apply different SLA targets based on the type of request. If someone tells you something is broken: fix it. If someone would like a new feature, confirm that you received the request and that you will (or will not) add it to your roadmap. And take your time to deliver it.

In that last scenario, effort is indeed a very relevant factor. However, it should be part of your standard development process and maybe influence your communication with your customer, but not the performance review of your service desk employees. When a customer asks you something that cannot possibly fit in you SLA agreements, there is probably something wrong with your agreement.

Still - if you want to factor in effort in your prioritisation process, all you need to do is provide a custom field for it to be filled out. And then - obviously - apply a formula to calculate a resulting value. Most commonly, the higher the effort, the lower the priority score you would want to return. So, you can find inspiration in e.g. the weighted shortest job first (WSJF) method used in SAFe. The formula there comes down to Cost of Delay / Job Size (in your scenario, quite similar:

(urgency x impact) / effort

The problem is that you need effort in order to avoid errors in your calculation. So either your customer will have to provide a value when creating a ticket (which is not something your customer should do) or you would need to

• use a default value at ticket creation (which voids the whole point of using it)
• make it an absolute priority for your team to estimate every incoming request as soon as possible (while I would rather see them spend their time on fixing things)

[Erna Putri Utami]

Thank you for your response Mr @Walter Buggenhout . I am starting to understand this priority determination and I just found out that there is a calculation (urgency x impact) /effort. But can you give a related example, about

• use a default value at ticket creation (which voids the whole point of using it)
• make it an absolute priority for your team to estimate every incoming request as soon as possible (while I would rather see them spend their time on fixing things)