Your Training Partner
Techniques Toolbox
Vertical chain of six why/because pairs starting from 160 of 500 processed applications missing the turnaround deadline, descending to the highlighted root cause, a regulatory-watch accountability assigned to no role, then on to the corrective action.

Five Whys

The Five Whys (BABOK 10.40.3.2) trace an observed problem back to its cause by asking "why" repeatedly, each question aimed at the answer just given. The chain stops when it reaches a condition the organisation can fix directly, and the number five is an empirical observation: it often takes five questions to get there, sometimes three, sometimes eight. It is one of the two elements BABOK groups under root cause analysis, alongside the fishbone diagram, and the simpler of the two to run whenever a problem has a human component. Its value rests entirely on two disciplines: every link is tested against evidence, and the chain never stops at a person.

Purpose

The technique answers a single question: where do you fix things so the problem stops coming back. An organisation that treats the visible effect of a failure buys itself a respite and meets the same failure next quarter in a slightly different form. The Five Whys look for the origin, meaning the point where a fix removes the recurrence. BABOK sets that purpose within four activities, which shape the session as much as the deliverable: defining the problem statement, collecting data on its nature, its magnitude, its location and its timing, identifying the cause and identifying the corrective action that will prevent or limit the repeat.

The use is reactive or proactive. In reactive analysis the chain starts from a problem that has occurred and looks for where to act. In preventive analysis it starts from an area judged fragile and looks for the condition that would make it fail, ahead of the incident. Both uses are legitimate and BABOK names them both.

The deliverable is a documented causal chain: the problem statement, the sequence of why/because pairs, the evidence supporting each link, the root cause retained and the corrective action attached to that cause. It fits on one page. Its quality is judged on a single criterion: can a reader who was not in the room reconstruct the reasoning and challenge it link by link.

Usage

When to use it

  • Problem with a human or execution component: BABOK places the technique's strength here explicitly.
  • A single plausible causal chain: one failure mode explains the observed effect.
  • Fast triage ahead of a heavy investigation: a one-hour session steers the enquiry without committing to it.
  • Recurring defect despite repeated fixes: a sign the fixes are landing on the effect.
  • A fishbone branch to dig into: the brainstorm produced categories, the chain deepens one of them.
  • Service commitment missed repeatedly: turnaround time, error rate, rework, wherever the measure already exists.
  • Fragile area to probe before the incident: the proactive use, allowed by BABOK, looks for the condition that would make it give way.

When not to use it

  • Multi-causal problem: a single chain hides the other factors, map the categories with the fishbone diagram (BABOK 10.40a).
  • Combinatorial failure: several conditions must coincide, use a fault tree, which carries the ANDs and the ORs.

Running the chain

The session opens with the problem statement, written where everyone can see it, on a board, a flip chart or a shared document. It carries a fact, a measure and a period: "last quarter, 160 of the 500 applications processed missed the 30-day turnaround" is a statement; "application processing is too slow" is a complaint, and a complaint produces a vague chain. The group brings together the people who run the failing process, not just their managers: the evidence for the first link is almost always in the hands of whoever does the work, and the first "why" is settled there.

Then comes the mechanism itself. You ask "why do you think this problem occurs", and the answer is written under the statement. You then ask "why" of the answer just given. That point is what separates a chain from a list. Putting the question back to the initial problem produces a set of parallel observations, all plausible, none connected to the others, and the group leaves with five hypotheses. A chain reads in both directions: downwards through "why", upwards through "therefore", and if the upward reading does not hold, a link is wrong.

Every link is backed by evidence. BABOK devotes an entire activity to data collection: an unverifiable answer is a hypothesis to test, never a link that has been earned. The evidence is a log, a count, a date, an observed fact, something that can be held up against the answer. Two checks apply when accepting a link. The first is causal: does the answer explain the effect, or merely accompany it. An answer that sounds right and an answer that is true look very much alike in a room. This is the technique's most frequent defect in the critical literature. The second is counterfactual: if this cause went away, would the effect go away. A link that fails that test accompanies the effect without producing it.

