The Core Model
Sakichi Toyoda developed the 5 Whys on the Toyota production line. The method is exactly what it sounds like: ask why the problem happened, then ask it again of each answer, until you reach something you could actually change. Five is a rule of thumb, not a law. Here is one chain, run on a late delivery.
Why 1: the delivery was late. Why? The order reached the floor two days behind schedule.
Why 2: why was it released late? The specification was still being amended.
Why 3: why was it still being amended? The customer's change request arrived after sign-off.
Why 4: why did it arrive after sign-off? Sign-off is scheduled before the customer's own review cycle closes.
Why 5: why is it sequenced that way? Nobody has revisited the order of those two steps since the customer moved their review calendar. The root cause is a scheduling assumption, not a person.
Watch For
A chain that ends at somebody's name. “Because he forgot” is a symptom, not a cause.
Reinforce
Testing each link backwards. If you fixed the last answer, would the one above it actually go away?
Try This Week
Run the chain on one recurring problem, in writing, with the people who saw it happen.
Why It Matters
Most problems get closed at the point they were spotted, which is exactly why the same ones keep returning. A late delivery gets escalated, expedited and signed off, and the next one arrives from the same source a quarter later. The 5 Whys takes about twenty minutes and needs no data you do not already have. Its real value is not the fifth answer. It is that the jump from symptom to cause becomes visible to everyone in the room, so the fix can be argued about properly instead of assumed.
On The Floor
A report goes out to a client carrying last month's figures. The quick fix is obvious: correct it and apologise. The analyst asks why instead. The wrong file was used. Why? Two versions sit in the same folder under nearly identical names. Why? The monthly file is copied rather than replaced, so the old one never leaves. Nobody was careless. The folder was built in a way that made the mistake likely, and fixing the naming convention took ten minutes.
Reflect
Think of a problem that has come back more than twice. At what level did you stop asking why?
When something goes wrong on your team, how quickly does the conversation arrive at a person's name rather than a step in the process?
This Week’s Micro-Action
Pick one recurring irritation and write the chain out, one line per why, before proposing anything.
Look at the last answer you reached. If you could not change it even if you wanted to, you stopped one why too early.
Illustrative workplace case study
A composite learning example from the original issue, rather than a verified client result.
A composite example drawn from common workplace situations in HRDC-sponsored problem-solving workshops. A finance team was rekeying supplier invoices that had already been rejected once. The volume was small but constant, and the working assumption was that suppliers were careless with their paperwork. Running the chain took a single meeting. Invoices were rejected because purchase order numbers did not match. They did not match because suppliers were quoting the reference from the original quotation. They quoted that because the quotation template and the purchase order used different reference formats. Nobody had put the two documents side by side since the templates were written. Changing one field on the quotation template removed most of the rework. What actually made the difference was not the fix, it was that the team stopped treating the rejections as a supplier behaviour problem and started treating them as a document design problem.
Takeaways
The cause sat in a template, two steps away from where the problem was being noticed.
Reframing it from supplier behaviour to document design made a cheap fix visible.
One meeting of structured questioning replaced months of quietly tolerated rework.