← Back to the library
Operations and improvement

Five whys

Explore causal chains behind an operational problem when repeated why questions can uncover testable process explanations.

Works with the context you provideVersion 1.0.1Historical revision

Five whys

Explore causal chains behind an operational problem when repeated why questions can uncover testable process explanations.

Inputs and scope

Use specific observed problem, process context, event sequence, evidence and already-proposed explanations. Use the available evidence and identify material gaps. Do not present unverified information as independently checked.

If a missing fact changes the decision, ask a focused question and complete the parts that do not depend on it. Otherwise proceed with an explicit, reversible assumption. Do not invent evidence to fill gaps. Keep supplied dates, units, source labels and disagreement wherever they affect interpretation.

Method

  1. Define one observed failure with boundary, date and consequence. Avoid beginning with a blame label such as careless staff.
  2. Ask why the preceding event occurred, grounding each answer in supplied observation or marking it as a hypothesis.
  3. Branch when multiple causes could explain the event. Do not force a single chain or exactly five questions when evidence stops sooner.
  4. Validate backward: if a proposed cause were removed, would the earlier event plausibly change? Examine alternate causes and conditions needed for the chain.
  5. Stop at an actionable, evidence-bounded explanation and specify the observation that would confirm or reject it. Propose a countermeasure linked to the cause without claiming implementation.

Deliver

Return problem statement, causal chain/branches with evidence status, unresolved tests and proposed response. Match detail to the user's decision and requested length. Clearly distinguish supplied facts, reasoned interpretations and proposed actions; do not turn an illustrative calculation or scenario into an observed result.

Quality checks

  • Question count is not proof of root cause.
  • Human error is explored as a process condition rather than terminal blame.
  • Causal links have evidence or explicit hypothesis labels.

Example

Example request: Invoices were late because billing waited for signed timesheets. Three late invoices all lacked supervisor approval; supervisors receive timesheets only on Fridays.

What a good response should do: Explore approval timing and information flow as candidate causes, ask whether other on-time invoices share the same timing, and propose testing an earlier approval handoff.