Root cause analysis is not a single technique. It is a family of structured approaches to the same problem: moving from observed symptoms to underlying causes so that interventions fix the problem, not just its manifestation.
Different techniques work better in different contexts. Knowing which tool to use — and when — is as important as knowing how to use any of them.
The five whys
The five whys is the simplest and most widely used root cause technique. Start with a problem statement, ask why it is happening, take the answer as the new problem, and ask why again. Repeat until you reach a cause that is structural and addressable rather than symptomatic.
An example: customer complaints about incorrect invoices are increasing.
- Why are invoices incorrect? Because the sales team is entering order details manually.
- Why are they entering manually? Because the CRM does not export to the billing system.
- Why not? Because the integration was never built when the billing system was changed two years ago.
- Why not then? Because the migration budget did not include integration work.
- Why not? Because the project scope was defined without input from the sales team.
The root cause is a process problem in how project scope is defined — not an invoice problem, not a CRM problem, and not a sales team competence problem.
The five whys works best for problems with a single causal chain. It is less effective when multiple independent causes contribute to the same symptom.
Fishbone diagrams (Ishikawa diagrams)
The fishbone diagram is useful when a problem likely has multiple contributing causes from different categories. The main categories commonly used are: people, process, equipment/tools, materials/inputs, environment, and measurement.
For each category, the team identifies potential causes. This produces a structured brainstorm that prevents fixating on any single cause before exploring the full range.
The fishbone is a starting point, not a conclusion. It generates hypotheses to test, not verified causes. Each potential cause identified in the diagram needs to be evaluated against data to determine whether it actually contributes to the problem.
Pareto analysis
The Pareto principle — 80% of effects come from 20% of causes — applies reliably to operational problems. In most processes, a small number of failure modes account for the majority of defects, delays, or customer complaints.
Pareto analysis involves categorizing all instances of the problem by type, counting the frequency of each type, and ranking them. The most frequent category is the first priority for root cause investigation. Fix the top category, and you eliminate the majority of the problem.
This matters because it prevents equal-effort distribution across unequal causes. Without Pareto analysis, teams often work on all categories simultaneously, or fix the ones that are easiest rather than the ones that are most impactful.
Process capability analysis
For processes that produce measurable outputs — cycle times, error rates, defect rates — statistical process capability analysis reveals whether the process is inherently capable of performing within the required range, or whether the variation is too large.
A process that is running at the edge of or outside its capability limits will produce defects even when everything is "working correctly." No amount of exhortation or incremental adjustment will fix a process that is structurally incapable. The process itself must be redesigned.
This analysis requires data — a sufficient number of process output measurements to establish the distribution. Once you have it, it tells you whether you are dealing with a process design problem or an execution problem, which are very different to fix.
Failure mode and effects analysis (FMEA)
FMEA is a proactive technique — used before a problem occurs to identify where failures are most likely, what their effects would be, and how to prevent them.
For each step in a process, identify: what could go wrong, what the effect would be if it did, how severe that effect would be, how likely the failure is, and how detectable the failure would be before it affects the output. Multiply severity, likelihood, and detectability to produce a risk priority number. The highest priority numbers indicate where prevention resources should be focused.
FMEA is most valuable when designing a new process, when significantly modifying an existing process, or when a process has experienced repeated failures that have not been resolved by other approaches.
Choosing the right tool
For a single-threaded problem with a clear symptom, start with five whys. For a problem with multiple possible causes across different categories, use a fishbone. For a problem with multiple instances that vary in type and frequency, start with Pareto. For a process that produces measurable output and needs statistical evaluation, use process capability analysis. For designing new processes or preventing future failures, use FMEA.
The common failure is starting with a solution before applying any diagnostic tool. The diagnosis determines the solution. Skipping the diagnosis produces solutions that do not address the cause.