Module 10 · Analyze

Root cause analysis

Graphical analysis (Module 9) shows you where to look. Root cause analysis is the disciplined process of actually looking: generating candidate causes without prematurely narrowing them, testing each one against evidence instead of opinion, and building a shared, structured picture of a failure mode before proposing a fix. This module covers the core tools: cause-and-effect diagrams, the 5 Whys done properly, Kepner-Tregoe's Is/Is-not comparison, an introduction to fault trees, and process FMEA per the AIAG-VDA handbook, with a full worked PFMEA on the brazing process.

Learning objectives

• Build a cause-and-effect (fishbone) diagram organized by standard cause categories.
• Run a 5 Whys analysis that demands evidence at each step, not the first plausible guess.
• Use Kepner-Tregoe's Is/Is-not structure to narrow a problem before brainstorming causes.
• Build and quantify a simple fault tree using AND and OR gates.
• Build a process FMEA per the AIAG-VDA handbook's structure, rate Severity, Occurrence and Detection, and compute RPN.
• Explain why RPN alone can misprioritize risk, and what Action Priority changes about that.

Why this matters

The published crankshaft DMAIC case cited in Modules 3 and 4 used exactly two of this module's tools in its Analyze phase: a cause-and-effect diagram and a process FMEA, ahead of the statistical work that produced its reported Cp and Cpk improvement.^[6] That ordering is not incidental. Root cause tools are cheap, fast, and they scope the expensive work (a designed experiment, a new gauge study, a process change) onto the failure modes actually worth the effort, instead of the ones that happen to be top of mind in a meeting.

The scenario below is a constructed illustration, not a real incident.

The most common way root cause analysis fails is not using the wrong tool; it is stopping at the first answer that sounds right. A team investigating leak-test rejects asks "why did this joint leak," gets the answer "the operator rushed the flux step," writes a corrective action for operator retraining, and closes the investigation — three whys short of anything, no evidence collected, no fixture or furnace data pulled, and a very plausible-sounding story that happens to blame the person easiest to blame. Two months later the reject rate is unchanged, because the retrained operator was never the cause; a furnace zone was running four degrees under profile the entire time. Every tool in this module exists to make that shortcut harder to take by accident.

Cause-and-effect diagrams

Kaoru Ishikawa's cause-and-effect diagram (fishbone, or Ishikawa diagram) organizes candidate causes of one clearly stated effect into standard categories, conventionally Man, Machine, Material, Method, Measurement, and Environment for a manufacturing process.^[3] The categories are a checklist, not a theory: their purpose is to keep a brainstorming session from exhausting itself on the first category anyone thinks of (almost always "Man") and skipping the other five.

The diagram below is a constructed example, drawn for teaching.

5 Whys, done properly

The 5 Whys technique, from Sakichi Toyoda and formalized within the Toyota Production System, repeatedly asks "why" about a stated problem until a root cause is reached, typically in about five iterations.^[4] "Properly" means one specific discipline: each "why" answer must be something the team can point to evidence for — a data pull, a physical inspection, a log — not a plausible guess. A 5 Whys session that never leaves the conference room is brainstorming with a numbering system, not root cause analysis; the value of the technique is entirely in the verification step between each why and the next one.

Is/Is-not

Kepner and Tregoe's Is/Is-not structure compares where, when, and how much a problem occurs against where, when, and how much it plausibly could occur but does not.^[5] The comparison is deliberately negative-space: a defect that appears on cavity B but never cavity A, on the night shift but never day shift, or after a specific date but never before it, is telling you something through what it does not do, and the distinctions between the "is" and "is not" columns are frequently the fastest route to a specific, testable cause — well before a full statistical study confirms it.

Fault tree introduction

A fault tree is a deductive, top-down diagram: start from one specific undesired top event and work backward through the logical combinations of more basic events that could produce it, connected by AND and OR gates.^[2] An AND gate needs every input event to occur for the output to occur; an OR gate needs only one. Unlike a fishbone diagram (which organizes hypotheses) or 5 Whys (which is a single chain), a fault tree can be quantified directly from estimated or measured probabilities of the basic events at the bottom of the tree.

