Anyone with even minimal exposure to ITIL understands that incident priority is a factor of both impact and urgency. But, most of the conversations I have with practitioners tell me that most of us leave it at that. Frankly, a lot of service desks use something like FIFO modified by a little common sense in deciding what incidents to address first.
There are, however, a number of nuances around incident prioritization that may be worth reviewing and taking into account as you work to build mojo at your service desk. Arguably, the most important of these is the approach of tying initial incident priorities to the recovery SLAs as expressed in your service catalog. The service catalog of course describes services including the support available for services and the SLAs associated with recovery of services that fail.
In most cases, recovery SLAs within the service catalog can be grouped into a small number of tiers, thus making it easier to tie SLAs to incident priority. Too much complexity in a prioritization algorithm is generally unhelpful. In my experience, recovery SLAs for services usefully provide a starting point for urgency designations. Impact designations are more situational and tend to be driven by the extent to which a service has been disrupted, e.g. for one or many users.
One of the trickier aspects of using SLAs to drive prioritization involves deciding how to weight impact and urgency in a prioritization algorithm and how much to allow truly situational aspects of urgency to influence the algorithm. In very broad terms, information from the service catalog is usually best allowed to exert the most influence in urgency determinations. Situational factors less so. This has implications for the ‘spacing’ between urgency designations in the algorithm; urgency levels must be far enough apart to allow situational factors to influence urgency without bumping the end result into an adjacent level. Such determinations require attention to the specifics of each organization and its priorities. There are no hard and fast rules.
A couple of other basic points around prioritization merit mention.
First, priority is always relative. Incident priority is always priority relative to whatever elses is in the queue. There’s no such thing as absolute priority. The point of prioritization is to enable decisions about what work at hand is most important. The term ‘at hand’ is key here: priority is about comparing work that needs to be done, not about absolute importance.
Second, priority is dynamic. Priority can change as new incident enter the queue, as SLA boundaries approach, etc.
Third, priority is also fundamentally about work queues, not necessarily about the entire incident management process. In many cases, a single incident management process may actually consist of several work queues. Prioritization is about determining the order in which work is opened within a queue. Priority governs what happens before work is opened. After work is opened within a queue, decisions about how proceed generally fall to the support person or group handling the work.
Finally, the best prioritization schemes are mostly automated and leave little to the discretion of the support analyst. This makes complete sense when one considers that prioritization is a level one activity and is generally carried out by personnel having very little experience within the organization. Leaving matters to discretion or judgement usually leads to suboptimal results.
A lot of ITSM success is about what happens between processes, as much or more than it’s about what happens within individual processes. Incident prioritization is one such example. Here we’re linking incident management, service catalog management, and (of course) service level management. We’re using a relatively static process (service catalog management) to drive one of the most dynamic processes in ITSM: incident management. And, by doing so, we’re making good on the effort invested in building a service catalog to do much more than simply advertise services. Improved prioritization of incidents makes a real difference every minute of every day in most IT shops.
