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.
Impact
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:
- 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
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
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:
- Critical/severe
- Major/high
- Medium
- Minor/low
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.
