5 Whys Analysis: Follow One Causal Chain Without Losing the Alternatives

5 Whys Analysis sits in the Analyse phase of RDMAICS. By that point you have recognised a problem, defined its boundaries and measured it. You know the size of the gap. You do not yet know what causes it.

The tool does three things. It follows the causal chain from a measured problem down to a structural cause. It records evidence for every answer so each step can be checked. It keeps alternative branches visible until they are tested, so you do not quietly discard a competing explanation.

Use it when you have a measured problem and a plausible first answer. Do not use it when the problem is still vague, or when you have no data at all. The chain only holds if each link carries evidence. A chain of opinions reads the same as a chain of facts on screen, and that is the risk the evidence field exists to manage.

Everything that follows uses the sample data built into the tool. The case is fictional. No real business, person or product is involved. It is there so you can see the mechanics of the tool on a complete example rather than an empty form.

The problem to explain is stated as: twenty-two percent of pizza deliveries miss the promised 30-minute delivery time. That is a good starting statement. It names a measurable outcome, it carries a figure, and it does not contain a cause. Weak problem statements usually hide a cause inside them, which pre-loads the first why and sends the whole chain one direction.

From that statement the sample case runs five whys, attaches evidence and a confidence label to each one, and parks one alternative cause for later testing.

Start with the problem field. Copy the measured statement in as it appears in your Measure phase output. Resist the urge to summarise it. The percentage matters because it is what you will test any improvement against later.

Then work the chain. Each why has three parts: the answer, the evidence, and a confidence label. The sample case fills all three every time.

Here is the chain as the sample data records it.

The sample case carries one alternative cause: kitchen status reaches dispatch late. It has a test method attached, which is to compare kitchen-ready and dispatch-visible timestamps. Its status is set to to test.

This is the part of the tool that most teams skip in a whiteboard version of 5 Whys. A whiteboard session narrows to one line quickly. Competing explanations get erased. Six weeks later somebody asks why the improvement did not land, and nobody remembers what was considered and rejected.

Keeping the branch visible does two things. It records that the team thought of it. It also forces a decision about testing. A branch marked to test is an open item, not a closed one. If the chain turns out to be wrong, you have somewhere to go next rather than starting again.

The result panel returns the deepest current hypothesis. For this case it is: the legacy design uses static zones. The tool states plainly that this remains a hypothesis until recorded evidence validates it.

Read the word hypothesis carefully. The tool is not telling you the root cause. It is telling you where your chain currently ends and what your team believes sits at the bottom of it. The evidence on why 5 says the design record confirms static-zone logic and that a pilot is still required. That caveat was entered by the person building the chain, and the result respects it.

The tool also offers an AI review that explains the result in context. Treat it as a second reader of your chain rather than a verdict. It can only work with the answers and evidence you entered.

A finished chain is an input to a decision, not the decision itself. In this case the chain points at dispatch logic rather than driver behaviour or kitchen speed. That changes who you talk to next and what you pilot.

Three decisions follow naturally from the sample data. The first is where to run a pilot. Why 5 asks for one explicitly. The second is what to test on the alternative branch, which already has a method written down. The third is what not to do, which is anything aimed at the drivers themselves, since the evidence at why 1 points to a wait before departure rather than the trip.

Carry the chain forward into the Improve phase as written. The evidence notes are the justification for whatever you change. If a change later fails to move the twenty-two percent figure, the chain tells you which link to revisit.

The first mistake is stopping at a person. If a why lands on an individual or a role, you have usually found a symptom of process design. The sample chain passes close to this at why 2, where a shift lead assigns orders manually. It does not stop there. It asks why the process needs that assignment at all, and the next three whys stay on the process.

The second mistake is leaving the evidence field empty or filling it with a restatement of the answer. Evidence should be something somebody could check. Median timestamps, 18 of 20 observed orders, a workflow review, a design record. Each of those sends a reader somewhere specific.

The third mistake is treating five as a target. Five whys is a convention, not a rule. Stop when the next why produces an answer you cannot act on or evidence you cannot gather. Going deeper for the sake of the count produces chains that end in general statements about markets or culture.

The 5 Whys Analysis tool will not find a cause for you. It records and structures the thinking of the people using it. If the team is wrong at why 2, every why after that is wrong too, and the tool will display that chain neatly and without complaint. Structure is not validation.

It will not test anything. The alternative cause in the sample case sits at to test, and it will stay there until somebody runs the timestamp comparison. The tool holds the open item. It does not close it. The same applies to why 5, where the evidence itself calls for a pilot.

It will not handle problems with several independent causes running at once. A 5 Whys chain is linear by design. The alternative cause field gives you one place to park a competing explanation, which helps, but a problem with four interacting drivers needs a different method. If your chain keeps branching at every level, that is a signal to change tools rather than to force the form.

It will not quantify anything. Nothing in the result tells you how much of the twenty-two percent sits with static zones and how much sits elsewhere. It will not price a fix, rank options or predict the effect of a change. Those belong to the Improve phase and to measurement after the change goes live. What this tool gives you is a written, evidenced, checkable account of what your team currently believes, with the untested parts still on the page.