Process FMEA per the AIAG-VDA handbook

The AIAG-VDA FMEA Handbook structures a process FMEA (PFMEA) as seven steps: Planning and Preparation, Structure Analysis, Function Analysis, Failure Analysis, Risk Analysis, Optimization, and Results Documentation.^[1] Failure Analysis is where the tool does its cause-and-effect work explicitly: for every process step, every plausible failure mode, its effect, and its cause are named. Risk Analysis rates each failure mode on three 1-to-10 scales — Severity (S, how bad the effect is), Occurrence (O, how often the cause happens), Detection (D, how well the current controls catch it before it escapes) — and the classic Risk Priority Number is their product.

The current AIAG-VDA handbook replaces ranking failure modes by raw RPN with an Action Priority (AP) rating of High, Medium, or Low, driven primarily by Severity, then Occurrence, then Detection, rather than treating the three factors as freely interchangeable in one product.^[1] The official AP lookup table itself is not reproduced here; it is proprietary content within the licensed handbook, and this course's sourcing for its exact cell-by-cell contents does not go beyond a secondary summary.^[7] The principle behind it, though, is straightforward and worth internalizing on its own: a high-severity failure mode should not quietly fall to the bottom of a priority list just because it is rare and well detected, which is exactly what a pure RPN product can do. Worked example 1 below shows this happening on real numbers.

Prioritization

RPN, Action Priority, and a Pareto chart (Module 9) of failure frequency are three different lenses on the same question, and they can disagree. RPN and AP both rate potential risk from an FMEA exercise, using judgement-based ratings; a Pareto chart of actual logged failures ranks by what has already happened. A failure mode can be genuinely low-probability and still deserve a high AP if its severity is high enough, while never showing up on this quarter's Pareto chart at all — both views are legitimate, and using only one of them (usually the Pareto chart, because the data already exists) is how a rare-but-severe risk stays unaddressed until it happens.

Worked examples

Worked example 1: PFMEA excerpt, the brazing process

The data below is a constructed example, not a real production PFMEA.

Seven failure modes from a process FMEA on the furnace-braze step, each rated 1 to 10 on Severity, Occurrence and Detection.

Total RPN across all seven modes: 754; mean 107.7. By RPN alone, "wrong braze alloy used" ranks dead last, with an RPN of only 18 — twelve times smaller than the top item. Look at its Severity alone, though: a 9, tied for the highest severity rating on the whole list, exactly as severe as "tube wall thinning" and higher than everything else. Its low RPN comes entirely from Occurrence and Detection both being very low (1 and 2: this specific mistake almost never happens, and when it does, the current controls catch it almost every time). That is precisely the situation Action Priority logic is built to handle differently from raw RPN: a high-severity failure mode does not automatically deserve the bottom of the priority list just because its current occurrence and detection numbers happen to be good today. If either of those numbers ever gets worse — a supplier substitution, a label mix-up in stores — the severity is already sitting at 9, waiting.

Worked example 2: fault tree, a leak escaping undetected

Constructed example; the basic-event probabilities are illustrative, not measured data.

The capstone's charter (Module 3) states a 4.2 % leak-test reject rate — leaks the test catches. This fault tree asks a different, narrower question: what is the probability a leak escapes the test undetected and reaches the customer? "Braze joint leaks" is built from the same three plausible causes a fishbone diagram might surface, quantified here as basic events.

• Leak escapes to the customer undetected [OR] = 0.00412 (0.412 %)
  • Joint leaks and the test fails to catch it [AND] = 0.00212
    • Braze joint leaks [OR] = 0.0424
      • Insufficient flux coverage (basic event) = 0.015
      • Joint gap out of tolerance (basic event) = 0.020
      • Furnace temperature low at this joint (basic event) = 0.008
    • Leak test fails to detect a real leak (basic event) = 0.05
  • Shipping or handling damage causes a new leak (basic event) = 0.002

