7.5 The Root Cause Verification Matrix
Key Takeaways
- CSSC lists seven acceptable root cause verification methods: statistical analysis, design of experiments, logical questioning, process observation, gathering additional data, graphical representation, and more granular process mapping.
- The Root Cause Verification Matrix has six documented columns: problem, possible root causes, method of verification, reason for the verification method, verified yes or no, and notes.
- The 'reason for verification method' column is what separates the matrix from a simple results log - it forces the team to justify why each method suits each specific cause.
- A cause that fails verification is a finding, not a failure; the matrix documents disproved causes so the team does not revisit them and does not carry them into Improve.
- The Analyze tollgate requires root cause assumptions to be backed by statistical data 'where possible', and the matrix is where a team records what was possible and what was not.
7.5 The Root Cause Verification Matrix
Quick Summary: Sections 7.1 through 7.4 taught how to generate candidate root causes — 5 Whys, fishbone diagrams, Pareto analysis, and graphical exploration. The CSSC manual is blunt about what has to happen next: "Once teams identify possible root causes, they must verify that the causes are valid." A fishbone branch is a hypothesis, not a finding. The Root Cause Verification Matrix is the Council's named instrument for testing each hypothesis and recording the test, and it is the document that carries the Analyze phase through its tollgate.
Why Verification Is a Separate Step
The failure mode this guards against is the most common way real Six Sigma projects waste money: a team brainstorms twelve plausible causes, picks the two that feel most likely, and spends the Improve phase engineering countermeasures for a cause that was never actually operating. Brainstorming tools are designed to be generous — the fishbone deliberately encourages participation and captures every idea in the room. Generosity in generation demands rigour in filtering.
CSSC also notes the opposite case: sometimes verification is so decisive that the Black Belt may assign someone to begin working on the Improve phase as soon as the cause is verified. More often the root cause is not obvious and the solution for it even less so, requiring additional analysis and validation before moving forward. The matrix is what tells you which situation you are in.
The Seven Verification Methods CSSC Accepts
Root cause verification can be completed via a variety of methods. The manual names these:
| # | Method | Best suited to | Cost / effort |
|---|---|---|---|
| 1 | Statistical analysis | Causes expressible as a difference in means, proportions, or variance between conditions | High rigour, moderate-to-high effort |
| 2 | Design of experiments | Causes involving several interacting inputs where you can manipulate settings | Highest rigour, highest effort |
| 3 | Logical questioning | Causes that can be eliminated by reasoning from known facts | Lowest cost, weakest evidence |
| 4 | Observing a process | Behavioural and compliance causes — is the documented procedure actually being followed? | Low cost, strong for "do they do it?" questions |
| 5 | Gathering additional data | Causes where the existing data set simply does not contain the relevant variable | Moderate |
| 6 | Analyzing data via graphical representation | Causes about distribution shape, spread, or time-ordered behaviour | Low cost, high communicative value |
| 7 | Mapping processes at a more granular level than was done in Define | Causes hidden inside a step that the Define-phase map treated as a single box | Moderate |
Note where the boundary of Green Belt scope sits. Statistical analysis and graphical representation are taught in Units 4 and 5 of the CSSC manual. Design of experiments and detailed process mapping are named here as verification options but are developed in later units and at Black Belt level — the manual says as much, noting that those topics "are covered in later units."
[!IMPORTANT] Method selection is the graded skill. The matrix's power is not that it records a verdict; it is that it forces the team to state why this method suits this cause. Choosing a two-sample t-test to verify "operators were never trained on the new SOP" is a category error — no amount of statistical rigour tests a compliance question. Process observation does, cheaply and conclusively.
The Six-Column Template
Whatever method is used to validate root cause assumptions, the Six Sigma team should document it. CSSC specifies the columns:
| Column | Contents |
|---|---|
| Problem | The problem statement, repeated once and applied to every row |
| Possible Root Causes | One candidate cause per row, drawn from the fishbone, 5 Whys, or Pareto work |
| Method of Verification | Which of the seven methods will be used |
| Reason for Verification Method | Why that method is appropriate for this cause |
| Verified? | Yes / No — the outcome of the test |
| Notes | Supporting detail, and in some cases whether a senior Six Sigma leader such as a Master Black Belt agrees |
Teams can also create similar documents in Excel or Word; the template is a convention, not a mandated form.
CSSC's Worked Example: The Burnt Cake Problem
The manual's illustration runs a bakery defect through the matrix. The problem statement: "Cakes in the Delaware bakery are coming out burnt 10 percent of the time."
| Problem | Possible Root Cause | Method of Verification | Reason for Verification Method | Verified? |
|---|---|---|---|---|
| Cakes in the Delaware bakery are coming out burnt 10% of the time | Temperature too hot | Run chart of temperature against required temperature | Allows the team to visually determine whether temperatures exceed requirements at any point during the bake process | Yes |
| Bake times inconsistent | Box plot of bake times per type of cake | Provides a visual representation of the variation per cake type; bake times should not vary widely by cake, so the boxes should be flat, letting the team determine whether certain cake types are more of a problem | Yes | |
| Instructions not provided to staff | Process observation | An easy way to determine whether bakery staff have the instructions necessary to complete work without defects | Yes |
Study the third row. The cause is procedural, so the method is observation — not a control chart, not a hypothesis test. And study the second: the box plot is not chosen because box plots are fashionable but because the team has a specific expectation about what the picture should look like (flat boxes) and can therefore be surprised by the data. A verification method that cannot produce a "no" is not a verification method.
Working the Matrix in Practice
Step 1 — Carry candidates over, do not re-brainstorm
Every row must trace to a fishbone branch, a 5 Whys terminal answer, or a Pareto bar. If a cause appears in the matrix that appears nowhere upstream, someone has smuggled in a favourite theory.
Step 2 — Pick the cheapest method that can actually disprove the cause
Rank the seven methods by cost and start low, but never below the level at which the method could return "no." Logical questioning is nearly free and eliminates causes that are physically impossible; it cannot settle a question about whether two machines differ in output.
Step 3 — Write the reason before running the test
Pre-committing to why the method fits prevents the retrospective rationalization that turns a matrix into a results log.
Step 4 — Record "no" verdicts as carefully as "yes" verdicts
A disproved cause is a real deliverable. It stops the team revisiting the idea in month four and stops Improve engineering a countermeasure for a phantom.
Step 5 — Escalate where the notes column says to
Where the stakes are high, capture whether a senior Six Sigma leader such as a Master Black Belt agrees with the verification. That signature is what a champion looks for at the tollgate.
How the Matrix Satisfies the Analyze Tollgate
Map the completed matrix against the Analyze gate list and the fit is exact:
| Analyze tollgate requirement | Matrix column that supplies it |
|---|---|
| Primary root causes have been identified | Possible Root Causes, filtered to the Verified = Yes rows |
| Team has prioritized root causes | Ordering of the verified rows, usually by Pareto contribution |
| Champion or sponsor agrees with priorities | Notes column, plus the tollgate presentation itself |
| Root cause assumptions backed by statistical data where possible | Method of Verification + Reason columns — which also document where it was not possible |
| Relationships between variables are understood | Reason for Verification Method |
| Variable relationships confirmed with statistical analysis where possible | Verified? column for rows using methods 1, 2, or 6 |
That "where possible" hedge is the reason the Reason column exists. A team that verified a behavioural cause by observation rather than statistics has not skipped the requirement — it has documented that statistical verification was not the applicable tool. A team that had the data and chose observation because it was easier has.
Realistic Exam Scenario
A Green Belt at a mail-order pharmacy is chasing a 4% mis-fill rate. The fishbone produced five candidates. The team fills the matrix:
- New pick-to-light hardware installed in March — verified by a run chart of daily mis-fill rate against the install date. Verified: No. The rate was flat across the install.
- Second-shift staffing below plan — verified by a two-sample test of mis-fill proportion between shifts. Verified: Yes.
- Look-alike/sound-alike drug pairs shelved adjacently — verified by more granular process mapping of the pick walk plus a Pareto of which pairs erred. Verified: Yes.
- Temperature excursions degrading barcode labels — verified by logical questioning: the labels are applied after the cold chain ends, so the cause is physically impossible. Verified: No.
- Staff never trained on the revised verification step — verified by process observation. Verified: Yes.
Three of five survive. Note that candidate 4 cost nothing to kill and candidate 1 cost one chart — the team spent its statistical effort only where a cheaper method could not return a verdict. That prioritization is precisely what the matrix is designed to produce.
Common Exam Traps
- Trap 1: Treating the fishbone output as findings. The fishbone generates hypotheses. Verification converts a subset of them into root causes.
- Trap 2: Assuming statistical analysis is always required. CSSC lists seven acceptable methods, and the Analyze tollgate qualifies statistical backing with "where possible."
- Trap 3: Dropping disproved causes from the matrix. A "No" row is documentation, not clutter.
- Trap 4: Omitting the Reason column. Without it the matrix degrades into a results log and cannot answer the tollgate question of whether the method fit the cause.
- Trap 5: Verifying a behavioural cause statistically. Whether staff have the instructions they need is settled by observing the process, exactly as in the burnt-cake example.
A Six Sigma team's fishbone diagram surfaces the candidate root cause 'assembly operators were never issued the revised torque procedure.' Which verification method does the CSSC Root Cause Verification Matrix approach indicate, and why?
Which set of columns does the CSSC Root Cause Verification Matrix template contain?
At an Analyze tollgate, a champion challenges a team that verified two of its four root causes by process observation rather than statistical testing. Which response is consistent with the CSSC Body of Knowledge?