Introduction
A supplier fails incoming inspection for the same dimensional defect three audits in a row. A CAPA gets closed, then reopens six months later with the identical complaint. In aerospace, manufacturing, and medical device environments, this pattern almost always traces back to one problem: teams treating symptoms instead of finding the actual root cause.
The FDA's own enforcement record shows how costly that gap can be. In a 2024 warning letter, the FDA cited failure rates of 55% and 75% on two capacity tests at a medical device manufacturer. The company's records lacked any documented root cause analysis for the failures.
This guide breaks down what root cause analysis actually means and the seven techniques quality and safety teams rely on most. You'll get a five-step process you can apply tomorrow, plus real examples from aerospace, manufacturing, medical devices, and workplace safety.
Key Takeaways
- Root cause analysis (RCA) finds the underlying cause of a problem instead of treating its symptoms
- Seven techniques cover most cases: 5 Whys, Fishbone, FMEA, Fault Tree, Pareto, Change Analysis, Kepner-Tregoe
- Use a five-step RCA process: define, collect data, identify causes, verify, implement corrective action
- Examples span aerospace nonconformances, manufacturing defects, medical devices, and safety incidents
- QMS Learning’s Workbench helps teams pick the right method and produce audit-ready documentation
What Is Root Cause Analysis?
Root cause analysis is a structured problem-solving method used to identify the underlying cause of a nonconformity, failure, or defect, rather than just its surface symptoms. It shows up across three connected disciplines:
- Quality management: CAPA processes under AS9100D, ISO 9001, and ISO 13485
- Maintenance and reliability engineering: equipment failure investigations
- EHS and safety: incident and near-miss investigations
Root Cause vs. Causal Factor
These two terms get confused constantly, and the mix-up leads to weak corrective actions. The U.S. Department of Energy draws a clear line between them in DOE-NE-STD-1004-92: a root cause is the most fundamental, correctable cause that, if fixed, would prevent the occurrence and similar ones. A causal factor is broader: any condition or event that shaped the outcome, but would not have caused the problem on its own.
Fixing a causal factor can improve the situation. Fixing the root cause should stop the problem from coming back.
Why Root Cause Analysis Matters
Skip RCA and jump straight to a quick fix, and the same issue tends to resurface, often within a few audit cycles. That drives up cost of quality and audit risk at the same time.
Solid RCA practice delivers:
- Fewer recurring nonconformities across audit cycles
- Faster CAPA and audit closure
- Lower cost of quality from reduced scrap, rework, and repeat inspections
- Evidence-based decisions instead of guesswork
- Stronger safety and compliance standing with registrars and regulators
Root Cause Analysis Techniques: 7 Methods to Know
Different problems call for different tools. Picking the wrong technique, such as running a 5 Whys on a multi-variable machine failure, is one of the most common RCA mistakes teams make.
The 5 Whys
You ask "why" repeatedly until you hit a cause you can actually fix. The technique traces back to Taiichi Ohno's Toyota machine-failure examples, and there's no fixed number of questions involved.
Some problems resolve in two or three whys; others need ten or more before you reach something correctable. It works best on straightforward, single-thread problems.
Fishbone (Ishikawa) Diagram
This visual tool sorts potential causes into categories, branching off a central "spine" toward the problem statement.
Ishikawa's original manufacturing categories were Materials, Machinery, Methods, Measurement, Manpower, and Mother Nature. Most teams today simplify these to Man, Machine, Method, Material, Measurement, and Environment. It works best when a problem has multiple contributing factors that a single why-chain can't untangle.
Failure Mode and Effects Analysis (FMEA)
FMEA scores potential failure modes before they happen, rating each on three factors:
- Severity: how serious the effect would be
- Occurrence: how likely the failure is
- Detection: how well current controls would catch it
Multiply the three scores together and you get a Risk Priority Number (RPN), which tells you where to focus first. It's proactive by design, making it a favorite for design and process risk reviews in aerospace and medical device work.
Fault Tree Analysis (FTA)
FTA works top-down. You start with a "top event" (the failure you're investigating) and map backward through the contributing events using AND/OR logic gates.
NASA has documented its use across aircraft, spacecraft, launch vehicles, and safety-critical software. That track record shows where FTA fits best: complex, safety-critical systems where multiple failures have to combine to cause the top event.
Pareto Analysis
Pareto Analysis ranks issues by frequency to find the "vital few" causes driving most of your defects or complaints. The shorthand version is the 80/20 rule: roughly 80% of effects come from 20% of causes.
Quality pioneer Joseph Juran applied this to quality management decades ago, and it still works well when you're staring at a long list of defect codes and need to know where to spend your time first.
Change/Event Analysis
This method compares before-and-after conditions to isolate exactly what changed when the problem appeared. The DOE's Event and Causal Factor Analysis approach reconstructs a timeline of what happened and when, then compares a failed run against a comparable successful one.
It's especially useful for intermittent problems that don't show up in a static process review.
Kepner-Tregoe Method
Kepner-Tregoe is a structured, four-part decision framework:
- Situation Appraisal: prioritizes issues
- Problem Analysis: finds the root cause
- Decision Analysis: weighs the alternatives
- Potential Problem Analysis: anticipates what could still go wrong
The method traces its case history back to Apollo 13, where the framework was reportedly used to work through the spacecraft's failure under extreme time pressure. It suits complex, high-stakes problems with multiple decision points, not simple one-cause defects.
How to Conduct a Root Cause Analysis: The 5-Step Process
This is how RCA actually plays out on the floor, not just in theory. Most failed RCAs skip step four and jump straight from a hypothesis to a fix.
Step 1 – Define the Problem
State what happened, when, and its impact as specifically as possible. "Machine broke" isn't a problem statement. "Line 3 stamping press produced 240 out-of-tolerance parts between 2nd and 3rd shift on March 4th" is.
A vague problem statement is the single most common cause of an inconclusive RCA.
Step 2 – Collect and Organize Data
Gather records, observations, and witness statements as close to the event as possible. Memory fades and evidence gets disturbed fast, so delayed data collection reduces reliability every time.
Pull these before anything changes:
- Maintenance logs
- Inspection records
- Operator statements
- Process data
Step 3 – Identify Potential Root Causes
Apply one or more of the seven techniques above to move from surface symptoms toward systemic causes. A single method often isn't enough. You might run a Fishbone to generate categories, then a 5 Whys inside the most promising branch.
Step 4 – Verify the Root Cause
Test your hypothesis against the actual evidence. Does it explain every symptom you observed? Would eliminating it plausibly prevent recurrence? This step gets skipped constantly, and it's usually why corrective actions fail to hold.
Step 5 – Implement and Monitor Corrective Action
Assign an owner, set a timeline, and track whether the fix actually works over time. If the same defect shows up again next quarter, the RCA wasn't finished; it just felt finished.
Root Cause Analysis Examples Across Industries
The five-step framework doesn't change much between industries. What changes is the technique you apply and the regulatory context around it. Here's how it plays out in four real-world scenarios.
Aerospace Manufacturing: Recurring AS9100 Nonconformance
Problem: A supplier keeps failing incoming inspection for the same dimensional defect, generating repeat findings at every audit.
Process: The quality team runs a 5 Whys:
- Why did the part fail? The dimension was out of tolerance.
- Why? The operator ran an old setup.
- Why? The work instruction still referenced the pre-changeover process.
- Why was it never updated? The engineering change never triggered a document revision.
The root cause is a controlled document that fell out of sync with the actual process, not simple operator error.
Outcome: Updating the work instruction and retraining on the current revision closed the nonconformance for good. This mirrors a documented NASA finding: after tightening up work instruction accuracy on the Space Shuttle program, deviations dropped roughly 25%, from 7,300 to 5,535 in a single year.
General Manufacturing: ISO 9001 Product Defect Spike
Problem: Scrap rate suddenly climbs on one production line, with no obvious single cause.
Process: The team builds a Fishbone Diagram across Machine, Method, Material, and Man. Material checks out (same lot as always). Method hasn't changed. Operators are trained and consistent. That leaves Machine, and a deeper look reveals gradual calibration drift on the line's measurement gauge.
Outcome: A recalibration schedule fixes the drift, and the defect rate returns to baseline within a week. The fix sticks because intervals now match the gauge's actual stability and criticality, not a generic annual date.
Medical Device: ISO 13485 CAPA Investigation
Problem: A device failure surfaces through post-market surveillance, triggering a formal CAPA.
Process: The team runs an FMEA across the potential failure modes tied to the reported issue, scoring each on severity, occurrence, and detection. The highest-RPN failure mode points to a design tolerance that's tighter in the field than it was in validation testing.
Outcome: A design change, paired with updated validation testing, closes the CAPA. That sequence matches FDA CAPA guidance: cause investigation, corrective action, verification, and effectiveness checks that catch recurrence rather than a one-time fix.
EHS/Safety: Workplace Incident Investigation
Problem: A near-miss occurs on the plant floor when a machine guard fails to engage properly.
Process: The safety team applies Barrier Analysis alongside Fault Tree logic, mapping which control should have stopped the incident and why it didn't. OSHA's incident investigation guidance pushes teams past "operator carelessness" to harder questions: production pressure, an outdated procedure, or inadequate training behind the failure.
Outcome: The investigation identifies a worn interlock sensor missing from the preventive maintenance checklist. Adding it closes the gap and prevents a repeat.
How QMS Learning Helps Teams Apply Root Cause Analysis with Confidence
Knowing the seven techniques is one thing. Applying the right one under audit pressure, with documentation an auditor will accept, is another.
QMS Learning was built by Will Trikha, a 20-year quality and operations practitioner who wrote over 1,000 audit findings and closed twice that number as a quality manager. The platform is built around what holds up on the audit floor, not just theory.
Three features directly support RCA work:
- AI Workbench — diagnoses the problem, routes it to the right method (5-Why, FMEA, CAPA, Gap Analysis, or other common plays), and drafts the audit-ready artifact
- Manager Dashboard — tracks capability gaps and exports training records, scenarios, and artifacts as one indexed evidence package in minutes
- Role-specific pathways — Aerospace & Defense, Manufacturing, Medical Device, and EHS teams train on the standards they face in audit, from AS9100D to ISO 13485 to OSHA 29 CFR 1910
Customers like S3 AeroDefense have reported that root-cause and corrective-action training brought a more structured, disciplined process to their operations: the kind of shift that shows up at the next audit, not just on paper.
Practice Beats a One-Time Certificate
Root cause analysis gets sharper with practice and needs revisiting as standards, products, and problems change. Teams that treat it that way close audits faster and see fewer repeat findings. Teams that don't keep meeting the same nonconformance, year after year.
Frequently Asked Questions
What are some good examples of root cause analysis?
Common examples include aerospace nonconformances from outdated work instructions, manufacturing defects from calibration drift, and medical device failures from design tolerance issues. Full walkthroughs are in the industry examples section above.
What are 7 different root cause analysis techniques?
Seven common techniques are 5 Whys, Fishbone Diagram, FMEA, Fault Tree Analysis, Pareto Analysis, Change/Event Analysis, and Kepner-Tregoe. Which one you use depends on how complex and interconnected the problem is.
What are the 5 steps in a root cause analysis?
Define the problem, collect and organize data, identify potential root causes, verify the root cause, and implement and monitor corrective action. Skipping verification is the most common failure point.
What's the difference between a root cause and a causal factor?
A causal factor likely contributed to the problem but wouldn't have caused it alone. A true root cause, if eliminated, would prevent the problem and similar problems from happening again.
How do you verify that you've found the true root cause?
Test the hypothesized cause against hard evidence and data, not just team agreement in a meeting. If the cause doesn't explain every observed symptom, keep digging before committing to a fix.
Can root cause analysis be automated with AI?
Yes. AI can help diagnose a problem, recommend the right RCA methodology, and draft documentation—QMS Learning’s AI Workbench is built around that workflow. Human judgment is still required to verify findings before you act on them.
