Root Cause Isn't a Single Answer

The most common mistake I see in root-cause analysis isn't a bad tool choice -- it's stopping too early. Someone runs a 5 Whys, lands on an answer that's plausible and doesn't implicate anyone in the room, and the team moves straight to solutioning. The fix gets implemented. The problem comes back in four months, slightly disguised.

The first answer is almost never the root cause

The first "why" usually gets you a symptom. The second gets you a contributing factor. It's typically the third or fourth "why" that surfaces something structural -- and it's almost always less comfortable than the first answer, because it tends to point at a system, a handoff, or a decision made upstream rather than a single mistake made by a single person.

A pattern I've seen enough times to trust: if your root-cause analysis lands on "someone didn't follow the process," you haven't finished. That's a symptom of something -- unclear training, a process that's harder to follow correctly than incorrectly, competing priorities, or a control that doesn't actually control anything. Keep asking.

Why fishbone beats 5 Whys for anything non-trivial

5 Whys is a great tool for a single, linear failure. It's a bad tool for anything with more than one contributing cause, because it encourages you to follow one thread to its end and stop -- when the real failure was two or three independent gaps arriving at the same moment.

For anything that shows up more than once, I default to a fishbone (Method, Machine, Material, Manpower, Measurement, Environment) before I let anyone run a Whys chain, specifically because it forces the room to generate multiple candidate branches before committing to one. Most teams, left alone, will grab the first branch that sounds right and build a whole Whys chain on it -- and then defend that chain, because sunk cost applies to analysis just as much as it applies to money.

Validate before you believe it

The step people skip most often: going back to the process and confirming the hypothesized cause with actual data, not just consensus in the room. "That makes sense to everyone" and "that's what the data shows" are different claims. A root cause that hasn't been checked against the actual process -- a time study, a data pull, a walk of the floor -- is still a hypothesis, no matter how good the discussion was.

The test I use now

Before closing out a root-cause analysis, I ask the team one question: if we fix exactly this and nothing else, are we confident the problem doesn't come back in a different shape? If the honest answer is "probably," we're not done. We found a cause. We haven't found the cause.