Root Cause Analysis: 5 Whys, Fishbone (Ishikawa) Diagram, and Fault Tree Analysis

The 5 Whys method

The 5 Whys is an iterative questioning technique developed by Sakichi Toyoda and made famous through its use in the Toyota Production System. The method works by taking a problem statement and asking “why did this occur?” then asking “why?” again about each successive answer until the underlying root cause is reached. The number five is a guideline, not a rule: some problems have root causes at the third why, others at the seventh.

The method is best illustrated by example. A stamping press produces parts with a dimensional defect:

Why 1: Why are the parts out of tolerance? Because the die is worn.

Why 2: Why is the die worn? Because it ran beyond its scheduled replacement interval.

Why 3: Why did it run beyond its replacement interval? Because the maintenance schedule was not updated when production volume increased.

Why 4: Why was the maintenance schedule not updated? Because there is no process to review maintenance intervals when production parameters change.

Why 5: Why is there no such process? Because the maintenance and production planning functions have no formal communication protocol for parameter changes.

The root cause is not a worn die (which is a symptom) or even a missed maintenance event (which is a proximate cause): it is an organizational gap in how production changes are communicated to maintenance. The corrective action at this level creates a durable fix; replacing the die without addressing the communication gap will produce the same failure again.

Effective 5 Whys analysis requires discipline. The most common failure mode is stopping at the proximate cause (Why 2 or Why 3) and implementing a corrective action at that level. A second failure mode is branching: at some why levels, there may be multiple contributing causes, each of which deserves its own chain of whys. A fishbone diagram is often used alongside the 5 Whys to capture branching causal chains.

Fishbone (Ishikawa) diagram

The fishbone diagram, developed by Kaoru Ishikawa in the 1960s, is a visual tool for organizing the potential causes of a problem into categories. The diagram takes its name from its shape: the problem statement (the effect) sits at the head of the fish, and the major cause categories branch off the spine like bones. Potential specific causes are added as smaller branches off each category bone.

The standard cause categories in manufacturing contexts follow the 6M framework:

• Man (People): operator skill, training, fatigue, procedure adherence, human error.
• Machine: equipment condition, tooling, calibration, maintenance state, capacity.
• Material: incoming material properties, supplier variation, lot-to-lot variation, storage conditions.
• Method: work instructions, process parameters, measurement methods, setup procedures.
• Measurement: gauge capability, calibration, measurement technique, data collection accuracy.
• Mother Nature (Environment): temperature, humidity, vibration, cleanliness, lighting.

The fishbone diagram is used in the Analyze phase of DMAIC and in the early stages of 8D problem solving to generate a comprehensive list of potential causes before data-driven investigation narrows the list to verified root causes. The diagram itself does not identify the root cause; it organizes hypotheses for testing. After the diagram is complete, each branch is evaluated against available data to determine which potential causes are actually contributing to the problem.

Fault tree analysis

Fault tree analysis (FTA) is a top-down, deductive analytical method that models the logical relationships between a top-level undesired event (the top event) and the lower-level events (basic events) that can cause it. FTA was developed by Bell Telephone Laboratories in the 1960s for the US Air Force Minuteman missile program and is now widely used in aerospace, nuclear, automotive (FMEDA), and process industries.

An FTA begins with defining the top event precisely: “hydraulic system pressure loss,” “control software lock-up,” or “product contamination exceeding 10 ppm.” The analyst then works downward, asking what combinations of events can directly cause the top event. These intermediate events are in turn decomposed into their own contributing events, until all branches reach basic events that cannot be decomposed further (equipment failures, human errors, external events).

The logical relationships between events are represented by gates:

• AND gate: the output event occurs only when all input events occur simultaneously. AND gates represent redundant systems where multiple failures are required to produce the top event.
• OR gate: the output event occurs when any one of the input events occurs. OR gates represent parallel failure paths where any single failure is sufficient.

When failure probabilities are assigned to basic events, the FTA becomes quantitative. The probability of the top event is calculated using Boolean algebra:

P(AND gate output) = P(A) × P(B) × P(C) [for independent events]

P(OR gate output) = 1 − (1 − P(A)) × (1 − P(B)) × (1 − P(C))