The chain stops when the answer names a condition the organisation can act on directly and one more "why" would yield nothing but an increasingly unfalsifiable generality. BABOK is clear: the number of questions varies, and the technique carries the number five because five are often needed. The two symmetrical drifts are common. You stop too early because the answer you have is comfortable, and you fix a symptom. You push too far once the cause has been found, and the chain drifts towards "because the organisation lacks a quality culture", a statement no action attaches to.

The session ends with the corrective action, attached by name to the confirmed root cause. A chain with no action is an exercise, and an action that connects to no link in the chain gives away a root cause the group never settled on. The action carries a deadline and an owner, failing which the problem returns with its chain intact.

Where the chain breaks

BABOK names two limitations of its own: the technique requires a trained facilitator, and it becomes difficult on complex problems, where the group risks following a false trail and reaching a dead end. The critical literature and practice document five more, heavier ones, and a practitioner who ignores them produces wrong root causes with great confidence.

The first is structural: the chain is single, whereas most real failures have several contributing causes. BABOK says so itself when it opens root cause analysis: more than one root cause may contribute to the effects. Every time an answer could split into two independent causes, forcing it into a single line makes one of the two disappear. That branching point is the limit of the procedure, where the fishbone diagram takes over.

The second is the knowledge ceiling. The chain stops where the room's knowledge of the domain stops. A group unaware that a portal has a validation rule set will never ask the "why" that leads there and will conclude, sincerely, on what it knows. The fix is one of group composition: bring into the room whoever owns the system at fault, plus an outside pair of eyes from beyond the department, whose ignorance of local obviousness is useful.

The third is the most damaging. The method offers no objective or reliable way to trace the causal path, and nothing establishes that two facilitators working the same problem converge on the same root cause (Card, BMJ Quality & Safety, 2017). Its spread, including among institutions that recommend it, rests on no demonstration of its effectiveness: its inter-rater reliability has never been established. The practical consequence is direct. A chain from a single session is a draft: on a decision of consequence it is rerun by a second group or set against a method that does not share its biases, before it grounds anything at all.

The fourth is confirmation bias, and the chain has no defence against it. An investigator who arrives with the conclusion already in hand builds the string of "becauses" leading to it without effort: every link justifies itself, the upward reading holds and nothing in the mechanism of the technique signals that the path was chosen before it was walked. Card lists it among the method's own defects. It concerns what the room has already decided, where the knowledge ceiling concerns what the room does not know and divergence concerns two good-faith facilitators landing elsewhere. The counterweight is procedural: write down before the session the hypothesis everyone already holds, treat it as a link to be refuted and hand the search for evidence to someone with no stake in the conclusion.

The fifth is the signature of the other four. A badly run chain ends on "human error" or "lack of training". Almost any failure can be reduced to a human decision if you stop early enough, and that ending has the advantage of being comfortable: it names a culprit, it proposes a cheap action, it closes the session. Ohno insisted on the opposite, and his canonical stopped-machine example never names the operator: it descends from the blown fuse to the overload, from the poorly lubricated bearing to the worn pump shaft and stops at a missing strainer that let the metal cuttings in. The useful cause is the systemic condition that allowed that decision to count: the field the portal did not require, the check that did not exist, the accountability nobody held. A chain that stops at an employee's name or at a need for training stopped one notch too early, and the facilitator who accepts it turns the analysis into an instrument of blame. This is where psychological safety becomes a feasibility condition: in a room where contradicting a senior costs you, nobody will ask the why that climbs above their own head, and the chain will stop at the last harmless link.

The boundary with the fishbone diagram

The two elements of root cause analysis answer two different questions. The fishbone diagram (BABOK 10.40a) goes wide: it opens up the categories of possible causes, people, processes, tools, policies, and inventories them in parallel. The Five Whys go deep: they follow a single line to its end. BABOK allows both uses: the chain can be run on its own or downstream of the diagram, to dig into a branch the brainstorm surfaced. The second order is the safer one when the cause categories are not known in advance, because it means choosing the branch while looking at it. The first is enough when a single failure mode is plausible and the room already knows where to look.

AI considerations

Two uses hold up. The first is generating candidate hypotheses: a language model brings the problem statement together with the incident history, the tickets and the logs, and returns a list of plausible "whys" the facilitator puts to the room. The value is in populating the blank page and surfacing a lead nobody would have raised, which attacks the knowledge ceiling head-on. The second is documentation: transcribing the session, then laying the chain back out across BABOK's four activities, statement, data, cause, action, frees the group from note-taking and gives that time back to the reasoning.

