Pink Elephant
The IT Service Management Experts

Troy's Blog

The Hitch Hiker's Guide to the IT Galaxy and Beyond
Don't Panic



Troy Dumoulin Photo

Troy DuMoulin, VP, Research & Development

Troy is a leading ITIL®, IT Governance & Lean IT authority with a solid and rich background in Executive IT Management consulting. Troy holds the ITIL Service Manager and Expert certifications and has extensive experience in leading IT Service Management (ITSM) programs with a regional and global scope.

He is a frequent speaker at IT Management events and is a contributing author to multiple ITSM and Lean IT books, papers and official ITIL publications including ITIL’s Planning To Implement IT Service Management and Continual Service Improvement.


The Guide

"This blog is dedicated to making sense out of the shifting landscape of IT Management. Just when we thought we had a good handle on managing technology, the job we thought we knew is being threatened by strange acronyms like ITIL, Lean, Agile, DevOps, CMMI, COBIT, ect.. Suddenly the rules have changed and we are not sure why. The goal of this blog is to offer an element of sanity and logic to what can appear to be chaos."

Hitch Hiker's Guide to the Galaxy

"In many of the more relaxed civilizations on the Outer Eastern Rim of the Galaxy, the Hitch Hiker’s Guide has already supplanted the great Encyclopedia Galactic as the standard repository of all knowledge and wisdom, for though it has many omissions and contains much that is apocryphal, or at least wildly inaccurate, it scores over the older more pedestrian work in two important respects.

First, it is slightly cheaper: and secondly it has the words DON’T PANIC inscribed in large friendly letters on its cover."
~Douglas Adams


Troy On Twitter

Recent Entries



Other Blogs


The Practicality of Prioritization

An IT Priority Model Cannot Be Relative but Must Represent Accepted Corporate Truth!

Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing ever happened. ~Sir Winston Churchill

We live in an age of relativism where high value is placed on the concept of independent thought and self direction. We often take this principle to the point where people are uncomfortable with the idea of taking a stand and establishing absolute truth.

However, there are some places where agreement on corporate truth is critical for successful policy and process collaboration. One of these areas is the policy of prioritization. Imagine an IT department where there is no agreement on how much impact a given incident has on the business customer. Or what constitutes a minor change versus one of significant business risk. In this organization one person believes an incident to represent a minor impact while another believes the sky is falling.

If this sounds familiar then consider that an organization that does not have a solid consensus around a model for establishing process priority has no hope of supporting service level agreements. In an organization where personal interpretation of the situation is the norm there is no real basis for establishing agreed upon escalation rules and change approval models

The ITIL policy of priority is based on the concept that Priority = Impact + Urgency

By looking at something from the combined perspective of Impact (often referred to as severity or degree of failure) and Urgency (time sensitivity and business criticality) we can derive Priority.

They key difference that ITIL presents with the concept of Priority versus the classic usage of Severity is that severity alone does not provide enough context for Prioritization. The urgency factor needs to be added to severity in order to provide an accurate understanding of how to prioritize activity.

Priority Model
Impact is a measure of the degree of realized or potential business process failure caused by an incident, problem, change or release.  In one sense you can equate Impact to equal the extent to which agreed service level agreements are or will be degraded. The scope of service degradation is measured by the number of services, systems or users affected. Generally, impact is differentiated by scope:

  • High: Business Unit, floor, branch or LOB
  • Medium: small group of users
  • Low: single user

However, impact can also be altered by VIP status, which can be based on organizational hierarchy (e.g. executives, VP’s, managing directors) or a particular role (i.e. specific users who justify immediate or special attention based on business role). In the case of users with VIP status, impact can be assigned as follows:

  • High: a group of users with VIP status
  • Medium: a single user with VIP status

