Root cause tree

Top-down from the problem to its symptoms to the verified root cause.

What it measures

The tree is a structured decomposition of a problem, built level by level so nothing gets skipped and nothing gets assumed:

• Apparent problem: the problem as the plant experiences it. Scrap rate up, customer complaint, yield drop. Written precisely: what, where, when, how much.
• Symptoms: the distinct observable signatures the problem shows. One problem usually presents several symptoms, and separating them matters because different symptoms often point at different parts of the process.
• Possible root causes: under each symptom, the candidate causes that could produce it. This level is deliberately generous: a candidate costs nothing to list and everything to miss.
• Actual root cause: the candidate that survives verification. Each possible cause is tested against evidence (process data, retained samples, on/off trials) and eliminated or confirmed. The tree converges on the cause you can prove, not the one that was most popular in the meeting room.

The discipline the tree enforces is the separation of those levels. Most failed investigations come from jumping straight from the apparent problem to a favorite cause, skipping the symptom level where the real branching information lives.

How to read the output

Read the tree by its status marks. Candidates still open need evidence collected; candidates crossed out should each have the evidence that eliminated them written at the node, because a rule-out without recorded evidence has a habit of coming back. A healthy tree narrows as you go down: many possible causes, few surviving ones, one verified actual root cause. Two warning shapes to watch for: a tree where every branch is still open after a week means nobody is collecting evidence, only brainstorming; and a tree with a single branch from top to bottom means the team wrote its conclusion first and decorated it with a diagram afterward.

Sometimes two candidates both survive verification. That is a real result, not a failure of the method: some problems need two contributing causes present at once, and the corrective action then has to address both.

A real use case

End-of-line HiPot failures spike on a cell assembly line. The apparent problem is written at the top: HiPot reject rate tripled over two weeks on line 2. Three symptoms branch under it: rejects cluster on one cell position of the fixture, rejects correlate with two separator lots, and the failure signature is a soft short rather than a hard short. Possible root causes go under each symptom: fixture damage, weld spatter, separator thin spots, electrode burrs, contamination. Then the evidence does the pruning: fixture inspection clears the fixture, weld monitoring data clears the welder on the affected dates, but separator thickness maps show low-end excursions in exactly the two implicated lots, and cross-sections of failed cells find the thin spots at the short location. The tree converges: actual root cause, separator lots at the thin edge of spec. The supplier conversation that follows carries the whole tree, including what was ruled out and how, which is what makes the claim stick.

Common mistakes

• Jumping from problem to cause without the symptom level. The symptoms are where the problem tells you which way to look; skipping them turns the tree into a guess with boxes around it.
• Listing too few possible causes. The tree only converges honestly if the candidate level was wide enough to contain the truth in the first place.
• Eliminating candidates by opinion instead of evidence. Every crossed-out node needs the data that crossed it out, or the investigation will re-walk it later.
• Stopping at the first confirmed cause without checking the remaining open branches. Confirmation of one candidate does not eliminate the others.
• Treating the tree as a report instead of a working document. It should change daily as evidence lands, and the final version is the investigation record.