# 5 Whys: An Example for Tracing Causes Without Inventing Certainty Five Whys: example, method, and limits for tracing causes without forcing one root cause or confusing a hypothesis with proof. - Canonical URL: https://www.harmate.com/en/blog/5-whys-an-example-for-tracing-causes-without-inventing-certainty - Author: Harmate Team - Published: 2026-09-24 - Updated: 2026-09-24T00:42:15.155006+00:00 - Language: en ## Content # 5 Whys: An Example for Tracing Causes Without Inventing Certainty The Five Whys method starts with a factual problem and asks “why?” to move toward conditions that can be checked and improved. Five is a memorable prompt, not a stopping rule. A problem may have several branches, contributing causes, or an answer that remains unknown. The [Canada School of Public Service guide](https://www.csps-efpc.gc.ca/video/five-whys-fra.aspx) presents Five Whys as a questioning technique. The [Institute for Healthcare Improvement](https://www.ihi.org/library/tools/5-whys-finding-root-cause) notes that an analysis can lead to several root causes and different responses from different people. The method helps formulate hypotheses; it does not detect a root cause by itself. ## Start with an observable problem Avoid “the team lacks discipline” or “the project is poorly managed.” Those are already judgments. Describe instead: - what happened; - when and where; - the gap between what was planned and observed; - the people or steps involved; - the decision the analysis should inform. Example: “The client meeting summary was sent three days after the announced date, on June 17 instead of June 14.” This can be checked against a calendar, send history, and the document. It does not yet claim to know why the delay happened. Before the first question, list available facts and what is missing. A short timeline is safer than a story rewritten after the event. Record the source of each fact: project log, message, document, observation, or someone’s statement. ## A simple worksheet for every why Do not keep only the final chain. Use a working table: | Step | Provisional answer | Evidence available | Missing | Test or action | |---|---|---|---|---| | Problem | Summary sent June 17 instead of June 14 | Message timestamp | Check announced date | Rebuild the timeline | | Why 1 | Validation was unfinished | Commented document | Who had to validate? | Check requests and reminders | | Why 2 | Two different conditions appear | History and client message | Test their relative effect | Examine two branches | Keep the answer provisional until a source supports it. The missing-evidence column prevents a documentation gap from becoming certainty. The last column gives the analysis a useful output: a check, experiment, or bounded action. ## Complete example: a delivery delay with two branches The factual problem is: “The client meeting summary from June 14 was sent on June 17.” The team starts a Five Whys review during a retrospective. ### Branch A: content validation **Why was the summary sent on June 17?** Because the version planned for June 14 had not been approved. **Why was approval unfinished?** Because two passages contained figures that were still under discussion. **Why were the figures still under discussion?** Because the data source was not identified in the first version. **Why was the source not identified?** The summary instructions did not require that level of traceability. **Why did the instructions not require it?** The team reused an old template designed for internal meetings. This branch suggests an action: adapt the template and test, across the next two meetings, whether every disputed figure has a source. It does not prove that the template was the only cause. ### Branch B: people’s availability The same problem may also be explained this way: approval was unfinished because the designated reviewer was unavailable from June 14 to June 16. **Why did that unavailability block sending?** No substitute had been designated for the approval. **Why was no substitute designated?** The approval role depended on one person rather than a documented step. This branch has fewer answers, but it is not less important. It creates another testable hypothesis. Check the calendar, the approval rule, and previous cases. The evidence is still incomplete: the reviewer’s absence may have delayed the document, or it may have been incidental. ### What the example cannot conclude Both branches may be true. A third condition may also exist: the announced date was not visible to the people preparing the summary. Do not choose a branch because it produces the neatest story. Possible tests include comparing the last three summaries, checking timestamps, asking the reviewer to describe the approval path, and testing the revised template. If the delay improves, that supports the action; it does not prove that every cause has disappeared. ## When should you stop? Stop a branch when the hypothesis is precise enough to trigger a check or action, when the answer becomes a design decision, or when available data cannot take you further. In the last case, write “evidence missing” and define how to obtain it. Do not stop merely because you have written five lines. Do not continue toward an abstract cause such as “company culture” when no observation can test it. A useful endpoint sounds like “check that a substitute is assigned for the next two approvals,” not “improve communication.” ## Five Whys and a fishbone diagram: different jobs Five Whys deepens one chain or branch. The [fishbone diagram](/en/blog/fishbone-diagram-5m-method-example-and-hypotheses-to-test) maps several families of possible causes before a path is selected. Use a fishbone when the problem is broad or several families—method, equipment, environment, people, measurement—need exploration. Use Five Whys when you have a specific event and a path to examine. Do not turn a Five Whys chain into a miniature fishbone. The first deepens; the second broadens the field of hypotheses. Both require evidence and a human decision. ## Errors that manufacture a false cause ### Blaming a person “Why did Paul forget?” closes the analysis around an individual. Ask what step, information, or constraint made the omission possible. The goal is to improve a situation, not produce a culprit. ### Replacing evidence with a plausible explanation An answer that sounds right is still a hypothesis. Look for the document, calendar, usage trace, or testimony that can support or contradict it. ### Confusing frequency with causality A frequently mentioned cause deserves examination, but frequency does not prove effect. A minority branch may reveal an important condition. ### Forcing one answer Differences between participants are useful. Record who describes which branch, in what context, and what is still missing for comparison. ## Prepare questions and evidence Open questions help people describe the sequence: “What happened next?”, “What information was missing?”, “What other explanation did you consider?” They do not replace available traces. [Open-Ended Questions: Get Actionable Data Without Bias](/en/blog/open-ended-questions-get-actionable-data-without-bias) helps avoid wording that already imposes a cause. [Actionable Questionnaires](/en/blog/actionable-questionnaires-start-with-the-decision-not-the-questions) also connects each question to a decision. In remote collection, Harmate can help import responses, retain explanations, and organize themes, contradictions, and sources useful to the analysis. It does not infer a root cause, replace domain expertise, or turn a response chain into an automatic diagnosis. An accountable person must check each link and decide the test or action. Five Whys is useful when it stays modest: start with a fact, open branches, document what is missing, test a hypothesis, and keep uncertainty visible. Five helps start the conversation. It never replaces checking what the situation actually supports.