The minimal cut sets of the fault tree are the smallest combinations of basic events whose simultaneous occurrence causes the top event. Minimal cut sets with only one basic event (single-point failures) are the most critical: any single failure causes the top event with no redundancy protection. Minimal cut sets with two basic events require two simultaneous failures and are more tolerant, and so on. Design improvements that eliminate single-point failures or reduce the probability of critical minimal cut sets have the greatest impact on system reliability.

Selecting and combining RCA tools

The three tools address different problem types and different stages of investigation. For a single, well-defined defect with a clear causal chain, 5 Whys is the fastest and most practical tool. For a recurring problem with multiple suspected causes across people, machines, materials, and methods, the fishbone diagram provides the structure to capture and organize all hypotheses before investigating. For a complex system failure where multiple components can fail in combination and quantitative probability targets must be met, FTA provides the rigor and mathematical framework that simpler tools cannot.

In quality management practice, these tools are often combined. A fishbone diagram is used first to map the problem space and generate hypotheses. Confirmed contributing causes are then analyzed with 5 Whys to find the systemic root cause within each category. For high-severity failures involving system safety or regulatory compliance, FTA is used to model all failure paths and verify that corrective actions reduce the top event probability to an acceptable level.

Common errors in root cause analysis

• Stopping at the proximate cause. A worn tool, a broken sensor, a misconfigured parameter are proximate causes. The root cause is the management system failure that allowed the proximate cause to occur: inadequate preventive maintenance, insufficient calibration frequency, no change control process. Corrective actions at the proximate cause level produce temporary fixes; corrective actions at the root cause level prevent recurrence.
• Confusing correlation with causation. In fishbone diagram brainstorming, potential causes are hypotheses. Confirming a cause requires data: statistical analysis, designed experiments, or controlled process trials that show the cause-and-effect relationship is real, not coincidental. Implementing corrective actions against unconfirmed causes wastes resources and may not address the actual problem.
• 5 Whys chains that terminate at a person. “The operator made an error” is not a root cause; it is a symptom of a deficient system. The 5 Whys chain should continue through the error to the system condition (inadequate training, unclear procedure, workstation design that makes errors likely) that allowed the error to occur.
• Using FTA for simple problems. FTA is a powerful tool that requires significant time and expertise to apply correctly. Using it for problems that can be resolved with a 5 Whys analysis wastes resources without adding analytical value. Match the tool complexity to the problem complexity.

Frequently asked questions

How do you know when you have reached the root cause in a 5 Whys analysis?

A root cause is reached when two conditions are met. First, the answer to the current “why” is a controllable system condition: a missing procedure, an inadequate standard, a communication gap, an untrained operator, an unmonitored process parameter. Second, a corrective action at this level would prevent not just this incident but the entire class of incidents caused by the same systemic gap. A practical test is the “therefore” check: work back up the chain using “therefore” instead of “why” to verify that the logical chain holds from root cause to symptom. If any link in the chain does not hold, the root cause identification is wrong or incomplete. Another indicator that the root cause has not been reached is when the answer points to another person or group (“because the maintenance team didn’t do their job”): this is a symptom of a system failure, not the root cause itself. The analysis should continue to identify what system condition allowed the maintenance team to miss the task: no alert system, no accountability mechanism, no standard work for the activity.

What are the six categories in a fishbone diagram and when should additional categories be used?

The six standard categories in the 6M fishbone framework for manufacturing are: Man (People), Machine, Material, Method, Measurement, and Mother Nature (Environment). These six categories were designed to cover the major sources of variation in manufacturing processes and are appropriate for most production quality problems. Additional categories can be added when the standard six do not cover all relevant sources of variation for a specific problem type. In service industry applications, the 8P framework (Product, Price, Place, Promotion, People, Process, Physical Evidence, Productivity) is sometimes used instead. In software quality, categories might include Code, Architecture, Testing, Requirements, and Environment. The rule for adding categories is that every major source of variation relevant to the specific problem should have its own branch, and every potential cause should fit clearly into exactly one category. If a cause fits multiple categories, the category definitions need to be clarified or the cause needs to be decomposed into more specific sub-causes.

