The 5 Whys: Steps, Example and Limits in Manufacturing

With the 5 Whys, you keep asking why a problem occurred until you reach the root cause. The method is explained in ten minutes and still goes wrong often – usually because the chain breaks off after the first plausible answer.

Where the method comes from

The American Society for Quality traces the technique back to Sakichi Toyoda. It was described by Taiichi Ohno, the architect of the Toyota Production System. In his book Toyota Production System: Beyond Large-Scale Production (Productivity Press, 1988), repeating the question why is the basis of the scientific approach at Toyota: only by asking again and again does the real cause emerge from behind the obvious symptoms.

His well-known example is a machine that stops. Why did it stop? There was an overload and the fuse blew. Why was there an overload? The bearing was not sufficiently lubricated. Why was it not sufficiently lubricated? The lubrication pump was not pumping enough. Why was it not pumping enough? Its shaft was worn and rattling. Why was the shaft worn? There was no strainer fitted, so metal chippings got in. Whoever stops at the first answer replaces the fuse. The chippings keep reaching the pump, and the stoppage repeats.

The steps in practice

1. Describe the problem. Specific, with place, time and extent. “Assembly line 2 has been down for 30 minutes because a housing part is missing” is a workable starting point. “Material problems” gets the team nowhere.
2. Ask the first why. Why did the problem occur? The answer has to be a fact. If nobody knows, the outcome of this round is a task: go and look.
3. Keep asking after every answer. The answer to the first question becomes the second question. That is how a chain builds up.
4. Stop once the cause lies in the process. The last line should name something your team can change: a way of working, a rule, a missing check. If the chain ends at “somebody forgot”, a step is still missing. The next question is then why the oversight could reach the point of a stoppage at all – because a confirmation step is missing, for instance, or because one operation has no check on it.
5. Run the counter-check. Read the chain backwards using “therefore”. If a step sounds contrived, it should be looked at again.
6. Derive an action and check that it works. Give every action an owner and a due date, and look again after a few weeks to see whether the problem has stayed away.

A second example, from assembly

The problem: assembly line 2 has been down for 30 minutes because a housing part is missing.

1. Why did the problem occur? The tugger train did not deliver the material to the line in time.
2. Why did that happen? The transport order was never printed in the warehouse.
3. Why did that happen? The system held the stock at a different storage location, so at the line-side staging location the part counted as unavailable.
4. Why did that happen? Goods receiving moved the pallet by hand but did not post the transfer in the ERP system.
5. Why did that happen? The handheld scanner at goods receiving was faulty, and the process had no way of recording the move immediately by other means.

The root cause is therefore a missing fallback process for when mobile data entry (MDE) devices fail. The action belongs at goods receiving: a defined alternative route for recording moves while a device is out of service. At the assembly line itself, no action would have changed anything.

Why five of all numbers?

Because it has proved a useful rule of thumb. It is not a law. The Lean Enterprise Institute puts it plainly in its Lean Lexicon: “The specific number five is not the point. Rather it is to keep asking until the root cause is reached and eliminated.” Some chains are finished after three questions, others need seven. Filling in the fifth line because the form has five lines is maintaining a form.

Where the method reaches its limits

Two objections come up again and again in practice:

• The answers are subjective. Two teams arrive at different chains for the same problem when nobody checks the answers against the process.
• Five questions are no guarantee. The chain can end before the root cause is reached.

Neither point is an argument against the method. They are the reason a 5 Whys analysis without verification is worth nothing: if five people nod and nobody has gone to look, it was not an analysis.

Typical thinking traps on the shop floor

• A name in the line. If an answer names a person, the chain has stopped there: a name does not explain why the mistake was possible. The way on is to ask which step in the sequence allowed it – an induction that is missing, a check nobody planned for, two parts that are easy to mix up.
• Jumping between levels. A chain that leaps from the machine to company culture has a gap in it. As a test, ask whether another answer would fit between an answer and the question that follows. If one fits, it belongs in the chain.
• Several strands in one chain. When two causes act together, you need two chains – or a fishbone diagram first, to sort out the breadth.
• The analysis disappears. Noted on paper, filed in a folder, nowhere to be found next time. Then the team starts again from the beginning.

Where the analysis belongs

In the 8D report, cause analysis is a step of its own before the corrective and preventive actions; in the PDCA cycle it sits inside “Plan”; and in the daily shop floor routine it belongs where the problem becomes visible. What matters is what happens next: the action needs an owner and a due date, tracked for example on a shop floor team meeting board.

Documenting so that patterns show up

The biggest gain lies in the collection: with twenty analyses side by side, it becomes obvious when the same root cause keeps coming back. That is exactly what the digital 5 Whys analysis is built for: the problem, the chain of whys and the root cause are entered on the display, and completed analyses stay in an overview with their date.

In the template, all analyses are held in a list in the Peakboard Hub. Other data sources can be connected just as well, for example SQL, Oracle or ODBC.