Chapter 16: The 5-Why Method: When to Use It and When to Stop

The 5-Why method is deceptively simple, which makes it both popular and dangerous. Ask why something happened. Take that answer and ask why again. Repeat. The theory is that by the fifth why, you've reached root cause. The reality is messier.

Here's how it works in practice. A welding shop in southern Ontario—let's call it TrueWeld Manufacturing—discovered that 18 weld joints on a batch of automotive suspension arms failed a penetration test. Here's their 5-Why chain:

1. Why did the welds fail penetration testing? Because the filler metal wasn't fully fused into the base metal.
2. Why wasn't it fully fused? Because the arc temperature was too low.
3. Why was the arc temperature too low? Because the wire feed speed was set incorrectly on the robotic welder.
4. Why was the wire feed speed incorrect? Because the parameter file wasn't updated after the equipment was serviced.
5. Why wasn't the parameter file updated? Because there's no documented handoff procedure between maintenance and production after equipment repairs.

That fifth why is legitimate. But here's the trap: TrueWeld could have stopped at why #3, identified "incorrect wire feed speed," and implemented a corrective action: "Operator will manually verify wire feed speed against the work order before each production run." That fixes the immediate problem.

However, it doesn't fix the system failure—the missing handoff procedure that ensures parameter changes stick. By stopping too early, you're volunteering to see this problem again.

The test your why rule is essential here. A valid root cause must satisfy two conditions:

1. The 'so therefore' forward test: If I eliminate this cause, will the nonconformance definitely not happen again? TrueWeld's fifth why passes: "If we establish a maintenance-to-production handoff procedure, then parameter drift after service will be caught." Yes.
2. The control test: Can your organization actually control and manage this cause? A root cause like "operator error" fails this test because it's vague and uncontrollable. "No documented procedure for verifying parameter files post-maintenance" passes—you can create a procedure.

When to use 5-Why: Keep this method for simpler nonconformances, lower-risk issues, or single-thread failures. A damaged bearing on a packaging machine. A material mix-up in a single work order. An out-of-spec dimension on a low-risk component. It's fast (15–30 minutes), requires no special tools, and produces actionable root causes when the failure is straightforward.

When to stop: If you can't get a clear answer at why #3, or if you find yourself asking "why" seven or eight times, switch methods. That's a signal the problem is more complex than a simple cause-and-effect chain.

Pro Tip: The biggest mistake we see is stopping at a "why" that describes a symptom rather than a root cause. "Why did the part fail inspection?" "Because the operator didn't measure it correctly." That's not root cause—that's the problem statement restated. Keep pushing: Why didn't the operator measure it correctly? No training? Defective measuring equipment? No procedure for measurement verification? That's where your real answer lives.