Root cause analysis at Black Belt level
Root cause tools are often taught as standalone techniques. At the CSSBB level, expect questions on how to integrate them in the Analyze phase to narrow from many hypotheses to a statistically verified root cause. The Analyze phase is not complete until the root cause is confirmed with data, not just identified by the team.
For the individual tool mechanics, see: Fishbone diagram →, 5 Whys → and Fault tree analysis →
DMAIC Analyze sequence
- Generate hypotheses: Fishbone (Ishikawa) diagram to map all potential cause categories (6M: Man, Machine, Material, Method, Measurement, Mother Nature)
- Prioritize: Multi-vari study or Pareto chart to identify the vital few X categories that explain most of the Y variation
- Drill down: 5 Whys or fault tree on the highest-priority branches to reach specific, actionable root causes
- Verify statistically: Hypothesis tests, regression, or DOE to confirm that the suspected X actually drives Y variation in a statistically significant way
- Prove the path: You must be able to show the causal chain: Cause X → mechanism → effect on Y, supported by data
Fault tree analysis (FTA)
FTA is a top-down, deductive tool that starts with the failure event (the "top event") and works backward through logic gates to identify the root causes. It is more formal than 5 Whys and is used when multiple simultaneous failures could contribute. The AND gate (output occurs only if all inputs occur) and OR gate (output occurs if any input occurs) structure allows probability calculation: for independent events, AND multiplies probabilities; OR gives 1 − ∏(1 − pi).
| Tool | Direction | Best for |
|---|---|---|
| Fishbone / Ishikawa | Effect → possible causes (structured brainstorming) | Initial brainstorming; team generates all hypotheses |
| 5 Whys | Symptom → root (iterative questioning) | Drilling into one branch after fishbone narrows the field |
| Fault tree analysis | Top event → basic events (top-down, deductive) | Complex systems with multiple contributing failures; safety-critical problems |
Verifying the root cause
A stated root cause is a hypothesis until proven. Verification methods:
- Turn it on / turn it off: Can you reproduce the problem by introducing the cause? Does the problem go away when you remove the cause? Most compelling evidence.
- Hypothesis test: t-test, ANOVA, or chi-square to test whether mean or proportion differs between cause-present and cause-absent conditions
- Regression: Continuous X → continuous Y; R² shows how much of Y variation X explains
- DOE: Deliberately set X levels and measure Y; the most rigorous proof of causality
Common exam traps
- Correlation is not root cause. The fishbone and scatter plot only generate hypotheses. The CSSBB exam will present a scenario where the team found a correlation and ask what the next step is — the answer is almost always a controlled study (hypothesis test or DOE) to verify causality.
- A root cause must be actionable. "Human error" and "machine failure" are not root causes — they are symptom labels. The root cause is the broken system that allowed the error or failure to occur.
- Exit criterion for Analyze tollgate: Root causes must be verified with data, and their combined effect must be large enough to close the gap between baseline and goal.
Try 5 free CSSBB practice questions on root cause analysis and the Analyze tollgate.
Take the free CSSBB diagnosticMore: DMAIC overview · Project charter · VOC & CTQ · SIPOC · MSA in DMAIC · Process capability · Data collection planning · Graphical analysis · Root cause analysis · Multi-vari analysis · Hypothesis testing · Regression · DOE · FMEA · Define tollgate · Change management · Financial benefits · Team dynamics · Improve tollgate · Piloting & scaling · Poka-yoke (BB) · Solution selection · Control plan · SPC in DMAIC · Sustaining gains
CSSBB Quest by Bizarre Act. Original study material; not affiliated with ASQ. CSSBB is a certification of ASQ. Terms · Privacy