Ah "incidents." That IT service management (ITSM) word we in IT use to describe customer issues that, rather awkwardly, means absolutely nothing to them — unlike IT "failure," "issue," and "problem" (and that's the original English language definition). But putting terminology aside, we think we have incidents and incident management covered — including prioritization — we just get on with it. But let's look at this more closely.
For those IT organizations that prioritize incidents, at the point of being alerted to them, there is often a calculation that multiplies urgency and business impact. But is this really the reality? Read on MacDuff …
Here is an example of prioritization framework
And number of users affected categorized as:
There are of course simpler prioritization frameworks and possibly those that are more complex. We then apply a standard, but not necessarily agreed, response and fix time.
Here is an example of incident response and fix times
These of course can again vary from company to company.
But let's look beyond these best practices — reality is far messier
It all makes sense — even if the math can be a little hard — and it's what we are taught in our ITIL*** training.
But does it really make sense? Does it really make sense to the consumers or customers of IT services? When you stop to think about it, in the words of Johnny Nash — "there are more questions than answers":
- Do service desk agents actually consistently apply this either directly or via some pre-set values in the ITSM tool?
- If a service desk agent has rigorously applied the formulae, or used a system setting, and arrived at the prioritization and fix time can they justify it to the customer?
- Or looking at it another way, how does it meet the customer's expectations? Expectations that have been pumped-up through their consumer-IT experiences.
- Is this what was agreed by a consortium of business users or is this what the IT organization has singularly dictated based on best practice? I'd imagine it is the latter.
And how does first contact resolution play into this? If you think about it, our service desk agents are sitting there "primed by their performance metrics" to aim for first contact resolution, i.e. to operate on a first-in, first-out basis. Thus prioritization goes out of the window if that particular service desk agent can help. Or even if they think they can help!
So are we really prioritizing incidents based on business need (whether it be impact and urgency or something else) or are we just doing what we think is best for them? Are we prioritizing based on someone else's "best practice" determination or, even worse, subjecting customers to prioritization based on ease of resolution, available knowledge, and possibly even personal preference — who doesn't do the stuff they like to do first?
It's scary when you stop to think about it. I wish I had the answer … maybe you do?
*** The ITSM best practice framework formerly known as the IT Infrastructure Library.
