How to do a 5 Why (the three-legged version)

A 5 Why that asks why it happened, why you missed it and why your system allowed it, with a worked example and the mistakes that end it too early.

A 5 Why is a root cause method. You state the problem, ask why it happened, then ask why of each answer until you reach a cause you can change. One chain of whys usually stops at the first cause that sounds right. The three-legged version runs three chains, why it happened, why you did not catch it and why your system allowed it, because most escapes are three failures, not one. Back every why with evidence, and stop when the answer is something you can fix and prove.

What a 5 Why is for

A 5 Why is the simplest root cause method there is. You write down the problem and ask why it happened. Whatever the answer is, you ask why again, and you keep going until you reach something you can change. Five is a habit, not a rule. Some problems take three whys and some take seven.

It is quick, it needs no software and a whole team can follow it on a whiteboard. That is also its weakness. A plain 5 Why gives you one chain, and one chain is easy to bend toward the answer the team already believed.

Where a single chain stops too early

Fourteen housings reach a customer with the same scratch on the same face. The quickest answer in the room is “the operator handled them roughly.” A chain built on that answer goes: handled roughly, because rushed, because short staffed, because of a hiring freeze. It ends at a budget decision nobody can change by Friday.

That chain never asks how the parts got past inspection. It never checks whether the scratches even look like rough handling. And it feels finished, which is the danger.

The three-legged version

Every escape is three failures at once. The defect happened, the checks did not catch it, and the way the plant is run allowed both. So you run three 5 Whys from the same problem statement, one for each failure.

LegThe questionWhat it leads to
OccurrenceWhy did the defect happen?A corrective action on the process
DetectionWhy did we not catch it?A change to inspection, gauging or the control plan
SystemWhy did the way we run the plant allow it?A change to a procedure, change management, training or design

Run the legs side by side if you can. The answers often point at each other, and the system leg is the one that stops the next problem, not just this one.

Worked example: 14 scratched housings

All 14 parts carried the same scratch in the same place, and all were packed after September 28. A fishbone listed every possible cause first. Final inspection records were clean, so the scratches happened after inspection. That cut the list in half. Then the team ran the three legs.

LegChain of whysCause you can fix
OccurrenceThe housings were scratched because they rubbed together in transit. They rubbed because the totes had no dividers. The totes had no dividers because a new tote design arrived from the packaging supplier on September 28.Tote without dividers. Put dividers in, and return to the old tote until then.
DetectionFinal inspection happens before packing. Nothing checks the parts after they go into the tote, so damage from packing or shipping is invisible to everyone in the plant.No check after pack out. Add one, and photograph a sample tote each shift.
SystemThe tote change was handled as a purchasing decision, not a process change. Nobody filed a change request, so nobody asked what the new tote would do to the part.Packaging changes bypass change control. Route them through it.

Three causes, three actions, three owners. Fix only the first and the next change to packaging, labels or carriers slips through the same gap.

How to run one, step by step

  1. Write a problem statement anyone can check

    What, where, how many and since when. “14 housings scratched on the sealing face, packed since September 28” is a statement. “Quality issue with housings” is not.

  2. Gather what you know before you ask why

    Parts, records, photos, the line itself. Go and look. A why without evidence is a guess.

  3. Ask the first why for each leg

    Write each answer as a plain sentence about the process, not about a person.

  4. Test every answer

    Read the chain backwards with the word “therefore.” “They rubbed in transit, therefore they were scratched” holds. If the reverse reads wrong, the why is wrong. Then find the proof: a part, a record, a photo or a test.

  5. Follow every branch

    Sometimes a why has two valid answers. Follow both. Do not pick the one you like.

  6. Stop at something you can change

    When the next why leaves your control or your plant, such as the economy, the weather or “people make mistakes,” back up one step. The cause you can act on is the last one inside your control.

  7. Turn each leg into an action

    One action per root cause, with an owner and a date. Then prove it worked with data, not with a signature.

Mistakes that end a 5 Why too early

  • Stopping at “operator error” or “retrain.” People make mistakes inside the system you gave them. Ask what about the process made the mistake easy.
  • Asking whys about people. “Why did Dave do that?” turns into blame. “Why did the process allow that?” turns into a fix.
  • Running one chain only. If detection and system never get asked, you fix the defect and leave the gate open.
  • Whys that are guesses. “Probably the new tote” is a hypothesis. Go and check.
  • Counting to five. Five is a prompt. Stop when you reach a cause you can fix and prove.
  • Skipping the proof. A 5 Why finds a cause on paper. Data after the fix shows whether it was the right one.

Fishbone first, then 5 Why

Use both. A fishbone widens the field before you commit: list every possible cause under man, machine, method, material, measurement and environment, then check each against the evidence. The 5 Why digs into the causes that survive. In an 8D, this work is the root cause step, and a customer will usually want to see the evidence behind it.

The 3-Legged 5 Why Analysis (QA-F-310) runs the three legs side by side, and the Fishbone Diagram (QA-F-365) sorts the causes under the six headings. A whiteboard works too. What matters is that each why is backed by evidence and each leg ends in something you can change.

Questions people ask

How many whys do I need?

As many as it takes to reach a cause you can fix and prove. Three to five is common. Five is a habit, not a rule.

What is a three-legged 5 Why?

Three 5 Whys run from one problem statement: why the defect happened (occurrence), why it was not caught (detection) and why the system allowed it (system). Each leg ends in its own action.

What is the difference between a 5 Why and a fishbone?

A fishbone lists possible causes so you do not jump to one. A 5 Why follows a cause down to something you can change. They work best together.

Will a customer accept a 5 Why as root cause analysis?

Often yes, when each step is backed by evidence. Some customers want a fishbone or other method for complex problems. Check your customer’s requirements.

How do I know I found the root cause?

The cause explains every symptom, you can switch it on and off and see the problem follow, and the problem stays gone after the fix. Verify with data after the action is in place.