The Reason Business as Usual Doesn’t Work in IT Service Management

According to the HappysSignals Global IT Experience Benchmark, speed of service is always the primary "factor of happiness” , good or bad, for both incidents and requests. It’s a fact that will not be a surprise to anyone. What is perhaps surprising, though, is how often slow service causes weak experiences.

Meaning from other statistical facts

According to HDI and HappySignals benchmark data (with a bit of interpretation), unacceptable slowness, or service not being provided at all, corresponds with 5 – 10% of all service tickets raised. In terms of tickets that aren’t completed straight away (on first contact), that works out to be typically at least one in every five tickets (20%).

While there will, I guess, be organizations which have found a way to ensure timeliness almost without exception (perhaps by over-staffing), in general it doesn’t take long for supported colleagues to realize that IT support is unreliable.

IT support’s purpose is to meet needs and expectations. I reckon it must follow that because most support teams are unable to consistently do this, employee experience might not be where it would like to be.

So, it begs a big question for IT service management - how can IT organizations max-out the good speed of service experiences, and eliminate the bad? How can support become reliable? To get there, it's necessary to first recognize that standard practice doesn’t work very well.

Standard practice doesn’t work very well

The incident and request management process (practice) as provided by ITSM tool vendors, is intended to provide focus on timely ticket progression, but in standard practice, it doesn’t.

It’s a fact proven by the 5 – 10% weak experience benchmark, also born-out by one of the key takeaways in the most recent HappySignals report. - “Once the SLA is breached, it seems the agent doesn’t care if it is by 5 minutes or 5 days. This can lead to hit-or-miss experiences for end-users.”

What’s more, this conclusion is drawn from their client base of predominantly large organizations and managed service providers (MSP’s) which are likely to be more operationally mature and therefore better at focused management and concerted governance. I’ve never worked for a large organization, but I know that it’s common for smaller, less operationally mature IT organizations to have many aging tickets sitting untouched for months.

Overall, it should be clearly recognized by senior managers that timeliness is not only by far the most vital of experience factors, but it is also IT support’s “big problem”, and that a better approach is needed to address it.

Why doesn’t standard practice work well?

Being busy is the go-to reason for slowness, not the process, but if a service improvement initiative were to look at identifying the actual causes of the problem, the conclusion would be:

1. Team members often work independently in highly inefficient and vulnerable ticket queue silos, with little or no cross-queue cover. Individuation naturally stifles teamwork.
2. Ticket prioritization does not guide mid-lifecycle activity until there is a SLA breach warning.
3. Resolution SLA breach warnings are generally ineffective because the only person responsible for preventing a breach is often busy with other things, and prevention might not be sufficiently entwined in the incident and request management process.
4. Once the service level target is breached, there is no further intended or actual control in the incident and request management process. Without concerted managerial effort, a designated role to control breaches, or ramped-up teamwork, tickets are allowed to freely dwindle into abandonment.

How to achieve reliable timely service

To tackle these causes of ineffective standard practice, two improvements are needed. One is prioritization. The other is teamwork.

But there’s more…

Beyond timeliness, there’s much more that needs to be improved for IT support services, however. This article is the first in a series that will explore it all, discussed from the perspective of the two different approaches that an IT organization might decide to take.

If you suffer mid-lifecycle backlog and the need to periodically cull aged tickets as most IT organizations do, there is a real need to look at why your incident and request management process does not prevent this, and the weak service experiences that result. Or, at a minimum, there is a need to introduce good practice principles that should go some way to improving outcomes.

David Stewart is the author of TOFT, a collection of 12 tool-based practices that fill Incident and Request Management gaps.