Why does incident management fail to keep the promise?

Incident management promises to restore normal service operations as quickly as it can. But, does it really? Despite the close-to-meticulous process in place, it still falls short of expectations when executed.

Let me start by narrating an incident (not the ITIL one) from my first job as a level 2 support engineer. Our automated report generator had crashed and the users weren’t able to procure their reports on time – which essentially meant our services were disrupted. Obviously, we were thwarted by tickets and we escalated them to level 3 (SMEs) to fix the reporting engine.

After a week and a two-level priority jump, the issue was finally fixed and automated reports were back in action. But a week without these reports meant that the business would face the brunt of it all.

In hindsight, I realize that we were so focused on fixing the issue that we completely forgot about the business. The business didn’t care about the reporting engine, they only cared about the report or lack thereof. Our action plan should have included a temporary fix to manually run the reports and send it across until the original problem was resolved. Instead, we were in over our heads from just the IT perspective of fixing things.

An incident can be resolved once we restore the affected service back to normalcy even when the issue is not fixed. Think about it – reinstating a service to the usual order of business doesn’t necessarily mean we have to fix the original issue. It can be achieved through a number of other ways.

They are called workarounds.

So what is incident management missing?

Purpose. We’re missing the whole point of incident management. Sometimes, I think we’re forgetting the purpose of IT.  Why does IT even exist?

IT doesn’t exist to fix broken things – despite the majority of the world believing otherwise. IT serves a bigger purpose as an enabler. IT exists to enable the business to meet its objectives. But in reality, is IT even aware of these business objectives? Or, does IT even care about all these details?

As cliched as it may be, let’s look at a light bulb example.

When a light bulb goes out plunging the entire room into darkness, we look for the fastest way to fix it or replace it. More often than not, we easily forget the emergency flashlight in our pockets. In this scenario, the immediate focus should be on bringing the light back and not fixing the light bulb.

A broken light bulb is an IT problem; darkness is the actual business problem. Click To Tweet

IT needs to start thinking about the business a little more proactively – contribute to sorting out the actual issue as compared to dismissing that as somebody else’s problem. IT needs to change the way it looks at incidents. An incident is more than just a ticket number in your help desk – it’s a roadblock that’s preventing the business from functioning smoothly. So our focus should be on helping remove that obstacle.

Although it’s ingrained in IT to just fix the issues and get on with work, there’s a pivotal need to also shift focus to the business. While there are times that call for an immediate fix of the issue, you’ll be surprised to see new possibilities open up when you take a step back and look at the bigger picture.

Incident management process should encourage the service desk to think outside the process. Think outside the box, think outside IT to restore the service.

What should IT do now?

Prevent incidents rather than resolving them.

My incident manager used to proudly present the number of incidents we resolved every week to the organization with extensive reports. I sat there thinking, “Doesn’t that mean we’re managing a service that’s constantly disrupting the business?” Resolving a high number of incidents gives the service desk a false sense of accomplishment that keeps them away from the actual end goal.

incident management

IT should focus on preventing incidents rather than resolving them.

As unsettling as it may sound, IT should be aiming for a utopian future with zero incidents and no service desk software. While we may never get there, it definitely matters that we constantly try to achieve that goal.

How can IT do that?

Focus on other processes that render incident management useless.

Problem management is an under-appreciated process. If only we could focus on problem management as much as we focused on incident management, there may actually not be enough incidents left to manage.

Knowledge management, if done effectively, can prevent a lot of incidents. A well-populated knowledge base can even educate the user to do a right-click instead of a left-click. You’ll be surprised at the number of incidents caused by a mere wrong click. However, if we’re doing knowledge management just for the sake of it – be warned. It can cause more trouble than it can solve.

All of this might sound far-fetched to execute in reality but I’d like to go ahead anyway and make a request to IT. The next time you receive an incident, do take a moment to think beyond metrics and more about its impact on the business as a whole. The greater good, if you will.