Root Cause Analysis
Root cause analysis investigates the contributing causes of a problem and the conditions that allowed it to recur. It combines evidence with causal reasoning to identify and assess corrective actions.
THE IDEA
Root cause analysis (RCA) investigates why a problem occurred and which changes could reduce recurrence. Repeatedly asking why can reveal a chain of contributing conditions, but a plausible chain still needs evidence and may leave out other causes.
Use records, observations, and interviews to test explanations. Cause-and-effect diagrams, including fishbone diagrams, can help organize possibilities involving equipment, human actions, working conditions, and organizational decisions. They organize an investigation; they do not establish the causes by themselves.
Consider how factors interact before choosing corrective actions. Assign responsibility for the changes and review whether they reduce the problem. An investigation need not claim to have found every cause to support a useful, evidence-based improvement.
When to use it
Investigating a recurring customer complaint to prevent future occurrences.
Analyzing a safety incident in a factory to identify underlying process weaknesses.
Debugging a complex software issue where symptoms are misleading.
Improving a business process that frequently fails to meet quality targets.
FROM THEORY TO EVERYDAY LIFE
In practice
Manufacturing Defect
A factory repeatedly produces defective parts. Using root cause analysis, engineers trace the issue through multiple 'whys': the machine malfunctions because a sensor fails, the sensor fails due to dust accumulation, dust accumulates because filters are not cleaned, filters are not cleaned because the maintenance schedule was changed to cut costs. Beyond the initial chain, they discover that the cost-cutting decision was made without consulting maintenance staff, revealing a communication breakdown.
Software Bug
An e-commerce website fails to process payments intermittently. The development team asks 'why' and finds a database timeout. The timeout occurs because queries are slow. The queries are slow because indexes are missing. Indexes were omitted by a developer who was pressed for time. The root cause extends beyond the individual developer to the project's deadline pressure and lack of code review.
A MOMENT TO REFLECT
Put it to work.
What are the limitations of stopping at the first 'why'? How might jumping to conclusions affect the analysis?
How can you ensure you are identifying a root cause rather than a proximate cause?
What systemic factors (e.g., culture, incentives, processes) might be overlooked in a simple root cause analysis?
CONTINUE THE CONVERSATION
Source texts
- Beyond the Five Whys Root Cause Analysis and Systems Thinking (James C. Paterson)