Since a high-impact incident does not by default, have to be solved immediately, it is not necessarily a high priority incident. Urgency provides a second measure of business criticality, which indicates the necessary speed of resolving an incident of a certain impact. Whereas impact is defined by scope, urgency is defined by time. It is determined by the time sensitivity requirement for a resolution, as measured in terms of financial, brand, or security impact of a particular service’s downtime. For Example: for the same period of downtime, a core business service will cost the business more than a back office administration service. Therefore, urgency is also based on levels of time sensitivity:

  • High: Core Business Service – an activity that has a direct financial, brand or security impact on the business organization (e.g. trading applications)
  • Medium: Support Service – an activity that directly supports the execution of a core business service (e.g. printing services)
  • Low: Non-urgent Service – an activity that does not directly support a core business service and is not time sensitive (e.g. Internal Company Intranet Portal)

This is an example model only but provides a good basis for discussion. They key factor represented in this blog post is that an organization must have organizational consensus around the policy for establishing priority in order to support cross process collaboration.

You will find a podcast on this subject On Pink Elephant’s iTunes Site

New Addition: Based on a comment I have provided a more complex model that reflects an additional example:
Example Priority Model

Troy’s thoughts what are yours?


Posted by Troy DuMoulin on 03/22 at 01:30 AM
  1. I have been intrigued by similar models, Troy, and was incredibly excited to see this blog entry.  I too proposed something similar and am hoping to refine the logic behind the model to be more organizationally persuasive.

    One difference between my model and your own is that I consider ITIL to suggest that Priority = Impact X Urgency rather than Priority = Impact + Urgency.  Either way, I agree that ITIL suggests that priority is a combination of an impact and urgency analysis – and that arriving at priority thusly helps align IT service support and delivery to business realities (ideally, as captured in SLAs establishing what is an impact to service and the urgency of restoring service to full functionality).

    I was also intrigued by your matrix, which seems to present some “snags” (and I know you have presented only a straw-man model for sake of discussion but I would like some other thoughts on the matter).  For instance, by either calculation (P=I x U or P=I + U), something with a combination of the same Impact and Urgency should receive equivalent priority, but in your matrix there are several cases where I and U are the same but P is different (i.e. there is one High/Medium combination that comes out “Critical” where another High/Medium combination comes out “High” – but in a double 3 tier high/med/low model following P=I + U those combinations should be equivalent).  This suggests, in fact, there are some finer distinctions out there representing some “corporate truth” that have not been easily captured in the metric (i.e. there must be some organizationally accepted principle hidden in your model where some “mediums” will be treated with higher priority than other “mediums” despite the general formula of determining priority).

    To fix this and better illustrate specific “corporate truths”, I recently proposed the Priority = Impact X Urgency calculation with a rigid application of the results of that mathematical function.  That is, to the degree we are able to assess different, organizationally relevant levels of impact and urgency, an expanded set of Priority codes can be outlined.  It is not easy to put these Priority codes into words, but the resulting number produced does give a set of priorities that match the assessment of impact and urgency rather nicely (and, again, this is a simplistic straw-man model … ‘normalizing’ it has been a challenge I won’t address in this post … if you produce the matrix you’ll start seeing some of the idiosyncrasies needing normalizing).

    For instance, consider a 3-levels-of-impact, 3-levels-of-urgency organization.  This yields up to 9 levels of priority and gives a great deal of flexibility to the support organization working to ensure services are delivered in ways relevant to the business.  A high impact issue (impact level “1”) x a high urgency issue (urgency level “1”) produces a Priority 1 incident (P = 1[I] X 1[U]); a medium impact issue (impact level “2”) combined with a high urgency issue (urgency level “1”) produces Priority 2 ... low impacts (level “3”) combined with low urgency (level “3”) produces a Priority 9 incident (i.e. something that the organization considers very low on the radar).  Even using the additive model, however, you would expect at least 5 priorities and would expect that a “high” impact + a “medium” urgency should yield the same priority as a “medium” impact with “high” urgency”.

    Needless to say, my proposal scares some people.  My organization is used to dealing with 4 priorities and the thought of 9 is scary.  But, I argue, it is actually easier and produces a set of results more organizationally relevant than using a mere 4 priorities.  Why?  We ask our technicians to first assess priority in one of 4 ways (4 choices to make) and then ask them to assess impact against a set of background urgencies.  This not only works “backwards” but forces technicians to fit disparate categories of urgency and impact into 4 categories where, inevitably, some higher level issues will be treated equivalently to lower ones.  By reversing the process whereby a technician assesses only impact on a 3 choice scale, it actually simplifies their work (3 choices to consider rather than 4).  “Urgency” is a function of the service level agreement established with a customer and can be stored in the background (i.e. it doesn’t change over time and technicians need not assess it – it is already established per agreement).  “Priority” therefore no longer requires mental gyrations to assess, as the single choice regarding customer impact generates priority automatically – the system can calculate priority and all its attendant response time requirements based on the technician’s impact assessment and the stored urgency information.

    Moreover, I argue, this provides some key benefits to the organization:  First, it allows a finer gauging of technician responses and helps avoid making mistakes “at the margins” by grouping disparate impact/urgency combinations into an arbitrary number of priority categories.  Secondly, it focuses attention on the customer impact rather than the organizational process of prioritization – that is, it automates the prioritization based on human assessment of impact arriving from interaction between service providers and their customers.  At that point, does it really matter that there are 9, 10, 12, or 20 “priority” levels since those priority levels (and the attendant response requirements) are tied directly to corporate truth?

    Either way, I think the basic construct you’ve outlined is precisely what is needed … I’d really like to fine-tune it into an automatable and deployable concept.

    smcd’s thoughts … others?

    Posted by .(JavaScript must be enabled to view this email address)  on  03/22  at  03:03 PM
  2. Dear SMCD

    You have obviously spent a long time thinking about this model and have gone into detail to ensure its mathematical correctness. I am not sure if it technically matters whether it is I + U or I x U but what is true is that both have to be looked at together to understand Priority.

    As I said what I posted here is a Strawman model and is for discussion purposes only. In reality the model does need to be more complex to consider other elements such as Brand exposure and Security issues. In fact automated applications of models such as this one usually take on the character of a wizard or automated script which outputs a weighted score to indicate High, Medium & Low calculations for Impact & Urgency.

    I have placed a new link on the post that provides a view a more realistic and weighted approach to building a comprehensive model. This is the type of content Pink provides in our Atlas product.

    One word of caution is that if you make your model to complex eg: 9 levels then it may loose the buy in it needs to be effective. The key is to balance complexity with simplicity.



    Posted by Troy DuMoulin  on  03/25  at  10:31 PM
  3. Thanks, Troy.  The additional link is valuable information.  I especially appreciated seeing how it distilled a highly complex “scoring” sheet into a simpler urgency matrix.  For some reason, I completely forgot that grouping results into ranges was a valuable way or organizing data (i.e. if 9 priority codes are generated, much as the example you provided does for urgency, those 9 priority codes could easily be grouped into ranges to produce a simpler 4 priority system).

    And you’re right ... As any good distiller knows, you’ve gotta separate the good stuff from the rest and the most pleasant complexities are sometimes revealed in simpler elixirs separated from more heady compounds.

    Cheers indeed!  Thanks again.

    Posted by .(JavaScript must be enabled to view this email address)  on  03/27  at  10:12 AM
  4. I found this post useful in developing a priority model for incidents at an organization that previously had used severity alone.

    However, one of the major complaints I receive from IT people is that they never have the time and resources to find the root cause of problems because problems are not given any priority. It would simplify things to use the same priority model for incidents and problems, but problems often have only potential impact, i.e. if problem abc is not fixed, xyz incident could happen. How can we use a priority model to ensure that high priority problems receive the resources they require when there is currently no impact to business?

    Posted by Lee Marshall  on  06/22  at  04:33 PM
  5. Hello Lee

    One of the primary roles of the priority model is to drive behavior based on the concept of business risk. It is important to assign a Priority to problems in the same way as we do incidents. Granted often the problem is a potential risk that has either at least occurred once or not occurred in the case of a known error observed outside your organization’s service model. So in the case of Impact your right about the potential of Risk (eg 1 person or enterprise wide) so the timing is not as urgent as it would be in an active incident scenario.

    What you will want to consider is the target time to achieve at least root cause if not full problem removal.

    For example:

    Priority 1 Problems need an immediate Major Incident Review and Root Cause meeting where are stakeholder parties meet until the issue of root cause is determined. (Perhaps a condition is that there is an active P1 Incident in process or just resolved)

    Priority 2 Problems have a target of determining root cause within a week.

    Priority 3 Problems within two week’s etc..

    The key is that you establish a level of focus on identifying and removing problems from the environment based on the same business risk oriented approach that drive Incident resolutions targets.



    Posted by Troy DuMoulin  on  06/23  at  11:39 AM
  6. Hi Troy -

    Thanks for your insights on this topic. I have been working on defining Impact and Urgency levels for an incident/problem management process at my company.

    My question is regarding your definition and examples of Urgency.

    My ITIL V3 Foundations book defines urgency as “relative speed that the business requires for the resolution of an incident…often the measure of how long it will be until there is significant impact on the business.”

    Rather than being framed by time sensitivity, your examples of Urgency seem to be relative to business impact. For example:

    “High: Core Business Service – an activity that has a direct financial, brand or security impact on the business organization (e.g. trading applications)”

    To me, your definition and examples relate more to Impact. Urgency would be used to identify how quickly the Impact will occur, e.g. an audit may identify a regulatory concern with a system (High Impact if not addressed) but the regulatory body gives the company 6 months to remediate (Medium or Low Urgency).

    Can you please elaborate on your distinction between Impact and Urgency?  Please let me know if I’m thinking along the right lines.

    Thank you,

    Posted by .(JavaScript must be enabled to view this email address)  on  04/28  at  03:15 PM
  7. Hello Jonathan

    You are correct in that I am expanding on the ITIL book definition based on practice and experience.

    In response to your question: Urgency = Time Sensitivity or in other words how quickly do I have to jump relative to the Service disruption.

    The calendar concept is certainly part of this equation since I don’t have to work on something right away that will not be an impact until a future date. Another dimension of time sensitivity / urgency is risk.

    If I have to pick between a list of 5 incidents to work on I will focus on those that have the highest risk to the business customer. Not all services are equal when it comes to business risk.

    As far as impact is concerned I have found it useful to look at impact in the sense of “Degree of Failure” or in other words how wide spread is the service disruption.

    Saying that it is very possible that you may have an incident that is impacting only one person but that person just so happens to be a financial trader making online trades.

    So the business risk / exposure is high making the urgency / time to jump immediate.

    One of the challenges we face is that many organizations have used a single factor called “Severity” as their prioritization approach. This approach collapses both time sensitivity and degree of failure into a single element.

    Remember that based on what type of business you are dealing what constitutes risk will be different based on their business model.

    For Profit, Government, Health Care, Non Profit, for example.


    Posted by Troy DuMoulin  on  04/28  at  03:41 PM
  8. Hi Troy - This article was really helpful.I am curently working on a model to prioritize problems based on Urgency and Impact.
    In the first step, we are assigning color bands and these color bands decide how the RCA tracking will happen.
    The challenge is deciding what parameters are considered under Urgency and Impact.

    This article has given me some ideas I can work with… The 2 examples are really good.

    Let me know if you have a few more examples for the same.


    Posted by .(JavaScript must be enabled to view this email address)  on  10/04  at  03:27 PM
  9. Well….. I dont think this matrix is particularly good. Like so many I have seen, it describes “impact” in term of scope (numbers of user, locations etc) and “urgency” in term sof impact on buisness process and function… in essence impact x impact = priorty…???

    Urgency should be an indication of how time sensitive the incident is? e.g. is it happening now and cannot be avoided? is a work-around in place? is the event scheduled to occur and do we have enough time to avoid it?

    We also need to be clear about the response from IT that we are supporting with these priorities…. e.g. critical = all available IT resources made avialble 24x7 and vendors may be called on to action.

    just my 2 cents worth…. but looking at the matrix provided, and stepping through a really simple scenario you can see that the matrix has confused impact and urgency and views it as the same thing: scenario = all of business is impacted by an upgrade to the finance system (which is viewed by as a core service of great importance) to resolve a number of problems. work-arounds are inplace fo rthe bugs and the upgarde is to occur in 6mths time. Kinds of a kooky examples, but looking at th ematrix the upgarde would have a critical priority (meaning it is the primary focus of the IT department and vendors etc for 6 months???) obvioulsy not as the urgency has been taken away by work-arounds etc….. so why not drop the priorty based on urgency? makes sense


    Posted by .(JavaScript must be enabled to view this email address)  on  05/21  at  11:43 PM
  10. Grant

    We are going to have to agree to dis-agree on this.

    Practically speaking there are two elements to consider.

    How Big is the business impact of the service outage and then how fast do we need to move relative to other incidents that need attention.

    I have always found that the best way to describe Impact is “Degree of Failure” you can use what ever attributes you want to define this practically for your organization.

    Urgency most be tied to the mission of the company in question. Eg; Revenue gain or loss for profit based companies. Front Line Battle support for Military or Life Support Systems for Hospitals, egg.

    These two elements (Degree of Failure and Criticality to Business Mission) are at a minimum the two factors that a Service Organization must use to develop a Prioritization model.

    There are potentially other factors of course and these I show an example of in the link below the graphic.


    Posted by Troy DuMoulin  on  05/22  at  12:23 PM
  11. AS with most models I see of this type, the focus seems to be Incident management/Problem management and changes/releases related to resroring the services as a result of these incidents/problems.  Is this the intent, or is this the proposal for all changes?

    Posted by .(JavaScript must be enabled to view this email address)  on  05/28  at  12:52 PM
  12. Tom

    Change and Release are classified based on Risk and Approval level requirements. However, these processes also need to consider time sensitivity in respect to when changes and releases are positioned in queue. For this reason a Priority Model based on degree of impact and business criticality is also an important policy to define to say when certain changes must take precedence over others.

    Business Criticality does not always mean restoration of an Incident. It can apply to legal requirements, or business time pressures.


    Posted by Troy DuMoulin  on  05/28  at  02:53 PM
  13. Reading through this message thread I’m surprised there’s no mention of “expected effort”.

    If the otherwise highest priority item is going to take a small team of people a few hours to complete, then do not unreasonably delay the next highest priority item that can be addressed with the “flick of a switch”!

    Of course “common sense” should prevail and maybe my example is a bit extreme - but you get the point, right? Don’t be a slave to your priority model, however well thought out it may be.

    As Oliver Wendell Holmes said “The young man knows the rules, but the old man knows the exceptions.”

    Posted by .(JavaScript must be enabled to view this email address)  on  05/29  at  12:40 PM
  14. Absolutely David, a good reminder of the practicality part of this article.

    Your quote says it all!

    Posted by Troy DuMoulin  on  05/29  at  12:47 PM
  15. I’m with Troy on this one, i.e. the criticality of the impacted service (as agreed and defined in the Business Service Catalogue) can be a pragmatic substitute for ‘urgency’ in an incident prioritisation matrix.

    While what Grant (and ITIL) says about urgency (i.e. that urgency should be about time sensitivity) is logical, in my experience the majority of incidents are having an impact right now and not at some later time (e.g. an incident that will effect an end-of-month business process, or an incident resulting from an exception event regarding an imminent CI failure).

    However, for organisations that have a good mix of incidents that are having an impact right now and incidents that will have an impact in the future, then I agree with Grant that scope and criticality are both impact factors.

    For organisations where the vast majority of incidents are impacting the business right now, then business criticality in lieu of time sensitivity makes sense.

    Posted by Dave O'Reardon  on  10/24  at  11:59 PM
  16. Business Criticality and time sensitivity for handling Incidents and Problems are useful in planning resource utilization within an IT department.

    However client satisfaction ratings are driven by negative and positive experiences of individuals in an organisation and for many senior organisational leaders, are the real measure of how IT performance is rated.

    Getting the queue of Incidents and Problems to zero on an hourly basis and satisfy the staff needs to have their service restored to full productivity is the real objective in my opinion.

    Posted by .(JavaScript must be enabled to view this email address)  on  03/17  at  07:59 PM
  17. Thank you for your perspective Robert. While I agree that customer experience is a key measure it is one of several from a balanced score card perspective. Others include Financial, Innovation, Internal Capability (BSC). Ideally it would be great to be able to zero out all Incidents and Problems on an hourly basis and if you are able to restore all service disruptions (not just first call touch and dispatch) then you are blessed.

    However, when it comes down t making decisions about what Customer’s will be prioritized above others in the effort related to Service Restoration other factors such as who that customer is in relationship to business mission and what services are currently being addressed need to be taken into account when making hard decisions about what to work on first, second and third.


    Posted by Troy DuMoulin  on  03/20  at  02:15 PM
  18. I’m looking to write a guideline, about after an incident is created when does one consider changing the Impact or Urgency, which will adjust the priority.  Do you have any articles on the subject?

    Posted by .(JavaScript must be enabled to view this email address)  on  12/17  at  06:32 PM
  19. Hello Cornelia

    The principle of Incident Management is that the lifecycle of the incident from initiation to close is constantly reviewed for updates to changes in status, impact and urgency. The primary goal is to restore service and during the period of time this may take many factors may change which should be reflected in the incident ticket over time.

    One one to accomplish this is to establish a few key policies:

    1) There is an overall owner of the Incident ticket and thereby the customer experience regardless of where the ticket actually sits in assignment. This will typically be the Service Desk or a group which owns Incident Management of the Service Desk is outsourced. Someone in this group will be responsible to monitor the incident over time and adjust both the Impact or urgency if either of these two factors change.

    2) Another key policy is that whoever (person / group) currently has the ticket assigned to them is responsible for updating the ticket with the most relevant and recent information. This means that the Developer, Server Admin, DBA, etc.. currently working the incident updates the ticket as they initially receive it and throughout the time it is assigned to them.

    3) A third possible policy is that the overall owner updates the ticket at the end of the lifecycle with the final details related to Impact and Urgency so that reporting will accurately reflect the final state of the incident for SLA purposes.



    Posted by Troy DuMoulin  on  12/18  at  12:16 PM
  20. Thank you Troy for sharing such calculative prioritization model..

    Does this also implies on prioritizing the Change Requests & Bugs? If not can you share the guidelines to prioritize Change Requests and Bugs? please.

    Posted by .(JavaScript must be enabled to view this email address)  on  05/05  at  12:09 AM
  21. Hello Saleem, indeed it does apply to Change Requests and Bugs. Consider the Agile concept of Backlog grooming, you always want to be moving to the top of the list the highest value work in respect to business objectives. This Priority model based on business value and risk provides a policy to support that objective. In essence the change requests and bugs that should be prioritized to be worked on first should be the ones that have the higher priority.

    Posted by Troy DuMoulin  on  05/05  at  10:55 AM
  22. Troy,

    Great information.  I see you making reference here about using this with Change Requests.  Do you have an article that talks about calculating Change Risks and Impacts that you could point me to?


    Posted by .(JavaScript must be enabled to view this email address)  on  05/05  at  11:09 AM
  23. Cornelia

    While I don’t have a specific “Change Risk” model example on this blog the same approach that I use here looking at classifying what is changing “Relationship to Mission” and its potential scope of impact would be used. Take a look at the detail example of the multi factor Priority model linked above. Also you will find a Podcast on iTunes where I go into more detail at the following link:

    Title: The Practicality of Prioritization.

    Posted by Troy DuMoulin  on  05/05  at  12:22 PM
  24. Page 1 of 1 pages






Remember my personal information

Notify me of follow-up comments?

Please answer the question asked below:

2+2 is equal to?