What is a minimal cut set in fault tree analysis and why does it matter?

A minimal cut set is the smallest combination of basic events (component failures, human errors, external events) whose simultaneous occurrence is both necessary and sufficient to cause the top event (the system failure being analyzed). “Minimal” means that removing any one event from the set would prevent the top event from occurring through that combination. A fault tree with three basic events A, B, and C and a top event that occurs when (A AND B) OR C occurs has two minimal cut sets: {A,B} and {C}. The minimal cut set {C} contains only one event, meaning C alone can cause the top event: this is a single-point failure, the most critical type in reliability engineering. Minimal cut sets matter because they identify which combinations of failures are most critical to system safety: single-element cut sets are the highest priority for design improvement (adding redundancy or reducing failure probability), two-element cut sets are the next priority, and so on. In automotive functional safety (ISO 26262) and aerospace (MIL-STD-1629A), identifying and eliminating single-point failures for safety-critical functions is a design requirement, not an option.

How is root cause analysis used in the CAPA process?

Root cause analysis is the analytical core of the corrective action and preventive action (CAPA) process. In a CAPA workflow, a nonconformance or customer complaint triggers an investigation that has three required outputs: a verified root cause, corrective actions that address the root cause, and evidence that the corrective actions were effective. The RCA tools are used in the investigation phase: 5 Whys for straightforward single-cause problems, fishbone diagram for problems with multiple potential contributing causes, and FTA for high-severity failures in complex systems. The root cause must be verified, not assumed: the investigation must show data or evidence that the identified root cause was actually present and actually contributed to the failure, not just that it is a plausible explanation. Corrective actions are then designed to address the verified root cause (not just the symptom) and are implemented with a defined timeline and responsible owner. Effectiveness verification is the final step: a defined metric is measured after implementation to confirm that the root cause has been eliminated and the problem has not recurred. In regulated industries (FDA, ISO 13485, IATF 16949), the CAPA record including the RCA documentation is subject to audit and must demonstrate that the investigation was thorough and the root cause was genuinely addressed.

What is the difference between a root cause and a contributing factor?

A root cause is the fundamental systemic condition that, if corrected, would prevent the problem from recurring. A contributing factor is a condition that increased the likelihood or severity of the problem but is not sufficient by itself to cause it. The distinction matters for corrective action prioritization: addressing only contributing factors without addressing the root cause produces an incomplete fix that leaves the problem vulnerable to recurrence. For example, in an investigation of a product contamination event: the root cause might be an inadequate cleaning validation that did not establish sufficient rinse cycle parameters; contributing factors might include an operator who skipped a step in the cleaning procedure and a supervisor who did not verify the cleaning log. Addressing the contributing factors (retraining the operator, adding a supervisor verification step) reduces the risk from those specific failure modes. Addressing the root cause (revising the cleaning validation to establish and control the critical rinse parameters) addresses the systemic gap that made the procedure inadequate regardless of operator behavior. In practice, a thorough CAPA addresses both the root cause and the significant contributing factors, with the root cause correction being the highest-priority action.

When should fault tree analysis be used instead of simpler RCA tools?

Fault tree analysis should be used when three or more of the following conditions apply: the system has multiple redundant or interacting failure modes that can combine in complex ways to produce the top event; a quantitative probability target for the top event must be demonstrated (such as a safety integrity level requirement or a regulatory limit on failure rate); the consequences of the failure are severe (safety-critical, life-critical, or regulatory-critical); the system is new and the failure modes have not been characterized by operational experience; or a previous simpler RCA investigation produced a fix that did not prevent recurrence, suggesting that the causal structure is more complex than initially understood. FTA is not appropriate for simple, well-understood problems where the causal chain is linear and the root cause can be identified by direct investigation or 5 Whys. The investment required for a rigorous FTA (defining the system boundary, building the tree, identifying all basic events, assigning failure rates, calculating minimal cut sets) is only justified when the complexity of the problem and the severity of the consequences warrant it. In automotive functional safety (ISO 26262 ASIL D), aerospace (DO-178C), and nuclear power, FTA at the system level is typically a regulatory requirement rather than an optional tool.