To do a 5 Whys, write a one-sentence problem statement backed by measurement, then ask why it happened. Answer with a fact you have checked at the process, not a guess, and ask why again of that answer. Stop when you reach a cause in your process or system that you can change and that, once removed, would stop the problem. That usually takes three to six whys, not exactly five. Read the chain backward with “therefore” to test it, then fix the cause and prove the fix worked with data.
By Coplain Team
Last updated
Step by step
Write a precise problem statement — state what is wrong, on which part or process, where and when it was found, and how much, using measured values. “Bore oversize” is too vague. “Bore measured 12.021 to 12.024 mm against 12.000 +0.018/0 mm on 3 of 40 parts, found at final inspection on second shift” gives the team something to test against.
Contain the problem first — segregate suspect product and record it on an NCR before you start the analysis. The nonconformance report example shows the level of detail to aim for. Root cause work takes time, and the customer should not wait for it.
Bring the right people to the process — include the operator, the setter or maintenance technician and a quality engineer, and do the analysis where the work happens. People who run the process know which answers are plausible, and the floor lets you check each one.
Ask why and verify each answer — write each answer as a fact, then check it: measure the part, look at the gauge, read the setup sheet, pull the record. If you cannot verify an answer, mark it as a hypothesis and test it before you build on it. The 5 Why template has a column for the evidence behind each step.
Run a second chain for detection — ask why the problem happened, and separately why it was not caught sooner. The occurrence chain fixes the process. The detection chain fixes the inspection or gauging that let it travel.
Stop at a cause you can control — stop when the answer is a process, method or system condition that you can change, such as a missing standard, an unclear procedure or an uncontrolled tool. If the chain ends at a person (“operator was careless”), ask why the process allowed that.
Test the chain backward — read from the root cause up to the problem using “therefore”. Each link should follow logically. If a link only works with “and maybe”, the chain has a gap, or the problem has more than one cause and needs a fishbone diagram.
Fix, verify and standardize — act on the root cause, not the symptom, and record the action in your CAPA form. Then verify with data that the problem is gone and update the work instruction so the fix survives a shift change.
Where the method comes from
The 5 Whys came out of the Toyota Production System. In his book on the system, Taiichi Ohno presents the habit of asking why repeatedly as central to how Toyota attacked problems: each repetition gets closer to the real cause and makes the right countermeasure more obvious. The number five is a rule of thumb. Some problems resolve in three whys and some take six.
ISO 9001 clause 10.2 asks you to determine the causes of a nonconformity before you take corrective action, and IATF 16949 expects a documented problem-solving method. The 5 Whys is one of the simplest ways to meet that, and it fits inside larger methods. It is the root cause step of many 8D reports, and 8D vs A3 covers how to pick the wrapper.
When 5 Whys is the wrong tool
The method follows one thread. It works well when one cause is likely and the team can check each answer at the process. It works badly when several causes interact, such as a defect that only appears with one material lot on one machine at high ambient temperature. In that case start with a fishbone to lay out the candidates, test them with data, and run a 5 Why on each cause the data supports.
It is also weak when nobody on the team knows the process. The chain ends where the team’s knowledge ends, which is why going to the floor matters more than the form.
Root causes that keep coming back
Many chains, followed honestly, end in documentation: a setup step that was never written down, a work instruction that does not match the job, or a standard that changed without the floor being told. Why manufacturing NCRs trace back to poor work instructions looks at that pattern. If your chains keep ending at “retrain the operator”, look at the instruction the operator was trained on.
Track each corrective action to closure in a corrective action log, and treat a repeat of the same problem as evidence that the chain stopped too early. The CAPA guide covers effectiveness checks in more depth.
Worked examples
Example: Oversize bores on a CNC lathe (fictional). Requirement: bore 12.000 +0.018/0 mm. Problem: 3 of 40 parts measured 12.021 to 12.024 mm on the CMM at final inspection, second shift.
Why 1: Why were the bores oversize? The operator had opened the boring tool’s wear offset during the shift. Evidence: offset history on the control.
Why 2: Why was the offset opened? The in-process bore gauge read 11.998 to 12.004 mm, so the operator adjusted toward mid-tolerance. Evidence: in-process check sheet.
Why 3: Why did the gauge read low? It had been zeroed on a 12.020 mm setting ring instead of the 12.000 mm ring, so every reading was 0.020 mm low. A reading of 12.003 meant a true bore of 12.003 + 0.020 = 12.023 mm, which matches the CMM.
Why 4: Why was the wrong ring used? Both rings sit in the same unlabeled drawer at the cell and look identical. Evidence: walk-through of the cell.
Why 5: Why are they unlabeled and stored together? When the 12.020 mm ring was added for another part, nobody assigned it a location or added the ring ID to either setup sheet. Root cause: the process for introducing a gauge does not include point-of-use storage and setup sheet updates.
Detection chain: the CMM check happens only at final inspection, so the error ran for a full shift. Action: add a first-piece CMM check after every gauge zeroing.
Backward test: no gauge introduction step, therefore no location or ID, therefore the wrong ring was picked, therefore the gauge read 0.020 mm low, therefore the offset was opened, therefore the bores were oversize. Every link holds.
Verification: after labeled storage, ring IDs on both setup sheets and the first-piece check, 30 bores measured mean 12.009 mm, s 0.0022 mm. Cpk = min(12.018 − 12.009, 12.009 − 12.000) ÷ (3 × 0.0022) = 0.009 ÷ 0.0066 = 1.36.
Result: The fix targets the gauge introduction process, not the operator, so it also protects every other part that runs in the cell. The verification shows a centered process with Cpk 1.36. Run the same check in the process capability calculator, then close the CAPA only after the next few lots confirm it.
Common mistakes
Stopping at “operator error”. Ask why the process let the error happen or go unnoticed: a missing standard, a confusing layout, no error-proofing.
Answering with opinions instead of facts. Verify every answer at the process with a measurement, a record or an observation before asking the next why.
A vague problem statement. Include the part, the requirement, the measured values and where it was found. A vague start produces a vague chain.
Forcing exactly five whys. Stop when you reach a controllable cause. Three can be enough, and some chains need six or seven.
Ignoring detection. Run a second chain for why the problem escaped, so the fix also tightens inspection or gauging.
Closing the action without evidence. Collect data after the fix and compare it with the requirement before closing the CAPA.
Frequently asked questions
Do you always have to ask why exactly five times?
No. Five is a guide. Stop when the answer is a cause you can change that would stop the problem from recurring, whether that takes three whys or seven.
Who should take part in a 5 Whys?
The people closest to the work: the operator, the setter or technician, and someone from quality or engineering who can pull records. A facilitator keeps the chain factual and stops blame.
What is the difference between 5 Whys and a fishbone diagram?
A fishbone lays out many possible causes by category so you can test them. The 5 Whys follows one cause down to its root. Teams often use the fishbone first, then a 5 Why on each cause the data supports.
Is 5 Whys acceptable for ISO 9001 or IATF 16949 corrective action?
Yes, neither standard mandates a specific method. Auditors look for a verified cause and evidence that the action worked, so record the evidence behind each answer.
What if the chain splits into two causes?
Follow both branches. Each branch gets its own chain and its own action, and the backward “therefore” test is done for each.
Sources
Toyota Production System: Beyond Large-Scale Production, Taiichi Ohno, Productivity Press
ISO 9001:2015 Quality management systems — Requirements (clause 10.2), ISO
CQI-20 Effective Problem Solving Practitioner’s Guide, AIAG
IATF 16949:2016 Automotive quality management system standard, IATF