Knowing when to start, and when to stop, root-cause analysis is essential to success.

When to do Root-Cause Analysis

One of the most challenging and misunderstood considerations is when to perform root-cause analysis. Secondarily, it’s also important to understand when to stop root-cause analysis. Largely, there are organizational factors that will guide this decision but we can provide some suggestions that may help.

We should start by providing some key definitions for the sake of clarity. If you have taken an ITIL course, you’ll likely be at least vaguely familiar with this terminology although we will color the definitions slightly to fit more precisely with our root-cause analysis system.

  • Incident – interruption to a service; failure of a component, element, unit, or system.
  • Problem – the cause of an incident.
  • Underlying Cause – the cause of another cause.
  • Root-Cause Analysis – the ongoing pursuit of causes and underlying causes through analysis in order to determine actionable steps to improve elements, units, systems, services, and organizations.

Factors that indicate we should start root-cause analysis

ITIL would lead us to believe that root-cause analysis is the domain of Problem Management. This is a valid approach in many organizations, however, in root-cause analysis you will certainly depart from technical to organizational factors. While problem management will likely play a role, effective root-cause analysis requires stakeholders who are empowered to examine, review, approve and implement broad-based actions.

Here’s a list of factors that could trigger root-cause analysis. This list is not exhaustive.

  • A major incident has occurred.
  • A project, plan, or strategy has failed (to produce intended results).
  • A recurring incident was addressed through Problem Management, was closed, and has since recurred.
  • A corrective action taken to address an incident or a problem has led to unintended effects on elements, units, systems, services or the organization.
  • There is no viable solution for an on-going problem or incident.
  • Undefined negative performance trends are observed.
  • Targets are missed or exceeded without explanation.
  • Patterns are discerned, but not understood.
  • A strong, common-sense judgement exists that there are underlying concerns.
  • Problem management has become ineffective in dealing with a cause.

When to stop root-cause analysis

Whatever triggers your organization to start root-cause analysis, you must establish some clear exit criteria. I mention this because root-cause analysis can take you to deeper causes that are less concrete, often abstract, and can be difficult to address effectively. We cover entry and exit criteria in detail in our root-cause analysis courses. Determining this exit criteria up-front is critical to the success of root-cause analysis.

Avoid the temptation of saying, “we stop root-cause analysis when we find the root cause.” Good analysis will often review multiple layers of underlying causes, each with some catalysts (we’ll call them contributing factors), and often with multiple causal factors. Truly, you can end up with a tree of causes, some necessitating action and others that you must generally accept.

Good root-cause analysis should have clearly defined entry and exit criteria. To learn more about root-cause analysis, contact us and find out how we can help establish this domain in your organization.

Share this post

Share on facebook
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email