Root Cause Analysis (RCA) is a systematic approach to investigating defects, equipment failures, accidents, operational problems, and other undesirable events. Rather than focusing only on visible symptoms or immediate causes, RCA examines the underlying conditions and mechanisms that contribute to a problem and identifies ways to prevent its recurrence.
For example, suppose defective products are discovered during manufacturing. Removing the defective items and replacing them with acceptable products may resolve the immediate situation. However, unless the conditions that caused the defects are addressed, the same problem may occur again.
Similarly, if an error is attributed to an operator’s mistake, further questions remain. Why did the operator make the mistake? Were the equipment and operating procedures appropriate? Were mechanisms available to prevent or detect the error?
RCA investigates such questions by combining different analytical techniques, including 5 Whys, Cause-and-Effect Diagrams, logical failure analysis, process investigation, and statistical methods.
However, the term root cause can create the misleading impression that every problem has one ultimate cause. In reality, many problems arise from multiple factors interacting under particular conditions.
The purpose of RCA is not simply to explain what went wrong. It is to identify which conditions or mechanisms should be changed to reduce the likelihood of recurrence.
What Is a Root Cause?
A root cause generally refers to an underlying factor that contributes to a problem and whose correction may help prevent the same problem from occurring again.
Consider a manufacturing machine that overheats and shuts down.
The immediate reason for the shutdown may be that the temperature exceeded a safety threshold, triggering a protective mechanism.
Further investigation reveals that coolant flow was insufficient.
Additional examination shows that a filter in the cooling system was clogged.
At this point, cleaning the filter may allow the machine to resume normal operation.
However, the investigation has not yet explained why the filter blockage was not detected before the machine overheated.
Perhaps the preventive maintenance schedule did not include filter inspection. Alternatively, the equipment may have lacked sensors capable of detecting reduced coolant flow.
Investigating these conditions suggests improvements that go beyond cleaning the filter, such as revising maintenance procedures or installing monitoring mechanisms.
Problems can therefore be examined at different levels.
| Level | Example | Typical Response |
|---|---|---|
| Observed event | The machine overheated and shut down | Ensure safety, stop operation, restore functionality |
| Immediate cause | Insufficient coolant flow | Restore coolant flow |
| Underlying cause | Clogged filter | Clean or replace the filter and address blockage |
| Management or design factors | Missing inspection requirements or inadequate monitoring | Improve maintenance plans or equipment design |
However, there is no universally applicable rule for determining exactly how far an investigation must proceed before a factor can be called a root cause.
The analysis could continue to examine maintenance budgets, equipment purchasing decisions, organizational responsibilities, and management policies.
In practice, RCA should not continue indefinitely. The depth of investigation must be determined by considering the seriousness of the problem, available evidence, and the feasibility and effectiveness of corrective actions.
Must There Be Only One Root Cause?
The expression root cause can suggest that a problem has a single underlying explanation.
However, complex accidents and defects often result from combinations of multiple factors.
Suppose an incorrect component is installed on a manufacturing line under the following circumstances:
- Components A and B have very similar appearances.
- Labels on component storage containers are difficult to distinguish.
- The barcode scanner used for identification is not functioning.
- Production can continue even when the scanner is unavailable.
- The final inspection does not verify component identification numbers.
In this situation, the operator’s selection of the wrong component is an immediate event, but it does not adequately explain the entire failure.
Difficult-to-distinguish components, unavailable identification equipment, inadequate operating controls, and insufficient final inspection may have combined to allow the defective product to be shipped.
It is also useful to distinguish the factors that caused the incorrect component to be installed from those that allowed the defect to escape detection.
The former concern the occurrence of the defect.
The latter concern the failure of mechanisms intended to detect or prevent defective products from reaching customers.
Rather than assigning the entire problem to a single person or process, RCA should examine both the conditions that allowed the problem to occur and the conditions that failed to prevent its consequences.
In safety engineering, accidents are sometimes understood as resulting from weaknesses in multiple layers of protection.
The well-known Swiss Cheese Model illustrates how vulnerabilities in different defensive layers may align and allow an accident to occur.
RCA should therefore consider combinations of contributing factors and their interactions, rather than assuming that every problem follows a single linear chain of causes.
How Does RCA Differ from 5 Whys and Cause-and-Effect Diagrams?
RCA is not simply a particular diagramming technique. It encompasses activities ranging from cause investigation to the development and evaluation of preventive measures.
5 Whys and Cause-and-Effect Diagrams are techniques that can be used within RCA.
| Method | Main Purpose | Role in RCA |
|---|---|---|
| 5 Whys | Repeatedly investigate why a problem occurred | Explore chains of possible causes |
| Cause-and-Effect Diagram | Organize potential causes into categories | Generate and classify cause candidates |
| Pareto Chart | Compare the frequency or impact of different problems | Prioritize investigation targets |
| Change Analysis | Examine differences between normal and abnormal conditions | Identify changes associated with an event |
| Barrier Analysis | Examine the performance of preventive and protective measures | Investigate why existing safeguards failed |
| Fault Tree Analysis (FTA) | Analyze logical combinations of events leading to failure | Examine relationships among multiple causal conditions |
| Statistical Analysis and Design of Experiments | Quantitatively evaluate relationships between factors and outcomes | Test or evaluate causal hypotheses |
These methods serve different purposes and should be selected according to the nature of the problem.
For relatively simple problems, 5 Whys combined with examination of operational records may be sufficient.
For serious safety incidents or failures involving multiple equipment systems and organizational processes, detailed timelines, technical investigations, and analysis of multiple contributing factors may be necessary.
Not every RCA requires every available technique.
How to Conduct Root Cause Analysis
RCA can be organized in different ways depending on the industry, the problem, and the analytical methods being used.
Nevertheless, a typical investigation includes defining the problem, collecting evidence, developing causal hypotheses, evaluating those hypotheses, implementing corrective measures, and confirming their effectiveness.
1. Define the Problem Clearly
The first step is to identify what actually happened.
A statement such as “Manufacturing quality is poor” does not sufficiently define the problem.
A more useful description might be:
“Twelve cases of incorrect component assembly occurred during the past month in the assembly process for Product X.”
This statement specifies the event, affected product, process, and period.
At this stage, it is important to avoid incorporating an assumed cause into the problem definition.
For example, defining the problem as “Incorrect assembly caused by operator carelessness” introduces a causal conclusion before the investigation has established it.
A problem statement should distinguish observed facts from interpretations of those facts.
2. Collect Evidence About the Event
The next step is to investigate the circumstances surrounding the problem.
In manufacturing, relevant evidence may include operating records, equipment logs, measurements, production conditions, maintenance histories, physical specimens, and interviews with operators.
For an accident, the investigation may need to examine events before and after the incident, operating procedures, safety devices, and the actions of people involved.
The important principle is to collect evidence without prematurely deciding on the explanation.
If different participants provide conflicting accounts, investigators should compare those accounts with available records and observations rather than immediately assuming that one person is mistaken.
Because physical conditions may change after an incident, relevant evidence should be preserved appropriately, with safety taking priority.
3. Reconstruct the Sequence of Events
The investigation should establish when and how the problem developed.
For example, equipment records might show the following sequence:
Normal Operation → Reduced Coolant Flow → Temperature Increase → Alarm Activation → Equipment Shutdown
A timeline helps clarify how the event progressed.
However, temporal sequence alone does not establish causation.
The investigation must still consider why coolant flow decreased, whether the temperature increase was caused by that decrease, and why the equipment could not be stopped earlier.
A sequence of events provides a framework for causal investigation, not a complete causal explanation.
4. Generate a Range of Possible Causes
Investigators next identify possible explanations for the observed problem.
5 Whys can help explore chains of potential causes, while Cause-and-Effect Diagrams can organize candidates involving equipment, materials, methods, environmental conditions, and other factors.
At this stage, investigators should avoid becoming committed to the first plausible explanation.
For example, a machine shutdown might involve cooling system problems, excessive mechanical load, sensor malfunction, or software control failures.
Generating possible causes is not the same as establishing that those causes actually occurred.
5. Evaluate and Test Causal Hypotheses
Each candidate cause should be examined against available evidence.
For example, if insufficient coolant flow is proposed as the cause of overheating, investigators should determine whether coolant flow actually decreased during the incident.
Comparisons with normally functioning equipment under similar operating conditions may also be useful.
Additional measurements, component examinations, simulations, or experiments may be necessary.
However, when safety is involved, investigators should not deliberately reproduce a dangerous failure merely to confirm a hypothesis. Alternative tests, simulations, or engineering assessments may be more appropriate.
It is also important to examine evidence that contradicts a hypothesis, as well as evidence that supports it.
Competing explanations should be considered whenever they remain plausible.
6. Develop and Implement Preventive Measures
Once relevant causes and contributing conditions have been identified, corrective measures can be developed.
For example, if a clogged filter contributed to overheating, possible measures include scheduled replacement, monitoring of pressure differences or coolant flow, and changes to equipment design.
The objective should not be limited to providing instructions for responding after the problem occurs.
Whenever possible, the system should be changed so that the same conditions are less likely to result in another serious event.
Each corrective action should have defined responsibilities, implementation requirements, deadlines, and criteria for evaluating effectiveness.
7. Verify the Effectiveness of Corrective Actions
After implementing corrective measures, investigators should evaluate whether the frequency or consequences of the problem have actually decreased.
For example, even if the defect rate falls, the improvement cannot necessarily be attributed to the corrective action if production volume or operating conditions have changed substantially.
Similarly, an absence of repeated incidents does not always demonstrate that preventive measures are effective.
For rare accidents or equipment failures, a short period without recurrence provides limited evidence.
It may therefore be useful to evaluate not only final outcomes, such as accident or defect rates, but also indicators showing whether the preventive mechanisms are functioning properly.
Examples include the operational status of monitoring devices, completion of required inspections, and verification of safety mechanisms.
RCA should not be considered complete merely because a report identifying causes has been written. It should include the implementation of corrective actions and an appropriate evaluation of their effectiveness.
Practical Example — A Product Shipped with the Wrong Component
The following hypothetical example illustrates how RCA can be applied.
A manufacturing plant discovers that a product containing an incorrect component has been shipped to a customer.
The investigation establishes the following facts.
| Confirmed Fact | Description |
|---|---|
| Event | Component B was installed in a product requiring Component A |
| Component characteristics | Components A and B have very similar shapes and dimensions |
| Normal identification method | A barcode is scanned before assembly |
| Equipment condition | The barcode scanner was malfunctioning |
| Operating procedure during failure | Production continued using visual identification |
| Final inspection | Component identification numbers were not verified |
Organizing the Causes
The statement “The operator selected the wrong component” describes an immediate event.
However, it is insufficient as an explanation for developing effective preventive measures.
First, Components A and B were difficult to distinguish.
Second, the barcode identification mechanism normally used to prevent incorrect assembly was unavailable because of equipment failure.
Third, production could continue without barcode verification.
Finally, the final inspection did not include a check capable of detecting the incorrect component.
The investigation should distinguish between the factors that allowed incorrect assembly to occur and those that prevented the defect from being detected before shipment.
Causal Hypotheses and Supporting Evidence
| Causal Hypothesis | Evidence to Examine |
|---|---|
| Similar component appearances increased the likelihood of confusion | Component labels, storage arrangements, previous identification errors |
| Scanner failure increased the risk of incorrect assembly | Equipment logs and the timing of the scanner failure |
| Procedures for operating during scanner failure were inadequate | Operating instructions, incident records, interviews |
| Final inspection was unable to detect incorrect assembly | Inspection requirements, inspection records, actual inspection practices |
Some of these statements remain hypotheses until verified through records or additional investigation.
Preventive Measures
Possible corrective measures include:
| Measure | Expected Effect |
|---|---|
| Prevent assembly operations when barcode verification is unavailable | Avoid assembly without automatic component identification |
| Redesign component containers or identification methods | Reduce the likelihood of selecting the wrong component |
| Verify component identification numbers during final inspection | Prevent incorrectly assembled products from being shipped |
| Revise equipment failure procedures and restart conditions | Reduce risks associated with exceptional operating conditions |
The effectiveness and consequences of these measures must also be considered.
For example, a system that automatically stops production when the barcode scanner fails may be effective in preventing incorrect assembly, but it may also affect production availability.
Likewise, introducing additional final inspections may require consideration of inspection reliability and processing time.
The appropriate combination of measures depends on the importance of the problem and the associated safety and quality requirements.
Why RCA Should Not Stop at “Operator Error”
RCA investigations sometimes identify mistakes or errors in human actions.
However, concluding that an incident occurred because an operator was careless may contribute little to preventing similar incidents.
Suppose an operator failed to follow the prescribed procedure.
Several questions remain.
Was the procedure sufficiently clear?
Was the necessary information available at the point of work?
Was following the prescribed procedure practically feasible?
Had exceptional workarounds become routine because of time pressure or workload?
Could the equipment have been designed to prevent the mistake or detect it before harmful consequences occurred?
These questions reflect an approach to system design that recognizes the possibility of human error and seeks to reduce its consequences through preventive and protective mechanisms.
This does not mean that all individual actions should automatically be attributed to organizational or equipment failures.
In some situations, deliberate violations or individual responsibilities may also require examination.
However, determining responsibility and investigating the causes of an incident are different activities.
Even if an operator is disciplined, the same mistake may be repeated by someone else if the underlying conditions remain unchanged.
What Makes a Preventive Measure Effective?
Once causes have been identified, the next challenge is developing measures that actually reduce recurrence.
After an accident or defect, organizations sometimes adopt measures such as reminding employees to be careful, providing additional training, or revising operating manuals.
These measures are not necessarily inappropriate.
However, if the system continues to rely primarily on operators’ attention and memory, similar errors may remain possible.
Safety engineering uses hierarchical approaches to evaluating the strength of preventive and protective measures.
| Example of Preventive Measure | Main Characteristic |
|---|---|
| Eliminate the hazardous activity or failure-producing condition | Removes the underlying source of the problem |
| Introduce interlocks or error-proofing mechanisms | Prevents failures without relying solely on human judgment |
| Redesign equipment or operating processes | Makes undesirable events less likely |
| Introduce automated inspection or alarms | Detects problems and limits their consequences |
| Add checklists or verification procedures | Reduces risks through additional human checks |
| Provide warnings or training | Improves awareness, understanding, and behavior |
Measures that structurally reduce opportunities for error may provide more reliable and sustainable protection than measures relying only on reminders or awareness.
However, the best measure depends on the nature of the problem, technological constraints, implementation costs, and possible unintended consequences.
RCA² — Emphasizing Action Rather Than Analysis Alone
In healthcare safety, concerns have been raised that conventional RCA investigations sometimes end with reports identifying causes without producing sufficiently effective improvements.
In response, the U.S. National Patient Safety Foundation introduced the concept of RCA² (Root Cause Analyses and Actions) in 2015.
RCA² emphasizes the importance of implementing meaningful corrective actions and evaluating their effectiveness, rather than treating cause identification as the final objective.
Although developed in the context of patient safety, this perspective is relevant to manufacturing, quality management, and business process improvement.
The central objective is not simply to explain why an undesirable event occurred but to reduce the probability that similar events will happen again.
The Relationship Between RCA, FMEA, FTA, and CAPA
Quality management and reliability engineering include several methods related to RCA.
FMEA, FTA, and CAPA have different purposes and are best understood as complementary approaches.
FMEA — Examining Potential Failures Before They Occur
Failure Mode and Effects Analysis (FMEA) examines how products or processes might fail and what consequences those failures could produce.
RCA is generally used to investigate problems that have already occurred.
FMEA, by contrast, is primarily a proactive approach to identifying and evaluating potential failure modes, including those that have not yet occurred.
However, the two methods are closely related.
When RCA reveals a previously unrecognized failure mechanism, the findings can be incorporated into FMEA and used to reassess risks in similar products or processes.
FTA — Analyzing Logical Combinations of Failure Conditions
Fault Tree Analysis (FTA) examines the logical combinations of events and conditions that can lead to a specified undesirable outcome.
For example, equipment shutdown may result from cooling system failure, power supply failure, or malfunction of a control unit.
FTA uses logical relationships such as OR and AND conditions.
An OR condition indicates that any one of several events can lead to a particular outcome.
An AND condition indicates that multiple events must occur together.
These relationships can represent combinations of conditions that are difficult to express using a simple linear chain of questions.
FTA can be applied to the investigation of existing incidents as well as the analysis of potential risks during system design.
CAPA — Managing Corrective and Preventive Actions
Corrective and Preventive Action (CAPA) refers to processes for addressing nonconformities, preventing recurrence, and reducing the likelihood of potential problems.
RCA may be used to investigate the causes of an observed nonconformity.
The findings can then support the selection of corrective actions, followed by implementation and verification of effectiveness.
RCA focuses primarily on understanding the causes and contributing conditions of a problem.
CAPA encompasses the management of actions, documentation, responsibilities, implementation, and effectiveness checks.
Integrating Qualitative and Quantitative Analysis
RCA frequently requires the integration of qualitative and quantitative approaches.
For example, interviews with operators and direct observation may reveal how equipment is actually used and how exceptional procedures are handled.
Meanwhile, numerical data on equipment temperature, pressure, coolant flow, and operating time can help identify the conditions associated with failures.
However, finding a statistical correlation does not necessarily establish a causal relationship.
For example, suppose machine failures are correlated with increased temperature.
This does not reveal whether higher temperature causes the failure, whether the failure causes the temperature increase, or whether another factor influences both.
Additional investigation of operating mechanisms, event sequences, and possible alternative explanations is required.
Experiments or simulations may also be useful, depending on the circumstances.
RCA therefore involves developing qualitative causal hypotheses and examining them through quantitative evidence.
The relationship can also operate in the opposite direction.
Unexpected patterns discovered through numerical analysis may lead investigators to formulate new explanations.
Effective RCA can involve repeated movement between qualitative investigation and quantitative evaluation, with each contributing to a better understanding of the problem.
When Is Root Cause Analysis Appropriate?
RCA is particularly useful when an identifiable problem has occurred and the objective is to understand why it happened and prevent recurrence.
Typical applications include manufacturing defects, equipment failures, workplace accidents, medical incidents, information system outages, and serious operational errors.
However, when the objective is to investigate risks before an event occurs, proactive approaches such as FMEA may be more appropriate.
Similarly, challenges such as “We want to create a new business” or “We need to discover new R&D themes” may not involve a clearly defined failure whose causes can be investigated.
Treating every such challenge as a problem of identifying the root cause of insufficient performance can restrict analysis to existing technologies, organizational arrangements, or business practices.
Exploring new directions may require problem structuring, concept exploration, analogy, and idea generation rather than conventional RCA.
Root Cause Analysis is therefore not a universal method for every kind of problem-solving.
Limitations of Root Cause Analysis
Although RCA offers significant benefits, it also has important limitations.
First, the further an investigation moves into underlying conditions, the more difficult it may become to establish causal relationships.
For example, equipment failure may be associated with inadequate maintenance planning.
However, further investigation might identify maintenance budgets, organizational responsibilities, equipment design decisions, and management priorities as additional contributing factors.
Second, problems do not necessarily develop through a single linear chain of causes.
Interactions among multiple factors and changing conditions over time may be important.
Third, after an accident or failure has occurred, investigators may perceive the outcome as more predictable than it actually was beforehand.
This tendency is related to hindsight bias.
Fourth, investigators may confuse the generation of plausible causal explanations with confirmation that those explanations are correct.
Fifth, even when relevant causes are identified, problems may recur if corrective actions are not implemented or do not provide sufficient protection.
Consequently, the quality of RCA should not be evaluated solely by the length of the investigation report or the completeness of the diagrams produced.
AI-Assisted Root Cause Analysis
Large language models and machine learning can support several activities involved in RCA.
For example, they can help organize information from failure reports, quality records, maintenance histories, and daily operating logs.
They can assist with the development of 5 Whys analyses and Cause-and-Effect Diagrams and generate candidate explanations for observed problems.
AI systems may also identify similarities between current incidents and historical cases, allowing investigators to examine previously implemented corrective measures.
Statistical analysis and anomaly detection can help investigate numerical sensor data and operating conditions associated with failures.
However, an explanation generated by an LLM is not necessarily the actual cause.
For example, if an equipment failure report mentions overheating, an AI system may propose cooling system malfunction based on its general knowledge.
In reality, the event might involve a faulty temperature sensor or an unrelated mechanical condition.
AI-assisted RCA should therefore distinguish between different types of information:
- Facts established through observation or measurement
- Situations and perceptions reported by people
- Candidate causes proposed by AI
- Evidence supporting or contradicting causal hypotheses
- Verified causes and unverified explanations
- Corrective measures and their observed effectiveness
Maintaining explicit relationships among these types of information could help turn AI from a tool that merely produces plausible explanations into one that supports evidence-based investigation.
It is also important that AI-assisted analysis remain open to alternative hypotheses and previously unexamined conditions rather than becoming committed to the first explanation generated.
Root Cause Analysis in ThinkNavi
ThinkNavi treats Root Cause Analysis as a comprehensive problem-solving approach that can combine individual methods such as 5 Whys and Cause-and-Effect Diagrams.
When the problem itself is unclear, Problem Structuring can help define the scope and objectives of the investigation.
Cause-and-Effect Diagrams can be used to organize possible causes, while 5 Whys can help explore chains of causal explanations.
Fault Tree Analysis can be useful when failures involve logical combinations of multiple conditions.
Statistical methods and Design of Experiments can support the quantitative evaluation of causal hypotheses.
In ThinkNavi Free, a possible implementation would allow users to manually record observed events, confirmed facts, candidate causes, evidence, verification results, and corrective actions while using relevant analytical techniques.
LLM-assisted functions could support the generation of alternative causal hypotheses, comparison of competing explanations, organization of evidence, suggestions for verification methods, and development of corrective measures.
These are possible directions for future development and do not imply that all such capabilities are currently available.
In RCA, reducing a problem to a single clear explanation is not necessarily the best outcome.
Multiple factors may contribute to an event, and the relationships among them may be important.
Furthermore, even when it is impossible to eliminate every contributing cause, the risk of recurrence may be reduced through improved prevention, detection, and mitigation mechanisms.
The essential purpose of RCA is not to claim that one ultimate and definitive cause has been discovered. It is to understand, through evidence, how a problem occurred and identify what can be changed to make the same problem less likely to happen again.
Related Topics
- Problem Structuring — Breaking Down Problems, Understanding Relationships, and Finding Paths to Solutions
- Five Whys | Exploring Root Causes by Repeatedly Asking “Why?”
- Cause-and-Effect Diagram (Fishbone Diagram) — Systematically Organizing Factors That May Contribute to a Problem
- Logic Trees and Issue Trees — Breaking Down Problems and Identifying the Questions That Need Answers
- Fault Tree Analysis (FTA)
- Failure Mode and Effects Analysis (FMEA)
- Process Maps
- Process Mining
- Systems Thinking | Interdependence and Change Over Time
- Causal Loop Diagrams | Understanding Feedback
- The Scientific Method and Falsifiability — Generating Hypotheses and Testing Them Critically
- Induction, Deduction, and Abduction — Discovering Patterns, Drawing Conclusions, and Generating New Hypothese
- What Is Statistics? — Discovering Patterns in Data and Understanding an Uncertain World
- Multivariate Analysis — Discovering Relationships and Structures Among Multiple Variables
- Design of Experiments (DOE) — Investigating Multiple Factors and Their Interactions Through Systematic Experimentation
- Qualitative and Quantitative Thinking — Two Perspectives on Understanding the World and Their Integration
References and Further Reading
- American Society for Quality (ASQ) — What Is Root Cause Analysis?
- ASQ — Root Cause Analysis Tools
- Agency for Healthcare Research and Quality (AHRQ) — Root Cause Analysis
- AHRQ — Rethinking Root Cause Analysis
- Institute for Healthcare Improvement (IHI) — RCA²: Improving Root Cause Analyses and Actions to Prevent Harm
- Occupational Safety and Health Administration (OSHA) — Incident Investigation
- NASA — Mishap Investigation
- ASQ — Failure Mode and Effects Analysis (FMEA)
- James Reason, Human Error, Cambridge University Press, 1990.
- James Reason, Managing the Risks of Organizational Accidents, Ashgate, 1997.
- Dean L. Gano, Apollo Root Cause Analysis: A New Way of Thinking, Apollonian Publications.