Root Cause Analysis

Quality technique · See it on the map

Runnable here

Tracing a problem back to the condition that, once fixed, stops the whole pattern recurring.

When to use it

A recurring defect, a pattern showing up across more than one report or project, or a single problem expensive enough that a repeat of it would cost more than the investigation.

When to avoid it

A genuine one-off with no pattern behind it. A full root cause analysis on an isolated defect can cost more than the defect itself — log it, fix it, and move on unless it recurs.

Steps

1. Write the problem down as an observed effect, not a diagnosis — '14% of returned units failed the seal test', not 'bad supplier'.
2. Ask why that effect happened, and write the answer as something you have evidence for, not an assumption.
3. Ask why again of that answer, and keep going (five whys) until the chain reaches something someone can actually change, and that is not itself just another symptom restated.
4. Cross-check the chain against a fishbone/Ishikawa diagram sorted by category (method, machine, material, people, measurement, environment) so a plausible-but-wrong single chain doesn't crowd out a second contributing cause.
5. For a cause with more than one contributing path, or safety-critical work, build a fault tree working backward from the failure through the combinations of conditions that produce it.
6. Test the candidate root cause: would removing it have prevented this occurrence, and would it prevent the next one? If either answer is no, keep digging.
7. Assign an owner and a corrective action to the confirmed root cause, and record the discarded intermediate causes too — they tend to resurface.

What it produces

• A documented cause chain.
• A confirmed root cause, distinguished in writing from the symptoms found along the way.
• A corrective action with a named owner.

Common pitfalls

• Stopping at the first plausible cause that happens to implicate nobody in the room.
• Landing on 'human error' or 'miscommunication' — that names an outcome, not a cause; ask why the error was possible in the first place.
• Single-cause tunnel vision when two or more independent causes combined to produce the failure.
• Re-running a root cause analysis on a symptom that was already investigated, without checking the earlier record first.

Worked example

A fit-out contractor, Larch & Rowe Builders, logs three separate callbacks in one quarter for water intrusion around the same window flashing detail, on unrelated projects. The site super's first instinct is 'the installer rushed it.' Five whys: rushed — why? — the crew was behind schedule — why? — the flashing detail wasn't on the standard install checklist — why? — the checklist was last updated before that window model was approved for use — why? — there's no step that links a product substitution to a checklist update. Root cause: no trigger connects material substitutions to checklist revisions. The fix is a checklist-review step added to the substitution approval, not retraining the installer.

Source

• PMBOK-6 §8.2

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.