ISO ARTICLES NONCONFORMITY & CORRECTIVE ACTION

How to Challenge Weak Five Whys Analysis

From nonconformities to sustained corrective action and improvement.

Use neutral challenge questions, evidence checks and alternative causal pathways to turn superficial Five Whys chains into testable corrective action reasoning.

ISO Toolkits Editorial Team Corrective action and continual improvement Approx. 7 min read

Five Whys is widely used because it is accessible, not because five answers guarantee a true explanation. Weak analyses repeat the same idea with different words, jump from an event to blame, or finish at a cause that the team already wanted to treat. A strong review challenges each transition in the chain, considers branching causes and tests whether the proposed action changes the conditions that generated the event.

quality practitioners challenging a Five Whys chain
Editorial illustration: Quality practitioners challenging a Five Whys chain.

Check the starting problem statement

A chain that begins with “poor compliance” will often end in “lack of awareness,” because neither term identifies a concrete event. Establish a verifiable statement of what was wrong, what requirement applied, where it happened and when. The first why should explain an event, not a judgment about someone’s attitude.

Practical examination

For instance, “shipment S-104 was released without final approval on the night shift” creates a testable boundary. “Employees do not follow procedures” does not. Review the original source record with the people involved and distinguish the sequence of events from recollections collected afterward.

Field test. Problem test: Read the starting statement without the conclusion. If it contains allegations about employee intent or a generic claim of bad culture, rewrite it into a verifiable event.

Demand evidence for every why

Ask which document, log, observation or corroborated account supports the arrow between one answer and the next. A manager’s confidence is not a substitute for causal evidence. If the link remains uncertain, mark it as a hypothesis and plan a test instead of treating it as an accepted finding. For the underlying terminology, consult ISO 9000:2026.

Operational example

A claim that a worker was not trained may be checked against competence records and a practical demonstration, but evidence of completed training does not automatically establish capability. More importantly, it may not explain why the electronic workflow allowed an unauthorized release.

Evidence check. Evidence test: Require every arrow to have a source and a test. Where support is missing, the team should stop, gather data and leave the arrow explicitly provisional.

  • Request specific evidence for every causal link.
  • Look for alternative paths and failed detection barriers.

Find where the chain turns into blame

Weak chains commonly proceed from missed step to employee oversight to inadequate awareness. Challenge what made the mistake possible and what barrier should have caught it. Consider task design, competing objectives, timing, escalation paths, information quality and system permissions.

Evidence and control test

Use neutral questions such as “What did the person see at that decision point?” and “What would an experienced employee have done with the same information?” The goal is to improve the work system while preserving accountability for actual decisions.

Decision point. Respect test: Explore what the person knew, could see and could physically do before assuming carelessness. Process controls should be designed for predictable human limits.

Allow branches instead of forcing one line

Complex events may require more than one causal pathway. A supplier error may create the wrong part, an ineffective receiving check may fail to detect it, and a hurried changeover may let the part reach production. Compressing the event into one vertical chain hides barriers that should be independently improved.

What a reviewer should challenge

Build parallel branches for occurrence and escape or detection. Compare each branch with cases where the failure was prevented. The analysis is complete enough when relevant mechanisms are substantiated and decisions are defensible, not when the chart has exactly five rows.

Verification approach. Branch test: Diagram occurrence and escape separately. A defect may be generated in one process and released because a completely different safeguard did not operate.

a practitioner comparing alternative causes
Editorial illustration: A practitioner comparing alternative causes.

Challenge abrupt jumps to management systems

Some analyses leap from a technical fault directly to “management did not provide resources.” Others stop at “no procedure.” Both can be correct in specific circumstances but require evidence. Identify the decision, allocation or design weakness through which a management factor affected the event.

How to test the response

Trace scheduling approvals, resource constraints and performance measures if workload is cited. If the procedure exists, ask whether it was accessible and feasible. Avoid converting every problem into generic leadership language that cannot support a measurable corrective action.