The limitation is specific to this technique and it is severe. The central defect of the Five Whys is accepting an answer because it sounds right, and a generative model produces precisely fluent, plausible sequences: its mode of operation is the technique's failure mode. A chain returned by a model is coherent from end to end, it reads very well and nothing in it indicates which of its links rests on real data. A hypothesis from a model therefore enters the chain on the same footing as a participant's guess: as a proposition to be confronted with evidence. Causal judgement, the counterfactual check and the decision to stop the chain on a systemic condition rather than on human error stay human. The technique produces its value at those three points.

Examples

The case is a cantonal social insurance office processing applications for supplementary benefits. In its service agreement, the office committed to a 30-day turnaround. Last quarter, of 500 applications processed, 160 missed that deadline, or 32%, and it is the third consecutive quarter. Of those 160 late files, 120 were sent back for correction because they were incomplete; the other 40 missed the deadline for other reasons, outside the scope of this chain. The chain is the session's deliverable, as it is handed over.

The why-chain, down to the root cause
Six whys were needed. Five is an average, not a countdown.
Problem statement
160 of 500 processed applications missed the 30-day deadline
third consecutive quarter
1
Bottleneck at the completeness check: 120 files sent back
2
Two mandatory documents omitted: rent certificate, spouse's income
3
The portal does not make these two documents mandatory
4
Validation rules not updated for twelve months
5
No process links a regulatory amendment to the portal backlog
6
Root cause
"Regulatory watch through to digital services": no role holds it
Corrective action
Assign the accountability; maximum delay between amendment and portal
The why-chain of a cantonal social insurance office. Each question is put to the previous answer. The chain stops at an unassigned accountability, a condition the organisation can fix. The chain has six links.

A chain on its own cannot be verified. The same deliverable therefore carries, against each link, the evidence that made it acceptable and the reason the chain did not stop there. It is that column which separates an analysis from a successful conversation.

#Question put to the previous answerAnswer retainedEvidenceWhy the chain continues
1Why did 160 of 500 applications miss the 30 days?A bottleneck forms at the completeness check: incomplete files are sent back for correction and lose the deadline.Rejection log of the case management system, past quarter: 120 of the 160 late files were sent back for correction, or 24% of the 500 applications processed. The other 40 have other causes.The bottleneck is a measured effect, the organisation cannot act on "the check is congested".
2Why does a quarter of applications arrive incomplete?Two documents that became mandatory, the rent certificate and the spouse's income, are omitted by applicants.Breakdown of rejection reasons: these two documents account for 104 of the 120 incomplete files.The omission is a behaviour, its cause lies in the submission channel.
3Why do applicants omit these two documents?The online portal does not make them mandatory: the form submits without them.Submission test on the portal, form accepted without the two documents.The portal applies a rule set, the question bears on that rule set.
4Why does the portal not require them?Its validation rules were not updated when the cantonal implementing ordinance was amended twelve months ago.Version log of the rule set: the last change predates the entry into force by seven months.An isolated oversight would be a circumstance, the repetition implies a missing mechanism.
5Why was that update never requested?No process connects a regulatory amendment to a change request on the portal: the legal service informs the processing teams, not the team holding the portal backlog.No change request logged on the date of entry into force, nor in the six months that followed.The absence of a process points to the question of who should have owned it.
6Why does that process not exist?Root cause. Accountability for "regulatory watch through to impact on digital services" is assigned to no role: it falls between the legal service and the IT unit, and neither one holds it.Job descriptions of both units: the accountability appears in neither.The chain stops: the organisation can assign a role, and one more "why" would deliver a generality about governance.
Corrective action. Assign the accountability explicitly, with a maximum delay between the entry into force of a regulatory amendment and the update of the portal's validation rules.Owner: the office's business analyst. Deadline and control measure: the incomplete-file rate, recorded quarterly.
The why-chain, with the evidence for each link and the reason not to stop. Six questions were needed: the number five is an average, not a countdown.

