Root Cause Tool
Build the why chain
Approach: problem -> why 1 -> why 2 -> why 3 -> why 4 -> why 5
Write the symptom, not the assumed cause. Example: “Connector seating failures increased on final test after the weekend PM on Line 3.”
Calculator Library / Root Cause Analysis
Start with a clear problem statement, answer each why in sequence, and let the tool carry the chain forward until you reach a likely root cause worth verifying in the process.
Root Cause Tool
Approach: problem -> why 1 -> why 2 -> why 3 -> why 4 -> why 5
Write the symptom, not the assumed cause. Example: “Connector seating failures increased on final test after the weekend PM on Line 3.”
Instructions
This app helps structure thinking. It does not prove causation by itself. A real root cause still needs engineering and process verification before corrective action is finalized.
This tool helps teams move from a symptom statement to a disciplined root-cause conversation. It generates a structured why chain from the problem description, lets users capture each answer step by step, and mark the point where the team believes the underlying cause has been reached.
Use it for recurring defects, process escapes, safety concerns, delivery failures, or team troubleshooting sessions where the first explanation is usually too shallow.
| Step | Question | Purpose |
|---|---|---|
| Problem statement | What failed, where, and how often? | Starts the chain with a factual symptom instead of blame. |
| Why 1 to Why 5 | Why did the previous condition occur? | Pushes the discussion past surface causes into process and system logic. |
| Root cause mark | Which answer best explains the failure mechanism? | Creates a defined handoff point into corrective action planning. |
A shipment arrives with missing labels. Why 1 may show the operator skipped the label check. Why 2 may reveal the check was not built into the station flow. Why 3 may reveal the standard work was revised but not retrained. By Why 4 or Why 5, the team is no longer talking about one person making a mistake. It is talking about a broken management system.
That shift is the reason the method works. The tool makes the chain visible enough to challenge weak logic before the team acts on the wrong cause.
No. Five is a forcing function, not a law. Some issues resolve in three whys and some need more because the system cause is deeper.
Stopping at operator error. If the answer is simply that someone forgot, the team has not yet found the process condition that allowed the failure.
Use more than 5-Why when the problem has several interacting causes, poor traceability, or conflicting evidence. That is where Fishbone, Pareto, or 8D adds structure.
Include the people who know the work directly, plus quality or engineering support where needed. The best chains come from those closest to the process.
The team should define corrective action, ownership, timing, and effectiveness checks. Root-cause identification without follow-through is only diagnosis.
Use the workbook when the investigation needs a printable record, team review trail, and root-cause summary log.
Use the guide for facilitation tips, branching logic, and the difference between symptom, direct cause, and system cause.
Use the original SixSigmaKaizen video to coach teams away from guessed answers and shallow root-cause chains.