Anatomy of Unsuccessful Incident Management

A common question when a company is implementing incident management is: why do we need this process?

It turns out that the easiest way to answer this question is to look at the world of unsuccessful incident management.

Attributes of Unsuccessful Incident Management

As we can see above, without a defined process or tool, incidents can quicklybecome unweildy.  Worse, they can fail to be noticed by those who need to know about them and cause churn throughout the organization as separate comms channels work in parallel to duplicate content.

Unsuccessful incident management is characterized by:

Confusion about Process

The first person to identify the incident is weighted with the responsibility to decide how to communicate it. Which channel to use, who to include, how to define the serverity, and what types of information are relevant.

Panic and Thrash

Because of the confusion of the initial reporter, those who are contacted high up in the chain of command often overreact and start contacting their peers, who start contacting their teams for more information.

Lack of Awareness

Members of teams affected by the incident who are outside of the originating organization remain unaware of the incident, causing more thrash and duplicative task filings and comms channels

Blame

WIthin the panic and thrash, assignment of blame can become a higher priority than resolution and mitigation, forcing responders to spend time explaining themselves rather than fixing the root cause of the problem.

Uncoordinated & Conflicting Response

Responders from multiple organizations who find themselves on different comms channels can take conflicting actions that affect each other, such as a server restart or configuration change that affects other responders negatively and slows resolution time.

Confusion over Ownership

Owners are not explicit and drop their implicit roles without warning such that work on the problem may stop unexpectedly when one or more responders don't realize that they are the primary owner. This can especially happen at shift changes or during work hour transitions such as end-of-day.

Repeat Problems

Without a postmortem process the organization may not actually learn about the underlying systemic causes of the incident, causing it to repeat again in the future.

Don't let this be you!

Read more from our academy and try out Kintaba to help you implement modren collaborative incident management quickly and easily across your organization.