What Is Impact & Effort Prioritization (Matrix)?
This is a decision-making / prioritization practice for selection of ideas (feature ideas, performance ideas, growth ideas). It is a 2 by 2 matrix comparing Impact vs Effort. A variation of the matrix may consider Effort+Costs or Complexity as representation of both effort and costs.
- Best Ideas - High Impact / Low Effort
- Research required - High Impact / High Effort
- Things to avoid - Low Impact / Low Effort
- Bad ideas - Low Impact / High Effort
Why Do Impact & Effort Prioritization (Matrix)?
The Eisenhower Matrix, which is also known as the Urgent-Important Matrix, helps you prioritize your tasks based upon their urgency and importance. It also allows you to identify tasks that you should either delegate or leave undone.
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 time frame. As a bonus, it also teaches the team the right kind of thinking, so that they can start prioritizing tasks correctly quicker. Many thanks for sharing this with me. It is a great help. However, I'm currently looking at creating the SLA matrix initially and for the workflow to set the priority automatically based upon urgency and impact. The urgency and impact would be complete by the end-user in the self-service portal. An impact effort matrix is a decision-making tool that assists people to manage their time more efficiently. Each potential idea, strategy or project is assessed based on the level of effort required and the potential impact or benefits they will have.
- This practice opens up the product development for the whole team
- Developing new products goes hand in hand with generation of ideas, hypothesis and their testing/validation. Unfortunately, it is mostly impossible to test and evaluate all ideas and hypothesis we can come up with. This requires us to filter and prioritize which of them to work on
- It is a simple, easy to understand, very visual and can include the whole team in the process of transparent selection of ideas/hypothesis to work on first
- Helps the Product Managers (Product Owners) in prioritisation, building the product roadmap/backlog and explaining priorities to stakeholders
- It helps identify directions and ideas for pivoting
How to do Impact & Effort Prioritization (Matrix)?
The source of ideas and hypothesis are practices like Event Storming, Impact Mapping, HMW, User Research, Empathy Mapping. While we perform those aforementioned practices, often ideas would emerge for possible improvements or new hypothesis may form. Some of them may be already formulated as HMW questions.
Before adding any of them as items on the Product Backlog these ideas & hypothesis would typically need some research, analysis and further elaboration. As any team has a limit of bandwidth and attention, prioritisation is required and any activities would be added as items in the Product Backlog.
Once prioritised these ideas & hypothesis may lead to:
- New stories being added
- Complete new features being broken down into new stories
- User Research
Look at Impact & Effort Prioritization (Matrix)
Links we love
Check out these great links which can help you dive a little deeper into running the Impact & Effort Prioritization (Matrix) practice with your team, customers or stakeholders.
Impact Urgency Priority Matrix Excel
Discuss with the Community
Myles Suer, writing for CIO magazine, states that IT leaders “need to focus upon things which provide value to customers”. These things include the time and effort spent on reducing business friction. When it comes to business priorities, nothing speaks louder than having available and reliable IT services that support business outcomes.
Of course, struggles to align IT with business needs are well documented. But if you take a different view—a view of how your handle incidents, changes, and requests—you’ll get a clearer picture on priorities from both sides.
To determine whether something is a value-add, you must define, prioritize, and measure the activities that do and don’t support such efforts.
Prioritization is vital for IT and business needs: it tells us the relative importance of an incident, so you’ll know how quickly to respond to address it, and how long that effort might take. In ITSM, the most common prioritization model involves understanding impact and urgency. How IT responds, handles, and resolves any request or issue to the business and/or customers depends upon what both parties think about impact and urgency.
Though you can boil these components down to a simple mathematical equation, I caution you against this. Instead, looking at impact, urgency, and priority is more about making decisions about relative importance and context. These are items only you and your company can define, not an equation.
Let’s take a look at each of these factors and how context and relativity support them.
ITILv3 defines impact as a measure of the effect of an incident, problem, or change on business processes.
This effect could be positive: a return on investment or customer satisfaction such as a new feature or improvement to a product. Conversely, it could be very negative based on the degree of damage or cost that results. Loss of revenue, manhours, or customers following IT service downtime or poor performance are all negative effects.
Usually, impact would not be expressed in absolute terms, but rather a range or degree that is subject to the interpretation of your company’s context. This range might include:
Eisenhower's Importance Urgency Matrix
- Number of customers/users affected
- Amount of lost revenue or incurred costs
- Number of IT systems/services/elements involved
A variety of terms can help identify the impact, or effect, of an incident:
- High, medium, low
- Enterprise-wide, extensive/widespread, moderate/multi-user, individual/single user
- Critical, significant, minor
Remember that words matter: all involved parties must share the same understanding of the scales you use. Clear, common understanding of the impact scale is the first step in effective prioritizing.
Urgency is not about effect as much as it is about time. A function of time, urgency depends on the speed at which the business or the customer would expect or want something. That might be restoring service to normal operation, or developing, deploying, and delivering a new or updated service or product.
The longer that your company is willing to wait or can afford to be delayed, the lower your urgency. Anything that significantly affects your business from an operational, compliance, or financial perspective is generally more pressing than impacts on other perspectives. For example, a VIP’s request or outage to a cloud service covering a whole region would require shorter response and resolution times because it is a more urgent issue.
Like impact, urgency scales depend on your business context, needs, and risks. Common scales used in defining urgency are critical, major, medium, and minor.
Priority is the intersection of impact and urgency. Considering impact and urgency offers your company a clearer understanding of what is more important when it comes to a change: a request or an incident.
Remember that priority is relative: it defines what actions you’ll take, but these are never set in stone—they can vary as the context shifts.
Correlating impact and urgency can be easily done in a simple matrix, which can he hardcoded into your ITSM solutions for an easy way to determine service levels and track performance measures when treating incidents, problems, requests, or changes. Priority scales are usually defined as:
Here’s an example of an impact, urgency, and priority matrix. Anything that has both high impact and high urgency gets the highest priority, while low impact and low urgency results in the lowest priority.
Best practices for determining impact, urgency, and priority
No matrix is a one-size-fits-all framework. You’ll want to define urgency, impact, and priority alongside key stakeholders, then continually review your definitions as you encounter various scenarios. What might be high priority to the business might be much lower in the eyes of a third-party vendor; therefore, alignment across all agreements and contracts is critical.
One significant challenge I have come across: when users and support teams have the freedom to dictate the impact, urgency, and priority of their submitted issue, you’ll likely see a confusion of priorities. This freedom might be necessary for support teams to give situational context, but it can have a bad effect: most users will likely choose the highest level of priority even for mundane matters, like obtaining a gaming mouse for use even though their work involves spreadsheets.
Conversely, support teams are likely to choose lower levels due to their perception of effort involved or performance rating model applied, i.e., not wanting to restrict themselves to shorter resolution timelines that they are unlikely to meet.
To address this, you must use policy to clearly define what constitutes each scale and providing relevant examples to guide all teams involved towards a common picture and effective collaboration. Then, of course, you’ll have maintained focus on the particular components, situations, and requests that offer value to your customers.