Challenge question. Management test: If insufficient resources are blamed, identify the allocation decision, capacity evidence and causal connection. Avoid using leadership as a vague terminal label.

  • Make the starting problem observable and bounded.
  • Request specific evidence for every causal link.

Five Whys challenge points

  • Make the starting problem observable and bounded.
  • Request specific evidence for every causal link.
  • Look for alternative paths and failed detection barriers.
  • Test the proposed solution against the actual failure mechanism.

Test whether the action fits the cause

Read the proposed remedy backward from the last why. Would implementing the action interrupt the event if the diagnosed cause were true? Does it also address any failure in detection? Could the same problem recur by an unchanged exception route?

Audit and management application

A chain ending with an inconsistent supplier status synchronization cannot be closed by sending a training email. It calls for validated synchronization, exception handling, ownership and monitoring. Check the actual control rather than relying on a meeting record.

Operating control. Remedy test: Reverse trace each proposed action to the verified link it is meant to interrupt. A gap without a mapped action and an action without a mapped cause, both warrant challenge.

Illustrative challenge sequence

Illustrative case: The team reports, “An inspection was missed because the operator forgot; the operator forgot because training was inadequate.” The reviewer asks for shift rosters, inspection schedules and system logs. These show that the required inspection window overlaps a mandatory machine restart task during peak demand.

Illustrative decision

The analysis shifts to workload design and independence of the release safeguard. The action may rebalance responsibility and prevent release until an inspection result exists. After deployment, test high load shifts and exception cases. The reviewer records why the original awareness explanation was rejected.

Closure threshold. Scenario test: Observe the changed shift arrangement during peak operation and verify that inspection evidence precedes release. This is stronger than a signed reminder about attention.

A constructive Five Whys challenge meeting

Display the causal chain beside the actual chronology. Give participants three questions for every arrow: What supports this explanation? What else could have produced the same result? What new fact would cause us to revise the conclusion? The reviewer should document contested links as hypotheses rather than letting presentation confidence substitute for evidence.

After the meeting, ask the action owner to explain how the proposed change interrupts the verified mechanism. If an unauthorized release remained possible through a manual override, retraining staff would not provide an adequate closure rationale. Use an observed or controlled operating test to challenge the revised control, and retain the test result even when it forces another investigation cycle.

A weak Five Whys chain may name the absence of training because training records are easy to check. Challenge this by asking what a fully trained employee would have experienced under the same system state. If the interface permitted an invalid release and offered no warning, competence might reduce occurrence but not remove the enabling control gap. Record the separate role of training, configuration and detection. The final action should be tested against both the human decision and the bypass path.

It is also reasonable for a review to conclude that the chain remains incomplete. In that case, the next step is a focused evidence request rather than an arbitrarily long list of further why questions. State which proposed causal link has not been verified and what transaction, source log or operational observation would help decide it. This prevents a polished Five Whys worksheet from being treated as a substitute for investigation.

Closing Perspective

A nonconformity workflow is credible when it preserves original evidence, distinguishes immediate disposition from causal treatment, and gives management an informed choice about remaining risk. The purpose is not an impressive volume of action records; it is an operating control that can withstand realistic conditions and independent challenge.

For the next management system review, identify the live control, accountable owner, test method and trigger for reconsidering the decision. If evidence contradicts the conclusion, preserve that result and revise the action. Continued improvement requires the ability to change course without disguising the earlier failure.

Technical reference basis: ISO 9001:2026 and ISO 19011:2026. Case examples are illustrative interpretations, not direct quotations from ISO requirements.

References & Further Reading

Official ISO standard pages and professional quality resources used to ground the subject. Illustrative scenarios are editorial examples; quoted ISO clause text is not reproduced.

  1. ASQ: Five Whys and Five Hows
  2. ASQ: Root Cause Analysis: Methods and causal evidence
  3. ASQ: Problem Solving: Process and techniques
  4. ISO: ISO 19011:2026, Guidelines for auditing management systems