Root cause analysis

What is root cause analysis?

Root cause analysis is the practice of finding the underlying reason a problem happened, rather than treating the symptom you can see. The American Society for Quality describes it as the collective set of approaches and tools used to uncover the causes of problems, and defines a root cause as a factor that should be permanently removed through process improvement.

The idea is simple to state and hard to do well. A late delivery, a rejected invoice, or a spike in errors is the symptom. The root cause is whatever keeps producing it, and fixing only the symptom means it comes back.

Common methods: 5 Whys and the fishbone diagram

The 5 Whys works by asking "why?" of each answer, roughly five times, until you reach a cause you can act on. It suits problems with a fairly linear chain, where one thing led to the next.

The fishbone diagram, also called the Ishikawa or cause-and-effect diagram, is better when several possible causes need to be weighed at once. You write the problem as the fish head and branch out categories of causes, often people, process, materials, machines, measurement, and environment, then fill in candidates under each. Both are structured ways to slow down and stop guessing.

Root cause analysis in data and process work

In a data and process setting, root cause analysis pairs naturally with process mining. An event log of what actually happened, step by step, lets you see where cases slow down, loop back, or deviate. Bottleneck analysis points at the step where work piles up, and variant analysis shows which paths through the process behave differently from the rest.

On the systems side, it overlaps with data observability and anomaly detection. A monitoring tool can flag that a table arrived late or that a number jumped, but the alert is the symptom. Root cause analysis is the work of tracing that alert back to the pipeline, the source change, or the code that caused it.

A warning runs through all of this: a statistical link is not proof of cause. Two things moving together can share a hidden third factor. Root cause analysis combines the data with real knowledge of the process, stated hypotheses, and where possible a test, rather than trusting correlation on its own.

A worked example

Process mining shows that invoices without a purchase order wait longer on average. It is tempting to name the missing purchase order as the root cause and stop there.

Segmenting further shows those invoices tend to come from new suppliers and for non-standard services, and they go through legal review more often. Several factors travel together. The team writes three hypotheses: the missing purchase order adds matching work, new suppliers need a master-data check, and legal review creates a separate queue. Each is then tested against the event sequence, the case attributes, and interviews. A trial where suppliers get a purchase-order reference earlier can measure whether matching time really drops. The honest answer may be several causes at once, not one tidy root.

What to watch out for with root cause analysis

Watch for confounders. A factor that influences both the suspected cause and the outcome can fool you. Complex cases may carry both more checks and a longer wait, so the checks alone are not necessarily the cause.

Say how strong the evidence is. Present a finding as a correlation, a plausible explanation, or a demonstrated causal effect, according to what you actually showed. Dressing up a weak link as a proven cause leads to fixes that do nothing.

Match the fix to the cause. Choose an action that hits the cause you believe you found. For missing purchase orders that might be validation at the source; sending more reminders to approvers treats a different symptom entirely.

Measure again after you act. If the delay does not fall, the hypothesis was incomplete, the fix was too weak, or it was carried out differently than planned. Keep the hypotheses, analyses, and results, because root cause analysis is a learning loop where explanations are allowed to be wrong.