
Root cause analysis in manufacturing: 7 methods & examples

Root cause analysis (RCA) is a systematic way to identify the underlying causes of a defect, failure, incident, or process deviation rather than only correcting its visible symptoms. In manufacturing, RCA supports quality, maintenance, safety, and operational improvement by connecting evidence, structured investigation, corrective action, and effectiveness checks.
A stopped machine can be restarted. A defective batch can be reworked. A customer complaint can be closed. None of these actions necessarily prevents the problem from returning. RCA helps teams determine why the issue occurred, which contributing conditions enabled it, and what must change to reduce recurrence.
What is root cause analysis in manufacturing?
Root cause analysis in manufacturing is a structured problem-solving process used to identify the fundamental causes of quality defects, equipment failures, safety incidents, and process deviations.
The purpose is not to find a single person or event to blame. It is to understand the chain of technical, procedural, material, environmental, and organizational factors
that allowed a problem to occur.
A practical RCA process usually answers five questions:
- What happened?
- Where and when did it happen?
- What evidence is available?
- Which causes contributed to the event?
- Which corrective actions will remove or control the confirmed root cause?
RCA is commonly triggered by customer complaints, recurring nonconformities, downtime, safety incidents,
scrap increases, yiel loss, production KPI deviations, or audit findings. It can also be initiated after a near miss, when the organization wants to prevent a more serious event.
In a digital environment, RCA can connect investigation records with operational data, action
workflows, owners, deadlines, approvals, and evidence of effectiveness. This is one of the ways RCA supports
a broader Decision Intelligence Platform: data and analysis provide the basis for decisions, while governed
processes ensure
that decisions lead to completed actions.
The 5 steps of root cause analysis
A consistent RCA process moves from a clearly defined problem to verified corrective action. Skipping steps often leads to assumptions, incomplete evidence, or actions
that address symptoms rather than causes.
Problem definition → Data collection → Cause identification → Root cause validation → Corrective action and effectiveness check
1. Definethe problem
Describe the issue in factual and measurable terms.
A useful problem statement specifies what happened, where it occurred, when it was detected, how often it occurs,
what product or process is affected, and what the operational impact is. Avoid vague formulations such as “poor quality” or “machine issue.”
For example:
“During the last three production shifts, Line 4 recorded 18 rejected assemblies due to incomplete seal placement. The defect rate increased from 0.4% to 3.1% after a tooling change.”
This statement gives the team a defined scope, a time window, a measurable effect, and a potential point of investigation.
2. Collect data and evidence
Gather information before selecting a cause.
Relevant evidence may include process parameters, equipment alarms, maintenance history, operator logs, batch records, inspection results, photographs, supplier data, standard operating procedures, training records, and shift handover notes.
The objective is to distinguish facts from assumptions. Interviews are valuable, but they should be supported by available production and quality records wherever possible.
3. Identify possible causes
Generate and structure plausible causes using one or more RCA techniques.
This stage may involve a fishbone diagram, 5 Whys, Pareto analysis, fault tree analysis, FMEA, 8D, or Is/Is Not analysis. The selected technique should reflect the complexity of the problem, the available data, and the number of functions involved.
4. Determine and validate the root cause
A root cause is not merely a plausible explanation. It is a cause supported by evidence and sufficiently connected to the observed problem.
Validation may involve reviewing time-aligned data, recreating the condition, comparing affected and unaffected batches,
testing a process change, examining components, or confirming whether the issue disappears after a controlled intervention.
A useful test is:
If this condition were removed or controlled, would the problem be unlikely to recur?
If the answer is uncertain, the team may have identified a contributing factor rather than the root cause.
5. Implement corrective action and verify effectiveness
Corrective action should address the confirmed cause, not only contain the immediate problem.
For example, sorting defective inventory is containment. Updating the setup procedure, recalibrating equipment, modifying a fixture, changing inspection logic, or
retraining operators may be corrective action—provided the action is linked to the validated cause.
The final step is an effectiveness check. The organization should confirm that the action was implemented, that the expected behavior changed, and that the problem has not returned within an appropriate monitoring period.
7 root cause analysis techniques compared
No single RCA method is appropriate for every manufacturing problem. The best technique depends on problem complexity, available evidence, risk, team size, and whether the organization is investigating an existing failure or preventing a potential one.
| Technique | Type | Best For | Complexity | Typical Team | Origin |
| 5 Whys | Inductive questioning | Simple, single-cause problems | Low | Individual or small team | Toyota Production System |
| Fishbone / Ishikawa | Cause-and-effect mapping | Problems with several possible cause categories | Medium | Cross-functional team | Kaoru Ishikawa, 1960s |
| Pareto analysis | Data-driven prioritization | Selecting the highest-impact failure modes or causes | Medium | Individual or team | Pareto principle / Juran |
| FMEA | Preventive risk analysis | Identifying potential failures before they occur | High | Cross-functional team | Reliability and automotive quality practice |
| 8D problem solving | Structured investigation | Customer complaints, supplier issue, recurring failures | High | Cross-functional team | Ford popularization, 1980s |
| Fault tree analysis | Deductive logic analysis | Complex systems with multiple failure paths | High | Specialists and engineering team | Bell Labs, 1961 |
| Is / Is Not analysis | Problem-scoping method | Narrowing the problem before deeper investigation | Low | Individual or small team | Kepner-Tregoe |
5 Whys
The 5 Whys method is the simplest RCA technique. It uses repeated questioning—typically asking “why?” around five times—to move from a visible symptom toward a more fundamental cause.
The method is commonly associated with Sakichi Toyoda and the Toyota Production System. It does not require statistical software or advanced modeling, which makes it useful for straightforward
problems with a limited number of likely causes.
Example:
- Why was the assembly rejected?
Because the seal was not placed correctly. - Why was the seal not placed correctly?
Because the positioning fixture was misaligned. - Why was the fixture misaligned?
Because it was not verified after maintenance. - Why was it not verified?
Because the maintenance procedure did not include a post-service check. - Why was the check missing?
Because the procedure had not been updated after the fixture modification.
The 5 Whys method can oversimplify failures with multiple interacting causes. For more complex cases, it is often combined with a fishbone diagram. ASQ identifies 5 Whys as a problem-solving technique used to identify root causes through
repeated questioning. [1]
Fishbone diagram or Ishikawa diagram
A fishbone diagram, also called an Ishikawa diagram or cause-and-effect diagram, is a visual tool used to organize
possible causes of a problem into structured categories.
The method was developed by Kaoru Ishikawa in Japan in the 1960s. It is particularly useful during team-based brainstorming because it prevents the discussion from focusing too early on one suspected cause.
The “head” of the fishbone represents the observed effect, such as excessive scrap, late delivery, machine stoppage,
or product defect. The “bones” represent categories of possible causes.
Effect: Surface defect rate increased
Possible cause categories: Man → Machine → Material → Method → Measurement → Mother Nature
Fishbone analysis is often combined with 5 Whys. The fishbone diagram helps the team identify possible cause paths; the 5 Whys method can then be applied to investigate the most credible branches. ASQ describes the fishbone diagram as a
cause-and-effect tool used to sort possible causes into useful categories. [2]
Pareto analysis and Pareto charts
Pareto analysis helps teams focus on the “vital few” causes that account for the largest share of a problem.
A Pareto chart combines a bar chart with a cumulative percentage line. The bars show the frequency, cost, or impact of different defect types, failure modes, or causes. The cumulative line shows how much of the total impact is explained as categories are added from highest to lowest.
The approach is linked to the 80/20 principle: a relatively small number of causes may account for a large share of the observed effects. The relationship is not always exactly 80/20, but the method helps prioritize improvement resources.
For example, a plant may identify that three defect categories account for 72% of all rejected units. RCA can then focus on these categories first instead of investigating every low-frequency issue at the same time.
Pareto analysis can also be used to prioritize risks identified through FMEA, especially when an organization needs to
decide where to direct investigation or action resources.
FMEA: Failure Mode and Effects Analysis
Failure Mode and Effects Analysis (FMEA) is a preventive method used to identify how a product, process,
or system could fail before the failure occurs.
FMEA differs from reactive RCA because it begins with the question: “What could go wrong?” RCA begins after a defect, failure, or incident has already occurred and asks: “What did go wrong, and why?”
Two common forms are:
- Design FMEA (DFMEA) — used to assess potential failures in product design.
- Process FMEA (PFMEA) — used to assess potential failures in manufacturing and process execution.
Traditional FMEA evaluates each failure mode using three factors:
Severity × Occurrence × Detection = Risk Priority Number (RPN)
Severity evaluates the impact of the failure. Occurrence estimates the likelihood of the failure. Detection evaluates the likelihood that the failure will be detected before reaching the next process or customer.
In the AIAG & VDA FMEA method, Action Priority is used instead of relying solely on RPN. Organizations should follow the method required by their customer, industry, quality system, or internal
governance framework. [3]
FMEA is a preventive complement to RCA. Its outputs can feed preventive actions into a broader CAPA process.
8D problem solving
8D, or Eight Disciplines Problem Solving, is a structured, team-based method often used for customer complaints,
supplier-quality issues, recurring failures, and formal corrective-action reporting.
The method became widely associated with Ford’s problem-solving approach in the 1980s, although earlier structured quality methods influenced its development.
A typical 8D process includes:
- D0: Prepare and plan the response.
- D1: Form a cross-functional team.
- D2: Describe the problem clearly.
- D3: Implement interim containment actions.
- D4: Identify and verify the root cause.
- D5: Select permanent corrective actions.
- D6: Implement and validate corrective actions.
- D7: Prevent recurrence through system improvements.
- D8: Recognize the team and close the investigation.
RCA is therefore a defined step within 8D, usually at D4. The 8D report provides a formal record of the investigation, containment, corrective action, validation, and prevention activity.
Fault tree analysis
Fault tree analysis (FTA) is a top-down, deductive technique used to examine how combinations of failures or
conditions can lead to an undesired event.
The analysis begins with a top event, such as “loss of line control,” “safety shutdown,” or “critical product failure.
” The team then works downward through possible contributing events using Boolean logic gates:
- AND gate — all listed conditions must occur for the event to happen.
- OR gate — any one of the listed conditions can produce the event.
FTA can be qualitative, helping teams map failure paths, or quantitative, using probability calculations when
reliable event data is available.
FTA and FMEA are complementary. FTA works from a top event downward to possible causes. FMEA works from possible component or process failures upward to their effects.
Is / Is not analysis
Is / Is Not analysis is a problem-scoping method that helps teams define the boundaries of an issue before applying a deeper RCA technique.
It compares what is affected with what is not affected across four dimensions:
| Dimension | “Is” Question | “Is Not” Question |
| What | What product, defect, asset, or event is affected? | What similar product, defect, asset, or event is not affected? |
| Where | Where does the problem occur? | Where does it not occur? |
| When | When did the problem start or appear? | When does it not appear? |
| Extent | How large is the impact? | What is outside the affected scope? |
This technique is associated with Kepner-Tregoe problem solving. It is useful when the investigation scope is unclear or when teams need to separate relevant evidence from background noise.
4M root cause analysis: man, machine, mmaterial, and method
4M root cause analysis is a practical framework for grouping possible causes into four core categories: man, machine, material, and method.
It is often used as the starting point for a fishbone diagram. Many manufacturing teams expand it to 5M or 6M by adding Measurement and Mother Nature, meaning the operating environment.
| Category | What It Covers | Examples of Possible Causes |
| Man | Human factors | Training gaps, fatigue, unclear responsibilities, procedural errors |
| Machine | Equipment and tooling | Wear, calibration drift, maintenance gaps, fixture misalignment |
| Material | Inputs and components | Supplier variation, contamination, incorrect specification, moisture content |
| Method | Processes and procedures | Outdated instructions, incorrect setup, missing verification step |
| Measurement | Inspection and data | Gauge capability issues, wrong tolerance, incomplete data collection |
| Mother Nature | Environment | Temperature, humidity, vibration, dust, contamination |
The 4M, 5M, and 6M structures do not prove causality. They provide a disciplined
way to ensure that the team considers human, equipment, material, process, measurement, and environmental factors before selecting a cause.
FMEA vs. RCA: key differences
FMEA and RCA are complementary methods, but they serve different purposes and operate at different points in the problem lifecycle.
| Aspect | FMEA | RCA |
| Timing | Before a failure occurs | After a failure, defect, or incident occurs |
| Primary purpose | Prevent potential failures | Identify the causes of an actual problem |
| Core question | What could go wrong? | What went wrong, and why? |
| Typical approach | Bottom-up risk assessment | Evidence-based investigation |
| Output | Risk assessment and prevention plan | Confirmed root cause and corrective action |
| Trigger | Design review, process change, risk review | Nonconformity, failure, complaint, incident |
| Relation to CAPA | Supports preventive action | Supports corrective action |
| Typical team | Cross-functional design or process team | Investigation team based on the problem scope |
FMEA supports preventive action by identifying potential failure modes before they create a visible issue. RCA supports corrective action by investigating an observed failure and identifying what must change to prevent recurrence.
Both methods can contribute to CAPA, but they should not be treated as interchangeable.
RCA and CAPA: from investigation to controlled action
Corrective and Preventive Action (CAPA) is a quality-system framework used to investigate nonconformities, implement corrective or preventive measures, and verify their effectiveness.
RCA is the core analytical step within CAPA. It provides the evidence needed to determine which actions are appropriate. CAPA then ensures that actions are assigned, implemented, verified, documented, and reviewed for effectiveness.
A typical CAPA workflow includes:
Detection → Containment → RCA → Corrective action → Preventive action → Effectiveness check → Closure
For regulated sectors, the exact expectations depend on the applicable quality system. ISO 9001 addresses nonconformity and corrective action, while ISO 13485 applies specifically to medical-device quality management systems. In the United States, the FDA’s Quality Management System Regulation became effective on February 2, 2026 and incorporates ISO 13485:2016 by reference for medical-device manufacturers. [4][5]
8D reports can generate CAPA deliverables, while FMEA can provide structured inputs for preventive actions. The important distinction is that an action should be closed only after its effectiveness has been demonstrated.
For organizations that need to formalize how evidence becomes an approved operational decision, a Decision Support System can provide a separate layer for evaluation, approval, and traceability.
Data-driven root cause analysis in manufacturing
Data-driven RCA combines structured investigation techniques with evidence from sensors,
production systems, quality records, and historical process data.
Typical data inputs include:
- sensor readings and machine states,
- SCADA records,
- MES production data,
- statistical process control results,
- historian data,
- quality-inspection records,
- maintenance history,
- operator observations,
- supplier and material-lot data.
The goal is not to replace engineering judgment with data alone. Data helps teams test assumptions, compare affected and unaffected conditions, identify timing relationships, and validate whether a suspected cause is supported by evidence.
For example, an investigation into repeated dimensional defects may compare the affected production window
with previous compliant runs. The analysis may show that the issue appears only after a specific tooling setup, material lot, humidity range,
or calibration event.
Manufacturing analytics can provide the data context needed for such investigations; see Manufacturing Analytics. The integration and governance of industrial data sources are addressed separately in an Industrial Data Platform.
Root cause analysis examples in manufacturing
RCA is used across quality, maintenance, safety, process performance, and production management. The technique should be selected according to the scale and complexity of the issue.
Example 1: repeated quality defect
A plant identifies an increase in incomplete labels on packaged products.
The team uses a Pareto chart to confirm that incomplete labels account for the largest share of packaging rejects. It then uses a fishbone diagram to consider possible causes across Man, Machine, Material, Method,
Measurement, and Environment.
The investigation finds that the defect occurs mainly on one packaging line after a label-roll change. A 5 Whys analysis shows that the loading procedure does not require verification of tension settings for a
new label-roll type.
Corrective action may include updating the procedure, adding a setup verification step, training operators,
and monitoring defect rates after implementation.
Example 2: equipment failure and downtime
A filling machine experiences recurring unplanned stops caused by an overload alarm.
The investigation reviews alarm history, vibration data, maintenance records, and operator notes. The team finds that overload events occur after longer production runs and are associated with a gradual increase in bearing temperature.
RCA can identify the mechanical and procedural contributors to the failure. Predictive-maintenance methods may later help monitor similar conditions, but that topic is covered
separately in Predictive Maintenance.
Downtime or performance losses can also serve as RCA triggers when operational KPIs change. For a dedicated explanation of production performance and OEE, see Manufacturing Performance.
Example 3: safety incident or near miss
An operator experiences a near miss when a component moves unexpectedly during a manual adjustment.
A suitable RCA may use Is / Is Not analysis to define when and where the event occurs, followed by a fishbone diagram or fault tree analysis. The investigation should examine equipment condition, procedure design, training, guarding, communication, and environmental conditions.
OSHA guidance emphasizes the importance of identifying underlying causes of incidents and near
misses so that organizations can develop effective corrective actions and reduce recurrence. [6]
Example 4: process deviation
A process begins producing batches with inconsistent viscosity values.
The RCA team reviews material-lot records, process temperatures, mixing time, equipment calibration,
laboratory measurements, and operator settings. The result may identify a raw-material variation, a measurement-system issue, or a process-control gap.
Once a confirmed cause has been addressed, the outcome can inform broader Process Optimization work. RCA identifies why the deviation occurred; process optimization addresses how the process should be
improved and sustained.
RCA software and vendor landscape
RCA software and services vary from training and consulting offerings to machine-data platforms, quality-management applications, no-code workflows, and industrial operations platforms.
| Vendor | Focus | Deployment | Target Segment |
| TWI Institute | RCA and FMEA training and consulting | Professional services and training | Quality, engineering, and operational teams |
| 6sigma.us | Structured problem-solving and RCA training | Online, virtual, and instructor-led training | Individuals and organizations building problem-solving capability |
| MachineMetrics | Connected machine data, downtime analysis, and manufacturing visibility | Connected manufacturing platform | Discrete manufacturers |
| Autodesk | Manufacturing and engineering software with quality-related capabilities | Software suite | Design and manufacturing organizations |
| FourJaw | Machine monitoring and downtime visibility | Connected monitoring platform | Manufacturing operations |
| Tulip | Digital frontline applications and no-code operational workflows | Cloud platform | Frontline and operations teams |
| WMEP | Manufacturing improvement and advisory services | Consulting and training | Small and mid-sized manufacturers |
| AdvancedTech | Manufacturing consulting and improvement support | Professional services | Manufacturing organizations |
| Smart RDM | Industrial data monitoring, workflow support, and operational context | On-premises, cloud, or hybrid deployment | Industrial organizations managing operational data and processes |
The appropriate solution depends on the investigation workflow, available data sources, regulatory needs, number of sites, required approvals, and the level of traceability expected from initiation through effectiveness verification.
RCA outcomes should also be captured as reusable operational knowledge. When a validated cause, action, and lesson learned must be transferred to frontline teams, Digital Work Instructions can provide a dedicated mechanism for distributing the updated work standard.
How to choose the right RCA technique?
Select an RCA technique based on the problem, not on habit. A simple issue may only require 5 Whys, while a high-risk, multi-factor failure may require a cross-functional 8D investigation supported by fishbone analysis, FTA, and operational data.
Use the following guide:
| Situation | Suitable Starting Technique |
| Simple, repeatable problem with a likely single cause | 5 Whys |
| Problem with multiple possible cause categories | Fishbone / Ishikawa |
| Many defects or failure modes requiring prioritization | Pareto chart |
| Product or process risks before failure occurs | FMEA |
| Customer complaint or recurring supplier-quality issue | 8D |
| Complex technical system with multiple failure paths | FTA |
| Problem scope is unclear or too broad | Is / Is Not analysis |
The availability of data also matters. Pareto analysis requires structured frequency or impact data. FTA may require specialist engineering knowledge. FMEA requires a cross-functional understanding of the product or process. Fishbone analysis is useful when the team needs to organize expert knowledge before deciding what evidence to test.
FAQ
What is root cause analysis?
Root cause analysis is a systematic process used to identify the underlying causes of a problem, failure, defect, or incident instead of only addressing its visible symptoms.
What is root cause analysis in manufacturing?
Root cause analysis in manufacturing is used to investigate quality defects, equipment failures, safety incidents,
downtime, process deviations, and recurring operational problems.
The objective is to identify the technical, material, procedural, environmental, or organizational conditions that
allowed the problem to occur and to implement actions that reduce recurrence.
What are the 5 steps of RCA?
The five steps are:
- Define the problem.
- Collect data and evidence.
- Identify possible causes.
- Determine and validate the root cause.
- Implement corrective action and verify effectiveness.
What are the 5 P’s of RCA?
The 5 P’s of RCA are:
- People,
- Processes,
- Policies,
- Procedures,
- Plant or Equipment.
They provide an additional framework for considering human, organizational, procedural, and technical
contributors to a problem.
What is the 5 Whys method?
The 5 Whys method is an iterative questioning technique that asks “why?” repeatedly until the investigation reaches
a more fundamental cause.
It is most useful for relatively simple problems with a limited number of cause paths. Complex failures often require additional tools, such as fishbone
analysis or fault tree analysis.
What is a Fishbone diagram?
A fishbone diagram is a cause-and-effect tool that organizes possible causes of a problem into categories such as Man, Machine, Material, Method, Measurement, and Mother Nature.
It is also called an Ishikawa diagram and is commonly used in team-based RCA workshops.
What is a Pareto chart in RCA?
A Pareto chart is a bar chart with a cumulative percentage line. It helps teams prioritize the defect types, failure modes, or causes that account for the largest share of a problem.
What is FMEA?
FMEA is a preventive risk-analysis method used to identify potential failure modes, assess their effects, and define actions before failures occur.
It is commonly used in design and process reviews. Traditional FMEA uses severity, occurrence, and detection ratings; current AIAG & VDA practice uses Action Priority rather than RPN alone.
What is the main difference between FMEA and RCA?
FMEA is preventive and asks what could fail before a problem occurs. RCA is reactive and investigates why an actual defect, failure, or incident occurred.
FMEA supports preventive action; RCA supports corrective action. Both can contribute to CAPA.
What is 8D problem solving?
8D is a team-based, structured problem-solving method used for recurring failures, customer complaints, supplier issues, and formal corrective-action reporting.
Its D4 stage focuses on identifying and verifying the root cause, while later stages address corrective action, validation, and prevention of recurrence.
What is 4M root cause analysis?
4M root cause analysis groups possible causes into man, machine, material, and method.
It is often expanded to 5M by adding Measurement and to 6M by adding Mother Nature or Environment. The framework is commonly used in fishbone diagrams.
What is fault tree analysis?
Fault tree analysis is a top-down method that maps how combinations of events or conditions can
lead to an undesired event.
It uses logic gates, such as AND and OR, to represent different failure paths and is useful for
complex technical systems.
What is the difference between RCA and CAPA?
RCA is the analytical investigation used to determine why a problem occurred. CAPA is the broader quality-system process used to manage containment, corrective action, preventive action, effectiveness
checks, documentation, and closure.
How does data-driven RCA work?
Data-driven RCA combines structured investigation methods with evidence from sources such as sensors, MES records, quality data, maintenance history, SCADA systems, and process historians.
The data helps teams validate or reject cause hypotheses by comparing affected and unaffected conditions,
identifying timing relationships, and confirming whether a suspected cause is supported by evidence.
What is an RCA template?
An RCA template is a standardized investigation record. It should include the problem statement, scope, evidence, selected technique, cause hypotheses, validated root cause,
containment action, corrective action, owner, due date, effectiveness check, and closure approval.
How do you choose the right RCA technique?
Choose the technique according to problem complexity, available data, risk level, team size, and required level of formality.
Use 5 Whys for simple issues, fishbone diagrams for multi-category causes, Pareto charts for prioritization,
FMEA for prevention, 8D for formal recurring issues, FTA for complex failure paths, and Is / Is Not analysis to narrow the investigation scope.
Sources and further reading
- American Society for Quality, Problem Solving and 5 Whys.
- American Society for Quality, Fishbone Diagram.
- Automotive Industry Action Group, AIAG & VDA FMEA Handbook.
- ISO, ISO 9001:2015 Quality Management Systems and ISO 13485:2016 Medical Devices — Quality Management Systems.
- U.S. Food and Drug Administration, Quality Management System Regulation (QMSR).
- Occupational Safety and Health Administration, Root Cause: The Importance of Root Cause Analysis During Incident Investigation.


