Incident Management Isn’t Just For IT

I've been working with a client to help them improve their IT service management processes and tools. Whenever I work on this kind of engagement I find there are things that I can learn, and in this particular case it was their approach to incident management that made me stop and think. It’s quite an unusual approach, with some far-reaching implications, and I think that many organizations could benefit from adopting it.

What is an incident?

ITIL, the world’s most popular framework for IT service management, defines an incident as

“An unplanned interruption to an IT service or reduction in the quality of an IT service…”

This is a very IT-centric definition. The ITIL publication does talk about the importance of minimizing the impact on the customer’s business, but the incident itself is clearly something to do with IT.  What’s promoted, however unconsciously, is a tendency to think about IT, rather than about customers, when we are managing incidents. 

My recent client defines incidents differently. For them, an incident is

“A deviation in business processes resulting in undesired business outcome…”

This is a very different way of thinking, and it results in a very different, and, in my view, potentially a much more effective mindset for the people working on incidents.

Who can be assigned actions to help resolve an incident?

In a typical incident management process, the focus is on the disrupted IT. Actions are assigned to people in IT, who are responsible for resolving the incident. If they need the customer to do something, these actions are often not seen as part of the incident management process, and IT may have little influence over, or responsibility for, how and when they happen. In the worst case, the IT organization “stops the clock” and doesn’t count any time waiting for customer actions towards their incident management target.

If, however, we think of an incident as a deviation in a business process, then it is very clear that anyone impacted by the deviation may need to contribute to resolving the incident. Where the incident is caused by an interruption to an IT service, then people in IT teams will have actions to take, but they will not be the only people focussed on the incident; and incident management work will not stop whilst IT waits for actions from people outside of IT. Instead the incident will continue to be managed actively, with many actions being taken by different people until the incident has been resolved. This is why an apparently small change in definition can result in a highly significant change in attitudes, behaviour, culture and outcomes.

Suppose that someone in sales enters the wrong data, and this results in external customers being incorrectly sent letters saying that they owe the company money. According to my customer’s definition this is clearly an incident, and should be logged with the service desk. Actions to resolve this incident will include correcting the data (which may need IT people to manipulate the underlying database); it will also require communication with the impacted customers to put things right, actions that will be carried out by sales or marketing people.  But everything, regardless of who takes the action and why, will be logged, tracked and managed using the service management tool and process, and this should result in a recovery processes that is intrinsically seamless and coherent.

When do you close an incident?

When an IT failure causes a business deviation, IT people tend to think that the incident should be closed as soon as they have fixed the IT components. But there may well be considerable business disruption after the IT is working again, and there will often be a range of activities needed to bring the business back to a normal state.

ITIL suggests that an incident should remain in a “resolved” state, until the customer agrees that it can be closed. In practice, many IT organizations automatically close incidents if the customer doesn’t get back to them within pre-defined times.

For an organisation following this business centred definition of an incident it becomes very clear that an incident should be closed AFTER all business deviation has been rectified. This means that all required actions have been completed and everything is now back to normal.

What incident reports do you produce?

Typical incident management reporting focusses on how quickly the IT organization resolves incidents. While this can be useful in helping to plan and manage IT improvements, and to show that SLA commitments have been met, it has very little business value.

When you redefine incidents in a more business focussed way, you are much more likely to produce reports that are valuable to the business. How much disruption has there been to business processes? What were the most common causes of disruption? (Often this won’t have been IT failures).  Where were the biggest delays incurred? This data can help to plan and manage improvements to how the business is managed, as well as how well IT supports the business.

Conclusion

Do you have an IT service desk that works really hard to resolve IT incidents? Maybe it’s time you thought about how you could create even more value for your organization by expanding the definition of an incident to include any deviation in a business process, regardless of the cause. That might help IT become better integrated into your overall organization, being seen as a real partner rather than as a back-room function that fixes the technology when it breaks.

 

Image Credit: miningcamper

This work is licensed under CC BY-SA 4.0