The chain makes the stake quantifiable, which is the second reason to document it. The office estimates internally that reworking an incomplete file costs CHF 45 of caseworker time. At 120 incomplete files a quarter, total rework comes to CHF 5'400. The corrective action removes only the share attributable to the two documents, 104 files: avoidable rework is CHF 4'680 a quarter. The remaining 16 files have other causes and will survive the fix, which is multi-causality in action, legible in the number itself. Of the 160 missed deadlines in the quarter, 104 trace back to the root cause retained, or 65%, and the balance awaits another chain. The unit cost is an internal order of magnitude rather than a published statistic, and it is enough for its purpose: it weighs the cost of fixing a validation rule set against the cost of the symptom that fix removes, before any effect of the missed deadline on the applicants themselves.

This chain also counts for where it does not stop. No link names a caseworker, no action calls for training. A chain run faster could have stopped at the second link, concluded that caseworkers were letting incomplete files through and proposed an awareness session. It would have been coherent, defensible in the room and wrong.

One problem, two facilitators, two root causes
Problem statement
160 of 500 processed applications missed the 30-day deadline
third consecutive quarter
Facilitator A, three whys
Bottleneck at the completeness check
Incomplete files pass the check
Apparent root cause
Caseworkers lack training
Stops at people: the chain ended too early.
Facilitator B, six whys, every link verified
Bottleneck at the completeness check
Two mandatory documents omitted
The portal does not require them
Validation rules never updated
No process links regulation and portal
Root cause
Accountability assigned to no role
Systemic root cause: nobody holds the accountability.
Action, facilitator A
Train the caseworkers
Action, facilitator B
Assign the role, set a deadline
One statement, two facilitators, two root causes. The short chain stops at people and proposes training. The evidence-backed chain descends to an accountability nobody holds.

Cost

PhaseLevelJustification
PreparationLowNo materials, no data to prepare. The work lies in writing a precise problem statement, with a number and a period, and in bringing in the right people, those who run the failing process.
ExecutionLow to mediumA session of 30 to 60 minutes is enough for a contained problem. The cost rises as soon as links are tested against data in the session rather than debated, and as soon as a committing decision requires the chain to be rerun with a second group, which the absence of any demonstrated convergence between facilitators makes necessary.
DocumentationLowThe deliverable is one page: the chain, its evidence, the root cause, the action. The cost only rises if the root cause turns out to be wrong and the analysis has to be redone, a real risk whose guard is backing every link with evidence.

Tooling

The technique demands nothing: a whiteboard, a flip chart, a sheet of paper. Writing the problem statement at the top and stacking the answers beneath it is the whole of the tooling required: the technique is run where the problem happens, with whatever is there.

Remotely, a digital whiteboard (Miro, Mural) or a plain shared document kept live during the call replaces the wall without losing anything: the chain has no dependency on a physical artefact, unlike a workshop technique built on sticky notes. A spreadsheet works just as well as soon as it carries the evidence column, which is the only structure the technique needs.

Specialised tooling exists and sits downstream. Incident management platforms offer post-mortem templates in which the why-chain is a structured field, and quality management software (TapRooT, Intelex, Cority) includes root cause analysis modules that impose a frame and keep an auditable trace. What they add is traceability and comparison from one analysis to the next, which matters once the chains accumulate and you need to see which one keeps coming back. Running the session stays identical: none of these tools asks the next why or verifies a piece of evidence.

Sources

  • IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.40 Root Cause Analysis: the definition, the four activities, reactive and proactive analysis, the steps of the Five Whys and the two limitations the guide names.
  • Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production, Productivity Press, 1988 (original Japanese edition, 1978): the origin of the technique and the stopped-machine example, pushed down to the missing strainer in the lubrication circuit, without any link naming an operator.
  • Lean Enterprise Institute, 5 Whys, Lean Lexicon: lean.org/lexicon-terms/5-whys. The number five is given there for what it is, an observation rather than a count.
  • Art Smalley, 5-Why Analysis, TPS Encyclopedia, Art of Lean: artoflean.com/reference/five-why. How the chain is practised at Toyota and where it sits in the A3.
  • Alan J. Card, The problem with "5 whys", BMJ Quality & Safety 2017;26:671-677: qualitysafety.bmj.com/content/26/8/671. The peer-reviewed critique: a single chain where causality is multiple, no objective means of tracing the causal path, confirmation bias and a warning against using the technique alone in safety-critical domains.
Fishbowl
All techniques
Flowchart