5 Whys

The method comes from Taiichi Ohno at Toyota, and it became popular because it costs nothing: no software, no data set, no week of training. That is also why it is so often done badly. The quality does not come from the number of questions, but from whether you can back up each answer.

Five is a rule of thumb, not a quota. Sometimes you are there after three steps, sometimes after eight. You are finished when you reach a cause that lies within your reach and whose removal makes the problem genuinely go away.

When to use it, and when not

What you need

• People. Two to five, and at least one of them does the work where things went wrong. An analysis without that person produces a chain that holds up on paper and not on the floor.
• Evidence. A timeline, and where possible logs, measurements or photographs. Every step in the chain needs something to carry it.
• Time. Thirty to sixty minutes. If it takes much longer, the problem is probably scoped too broadly.

How to run it

1. Write the problem down as an observable deviation

   Not “quality is poor” but “in week 27, 14 of 900 bottles were rejected on fill height”. Leave the problem vague and every later answer becomes defensible.

2. Ask the first why

   Why did the deviation occur? Look for the mechanism, not the culprit. A good answer describes something that happened, not someone who failed.

3. Test every answer against evidence

   Record what each step rests on, and whether that is an assumption or something you established. A chain of five assumptions is a story, not an analysis.

4. Branch where several causes hold

   A why often has more than one answer. Write both down and work both out. Picking a branch straight away means picking before you have evidence.

   Classically, 5 Whys is a straight line. Branching comes from later methods such as Apollo, TapRooT and Cause Mapping, and it is an extension that practice tends to demand: problems of any size usually have two or three causes acting together.

5. Stop at a cause you can influence

   Keep asking and you will eventually arrive at the founding of the company. Stop when you have a cause whose removal is within your reach and which you believe will actually make the problem disappear.

6. Write a countermeasure for each root cause

   With an owner and a date. An analysis without a countermeasure was a conversation, and a countermeasure without an owner is an intention.

Two worked examples

An IT incident

Deviation: for just over half an hour on Thursday afternoon, customers got errors at checkout.

1. Why did customers get an error? Because the payment provider timed out talking to our API.
2. Why did it time out? Because the connection pool to the database was exhausted.
3. Why was it exhausted? Because a new reporting query held connections open for more than forty seconds.
4. Why did that query take so long? Because the column it filtered on had no index, so the whole table was scanned.
5. Why did that query reach production without an index? Because the review of a migration does not look at the execution plan.

Root cause: the review process does not test changes against their execution plan. Countermeasure: every migration containing a new query carries an execution plan in the proposal, and the reviewer signs off on it.

Notice what is not named as the root cause: the developer who wrote the query. That fact adds nothing to the countermeasure.

A stoppage on the line

Deviation: filling line 3 stood still for 70 minutes on Tuesday night.

1. Why did the line stop? Because the labelling machine faulted.
2. Why did it fault? Because the glue reservoir was empty.
3. Why was it empty? Because it was not topped up during the night shift.
4. Why was it not topped up? Because topping up is on the day shift’s checklist and not on the night shift’s.
5. Why is it missing from the night checklist? Because that checklist was written when there was no night shift, and it was never reviewed when one was introduced.

Root cause: standard work was not updated when the night shift was introduced. Countermeasure: a change to the shift roster is not complete until every checklist has been reviewed against it.

Step three is where the temptation to stop lies: “the operator did not top it up”. That answer feels like an explanation, but all it produces is a conversation with that operator. Two questions further on there is something you can genuinely fix, and that helps every shift after this one.

Common mistakes

• Stopping at a person. “Human error” is not a root cause; it is the point where the analysis stopped. Keep going: what made that error possible, or even likely?
• Forcing a straight line. If there are two causes, write down two. A chain that looks tidy is not the same as a chain that is right.
• Recording assumptions as facts. Mark what you suspect and what you established. The first time a countermeasure fails to work, you will know exactly where to look.
• Taking five literally. Asking until you arrive at the weather or at the board is as useless as stopping after two steps.
• Aiming the countermeasure at the symptom. If the root cause sits in the process and the countermeasure is an extra inspection afterwards, you have applied a plaster and left the hole.

Combining it with the other methods

• Is / Is-not logically comes first: get sharp on where the problem does and does not occur, then start asking why. The difference between the two usually gives you the direction of the first why.
• Pareto comes first when you have many separate incidents. Run the analysis on the category that does the most damage, not the one that occurs most often.
• Ishikawa comes first when you have no direction yet. Widen to every possible cause, pick the most likely, and take that one deep.

Frequently asked questions

Does it really have to be exactly five?

No. Five was the average Ohno ran into, not a rule. Count your evidence, not your questions.

What if there are several causes?

Then there are several causes. Branch, work out each branch, and mark more than one root cause if that is what you found. Most incidents of any size have two or three.

Who should be in the room?

Someone who does the work, someone who knows the process, and someone who asks the questions without filling in the answers. A manager is fine as long as it is clear that nobody is looking for a culprit; if that is not clear, you will get tidy answers rather than true ones.

Is this the same as a postmortem?

A postmortem is the meeting; 5 Whys is one of the techniques you use inside it. They go together well, provided the postmortem is set up to be blameless.

How do I know I have gone far enough?

Ask yourself two questions. Can I remove this cause with the means I have? And if I remove it, does the problem actually disappear, or only this one appearance of it? If both answers are yes, you are there.