About 4 in 1,000 assemblies are predicted to reach the customer with an undetected leak — noticeably smaller than the 4.2 % reject rate the test catches, which is exactly the point of a 100 % leak test: most leaks are caught. The tree also shows where the residual risk concentrates: the "test fails to detect" branch (5 % miss rate) contributes roughly as much to the undetected-escape probability as all three physical leak causes combined, which argues for a Module 4 MSA study on the leak-test method itself as much as for any change to the braze process.

Worked example 3: verifying a candidate cause by turning it off and on

The data below is a constructed example, not a real production run.

This is the step the 5 Whys section calls the whole value of the technique, done with numbers. The chain on the brazed header ended at a candidate cause: the assembly fixture's locating pin has worn, so the two parts sit further apart than the drawing intends and the braze gap opens. That is a plausible story consistent with everything seen so far, which is precisely the point at which teams stop and implement. The verification is to turn the suspected cause off and measure: twenty assemblies are built on the worn fixture, the pin is replaced, and twenty more are built on the repaired one. The joint gap is measured on a shadowgraph to 0.001 mm.

Replacing the pin moved the mean gap by 0.01380 mm, and the interval says the true effect is somewhere between 0.00581 and 0.02179 mm. Both the p-value and, more usefully, the effect size say this is a real and substantial change: a bit over one pooled standard deviation. On a characteristic whose working range is a few hundredths of a millimetre, that is worth having. The candidate cause survives.

Two honest limits on what has been shown. First, this is a comparison of two groups built at different times, so anything else that changed between them, a different powder lot, a different operator, a different ambient temperature, is confounded with the pin. The stronger version of this experiment randomises the order of the forty builds across the two fixtures, which is Module 13's subject and the reason it exists. Second, the mean gap after the repair is still 0.10535 mm, not zero variation and not necessarily inside the gap window the process needs; the pin was a cause, and the evidence does not say it was the only one. "Verified" means the arrow in the cause-and-effect diagram is now supported by data, not that the problem is finished.

This is also the answer to the most common failure of root cause analysis, which is not picking the wrong cause but never checking the one that was picked. A cause that has been turned off and on, with the effect measured both times, is in a different evidential class from a cause that a team found convincing in a meeting, and it costs one afternoon.

Common mistakes

1. Stopping at the first plausible-sounding cause. Consequence: the illustrative failure above — a retraining corrective action closes the investigation while the real cause, a furnace zone out of profile, keeps producing rejects. Fix: every "why" needs evidence, not just plausibility.
2. Running 5 Whys as a solo desk exercise. Consequence: one person's mental model of the process, not the process itself, gets interrogated five times. Fix: pull data and walk the floor between each why.
3. Brainstorming causes only under "Man." Consequence: Machine, Material, Method, Measurement and Environment causes never get considered, and a genuine equipment or measurement problem gets missed entirely. Fix: work through all six fishbone categories deliberately, even the ones that feel like a stretch.
4. Treating RPN as the only prioritization number that matters. Consequence: Worked example 1 — a high-severity, low-probability failure mode ranks near the bottom of a pure RPN list and gets no attention until it happens. Fix: read Severity on its own, not only inside the RPN product; use Action Priority logic (Severity first) alongside RPN.
5. Building a fault tree from events that are not really independent. Consequence: a shared upstream cause behind two "independent" branches (the same furnace, the same operator, the same incoming lot) means the AND-gate multiplication understates the true top-event probability. Fix: check for shared causes before assuming independence.
6. Skipping Structure and Function Analysis and jumping straight to Failure Analysis in a PFMEA. Consequence: failure modes get listed without a clear link to which process step and which function they actually affect, making the S-O-D ratings harder to justify and the team's discussion less focused. Fix: follow the AIAG-VDA seven steps in order, even briefly, before rating anything.
7. Using only a Pareto chart of past failures to prioritize risk. Consequence: a rare, high-severity failure mode with no occurrences yet this quarter never appears on the chart and never gets addressed until it happens. Fix: use FMEA-based prioritization (RPN, Action Priority) alongside, not instead of, a Pareto chart of actual history.

