Skip to main content

Leveraging Prioritized Incident Management

By September 27, 2017Article

The helpdesk tickets keep rolling in and, more often than not, become overwhelming to your service deck employees to manage. Problems of various importance lack priority and only the most mission critical are addressed regularly. For example, the offline printer on the seventh floor sits idle, the queue for room reservations becomes nothing more than a first-come-first-served process of whomever can grab a room when they can, and the password reset requests are handled as times allows while all other hands on deck address a phishing attack.

Priorities in such situations are rarely easy to establish nor are they clear cut. Organizations that operate a largely manually driven IT desk may struggle with prioritizing incidents on a detailed level. 

The ITIL-framework and incident management

From an ITIL-framework, a task’s priority can be identified using the equation, “impact multiplied urgency.” How do we decide what in the real world counts toward these factors? There are four things that help us map out a priority matrix: 

  1. How is productivity affected?
  2. How many users (and what type of user organizational leadership, part-time staff or other) are affected?
  3. How many systems or services are affected?
  4. How critical are these systems/services to the organization?

To use my company (TOPdesk) as an example, we work with five “impact” levels: organization, location, department, team and individual. Thus, regarding the impact, for each of these five areas we ask ourselves if there is something in them that risks sinking the entire organization, or something that makes “Richard” or “Tamara” in accounting mildly inconvenienced.

As for “urgency,” we have found that three levels are ideal for most organizations: critical, normal and low. This is the priority matrix we (TOPdesk) work with:

Mapping impact and urgency on one axis each, it’s fairly easy to set up a priority matrix that can be used to help your teams successfully address incidents in their proper order, while providing you with an overview of issues and tasks that must be addressed. Those issues that must be dealt with quickly can be tackled while the lower priority tasks can be handled within an acceptable period of time – to be determined by the organization, of course. Also, such a process can help teach your team the kind of thinking required to prioritize tasks correctly and quicker.

Understanding different priority levels

Using the formula referenced above, you can assign any number of priorities. TOPdesk uses up to seven, but this number can differ with the amount of urgency and impact levels you use or determine are best for your organization. Let me give you some real-world examples of what these levels of urgency might correlate to:

Critical priority tasks

A task classed as “critical” (P2 and up) usually includes the following:

  • A very important system has gone down,
  • There is little or no functionality and no workarounds
  • Data has been corrupted
  • The majority or all users are affected
  • There are potential legal or regulatory ramifications

 Examples of these sorts of failures are network outages, viruses, system failure or email outages. There are many more other critical issues that could fall under this priority indicator, but the list here is illustrative. There are a plethora of issues that these factors can encompass, often unique to the organization. 

Normal priority tasks

“Normal” priority tasks usually have priority P3 through P5 assigned to them and include:

  • Basic functionality, but with some restrictions
  • Workarounds are available, to some extent
  • More than one user is affected

 These are often standard IT issues, such as non-functioning printers or certain vital applications won’t launch on individual machines. Clearly these issues are still important in allowing your colleagues in other departments do their daily tasks; however, they also are clearly not as urgent as the examples we have been through so far.

Low importance tasks

Finally, “low” priority tasks (< P6) include minor issues where no functionality is affected and it’s really nothing more than cosmetic issue or minor annoyance to a user. These issues usually include things like spelling errors or typos on one of the organization’s web pages or forms. Of course these issues need to be fixed, but should not be prioritized above higher impact tasks that are likely to impact customers, business operation and/or potential growth.

Timelines to act

Response times to any of these issues is likely to vary from organization to organization. For some, a P1 response might be within 15 minutes, and if unresolved, as escalation by the 30-minute mark. A P2 issue could be up to four hours to fix, with an escalation in the fifth hour if a solution cannot be found. A P3 task would receive a first fix time of eight hours, with an escalation if unresolved, and P4 would have a full 24 hours, etc. These are guidelines only, but serve as examples of how you can apply your priorities and response times. 

The previous illustrations are designed to lead you to a culture of nimbleness, responsiveness and accountability with those you serve. Doing so might establish a system for prioritizing incidents on a detailed level and provide some confidence to your service teams for how they can best support the organization and its people.

 

Nancy Van Elsacker Louisnord is president of TOPdesk US.