Exercises

Exercise 1: a second PFMEA

Constructed example, not a real production PFMEA.

Tasks. (a) Compute RPN for each failure mode and rank them. (b) Which failure mode has the highest Severity? Where does it rank by RPN? (c) Is this the same pattern as Worked example 1, or different? Explain.

Exercise 2: a smaller fault tree

Constructed example; probabilities are illustrative.

A wire-harness assembly ships with an undetected open circuit if a crimp pull-out creates an open circuit and the continuity test fails to catch it, or if the connector is damaged after testing but before shipment.

• Crimp pull-out creates an open circuit (basic event) = 0.010
• Continuity test fails to detect an open (basic event) = 0.03
• Connector damaged after test, before shipment (basic event) = 0.001

Tasks. (a) Draw (in words or on paper) the gate structure connecting these three basic events to the top event. (b) Compute the top-event probability. (c) Which single change would reduce the top-event probability more: halving the crimp pull-out rate, or halving the test's miss rate? Compute both to check your intuition.

Quiz

Ten questions. Score 70 % or more to mark the module complete on this device.

Key takeaways

• A cause-and-effect diagram organizes candidate causes into standard categories (Man, Machine, Material, Method, Measurement, Environment) so a brainstorm does not exhaust itself on the first category anyone thinks of.
• 5 Whys only works when each answer is backed by evidence collected between iterations; without that discipline it is brainstorming with a numbering system.
• Is/Is-not narrows a problem by comparing where, when and how much it occurs against where, when and how much it plausibly could occur but does not.
• A fault tree is deductive and quantifiable: AND gates multiply probabilities, OR gates use 1 minus the product of survival probabilities, and the method assumes independence between branches unless checked.
• Process FMEA rates Severity, Occurrence and Detection on 1-to-10 scales; RPN = S × O × D is the classic product, but Action Priority (Severity first) exists specifically because a high-severity, low-probability failure can rank artificially low on RPN alone.
• RPN/AP (potential risk) and a Pareto chart (actual history) are different lenses that can disagree; use both, not one instead of the other.

References

All web sources accessed 2026-09-09 unless noted.

1. AIAG & VDA. FMEA Handbook, 1st ed., June 2019 (2nd printing with errata, Aug 2022). https://www.aiag.org/training-and-resources/manuals/details/FMEAAV-1 (catalogue-level: existence, edition, printing history, and the seven-step structure are confirmed at this depth; the Action Priority table's exact contents are not reproduced from this source, see [7])
2. NASA (Vesely, W., Stamatelatos, M., et al.). Fault Tree Handbook with Aerospace Applications, Version 1.1, Aug 2002. https://s3vi.ndc.nasa.gov/ssri-kb/static/resources/Fault%20Tree%20Handbook_NASA.pdf
3. Ishikawa, K. (1976). Guide to Quality Control. Asian Productivity Organization. https://openlibrary.org/books/OL4595409M/Guide_to_quality_control (catalogue-level; cause-and-effect diagram origin)
4. Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press. https://books.google.com/books/about/Toyota_Production_System.html?id=QebEDwAAQBAJ (catalogue-level; 5 Whys within the Toyota Production System)
5. Kepner, C. H., & Tregoe, B. B. (1965). The Rational Manager. McGraw-Hill. https://books.google.com/books/about/The_Rational_Manager.html?id=OboWAAAAIAAJ (catalogue-level; Is/Is-not problem analysis)
6. Sharma, G. V. S. S., & Rao, P. S. (2014). A DMAIC approach for process capability improvement: an engine crankshaft manufacturing process. Journal of Industrial Engineering International, 10, 65. https://link.springer.com/article/10.1007/s40092-014-0065-7
7. Quality-One. "AIAG & VDA FMEA." https://quality-one.com/aiag-vda-fmea/ (secondary: seven-step process and Action Priority replacing RPN, as summarized by this source; the official AP lookup table's exact contents are not reproduced in this course)