How to Run a 5 Whys Analysis: Blame-Free Questions and an Office Error Example

What Is a 5 Whys Analysis? 3 Basics to Know

A 5 Whys analysis asks "why?" repeatedly about a problem that happened, to find the root cause: the part of the system you need to change so the same problem never happens again. The goal is to dig past surface reasons like one person's lack of skill and reach causes in the process or the system.

Definition and origin: "five" is a guideline

The method is usually traced to the Toyota Production System and its habit of "asking why five times." But five is only a guideline. Rather than hitting a set count, you stop when you've reached a step or system you can actually act on.

Separate the symptom from the cause

"An invoice arrived at the wrong company" is a symptom, and you can't fix a symptom directly. A 5 Whys analysis starts by writing down the symptom as a fact, then digs into the steps and systems that produced it.

5 Whys vs. the fishbone diagram

The fishbone diagram (also called the Ishikawa diagram, after Kaoru Ishikawa, who devised it) spreads out possible causes broadly under headings like people, machines, materials, and methods. 5 Whys digs deep along a single line. When you have no idea where the cause lies, widen the search with a fishbone diagram first, then dig into the one or two strongest candidates with 5 Whys.

Minami

Process improvement lead

Last time we did one, I ended up having to write "I failed to double-check." It was basically an apology letter...

Spark

DrillSpark consultant

That happened because the questions were aimed at a person. In this article, let's walk through how to aim them at steps and systems instead.

A 5 Whys Example for an Office Error: Invoices Sent to the Wrong Customer, Five Whys Deep

Even with office errors, if you pin down the step on a process flowchart before digging, you reach a fixable cause — "invoices and address labels are printed separately and paired by hand" — instead of "the person in charge was careless."

Say a building maintenance company with 30 employees mails about 120 invoices at the end of every month (a fictional example). In the end-of-October mailing, the invoice for Company A arrived in an envelope addressed to Company B, and Company B called to let them know. It's the third misdirected mailing of this kind in the past six months.

First, find the step on a process flowchart

Before interviewing anyone, map the flow up to mailing and mark the step where the error happened. Starting from "which step did it happen in" rather than "who made the mistake" naturally points your questions at the system.

A five-level 5 Whys: filled-in example

Start from the step you marked on the diagram and keep asking "why." The trick is to write "how we confirmed it" next to each answer. Once a guess slips in, every "why" after it becomes a guess too.

In this example, the causes to act on are the "procedure of hand-matching two printouts sorted in different orders" revealed in Why 2–4, and the "lack of a procedure for reviewing the steps when a system changes" from Why 5. Both would remain even if you replaced the person doing the work.

How it differs from an analysis that stops at a person

Ask about the same incident with the questions aimed at a person, and it stops after two levels:

• Why 1: The person in charge failed to check the address
• Why 2: The person in charge wasn't paying enough attention
• Fix: Be more careful from now on

With this analysis, the procedure of hand-matching 120 pairs stays exactly as it is. Whether you swap in someone new or the same person tries as hard as they can, it will happen again sooner or later during a busy month-end.

For your own incident, start by mapping the flow of the work where it happened and marking the step. Describe the flow in words, and the AI will draft a process flowchart for you.

Minami

Process improvement lead

But it really was the person in charge who mixed them up, right?

Spark

DrillSpark consultant

True. But ask yourself: would it have happened if someone else followed the same procedure? If the answer is yes, it's the procedure that needs fixing.

How to Run a 5 Whys Analysis in 5 Steps

Work through five steps: write the problem as facts → find the step on a diagram → ask "why" about steps and systems → trace back with "therefore" to confirm → write fixes as process changes. In the 6 steps from "How to Improve Business Processes," you use this in Step 3, when you dig into the causes of the problems you've listed.

Step 1: Write the problem with facts and numbers

Put "when, which document, how many, and what went wrong" into one sentence. For example: "Of about 120 invoices mailed on October 31, one reached a different customer. This is the third case in six months." Drop any wording that makes a person the subject, like "the person in charge made a mistake," at this stage.

Step 2: Mark the step on the process flowchart

If there's no diagram, have 2–3 people involved sketch one on a whiteboard or with sticky notes in about 15 minutes. It's detailed enough if you can see the step where the error happened plus two steps on either side. How to draw the diagram itself is covered in detail in "How to Map a Business Process Flow."

With DrillSpark, you describe the flow in plain language and the AI drafts a flowchart, which you can then refine in conversation. Add "ERROR POINT" to the node where it happened, and you have the starting point for your analysis.

Step 3: Ask "why" about steps and systems

Write only facts you've confirmed through interviews, observing the work, or records — no guesses. If an answer splits in two, branch and dig into each one. Tips for phrasing the questions are in the next section.

Step 4: Trace back with "therefore" to confirm

Starting from the bottom cause, read the chain aloud linked by "therefore" and check that it leads back to the problem. For the invoice example: "There was no procedure for reviewing the steps → therefore the practice of printing labels from Excel stayed on → therefore two printouts in different orders were matched by hand → therefore they got mismatched → therefore the invoice reached another company."

If any link doesn't connect, re-dig from that point. Decide where to stop by whether this reverse check holds, not by whether you reached five.

Step 5: Write fixes as process changes and update the diagram

Write each fix in terms of "which step to remove" or "where to place a check," and redraw the process flowchart as it will look after the fix. The three types of fixes are covered in detail in a later section.

Blame-Free Questions That Reach the Root Cause: 4 Rewrites

Make "which step and what" the subject of your questions instead of "who," and the answers stop getting stuck on people and move on to procedures and systems.

Change the subject of the question from a person to a step

Ask someone "why didn't you check?" and all they can offer is a defensive answer or an apology. Ask "where in the flow was the checking step?" and the answer becomes a place on the diagram, which keeps the conversation away from blame.

4 answers that stall the analysis, and how to rephrase the question

When any of the four answers below comes up, it's a sign the analysis is about to stop at a person. Rephrasing the question as in the "Rephrased question" column is what surfaced the system causes in the invoice example.

3 ground rules to keep it from becoming a blame session

Before you start, have all participants agree to these three rules.

1. Don't write individual names on the worksheet (name the department at most)
2. Write answers as confirmed facts, not guesses
3. Don't write "pay attention" or "be careful" as a fix

With the third rule in place, the discussion turns to "so how do we change the step?" when it's time to decide on fixes. Write the rules on paper at the start and post them where everyone can see; when the talk drifts back to people, you can point at them to bring it back.

Minami

Process improvement lead

What do I say if my manager goes, "Come on, it was just carelessness"?

Spark

DrillSpark consultant

Bring it back to the procedure: "Let's set it up so that even if someone slips, it gets caught before it leaves the office." You don't have to contradict them about the person, and you've shown the next move.

3 Ways to Write Prevention Measures as Process Changes

Instead of "be careful," write each prevention measure as one of three types — (1) remove the step where the error happens, (2) place a check right after the step where it happened, or (3) make it impossible to get wrong — and show where the flowchart changes.

Type 1 tends to work best. Type 2 still relies on someone's eyes, so it suits a stopgap until Type 1 is ready. Thinking about "removing" first is the same idea as ECRS (Eliminate → Combine → Rearrange → Simplify), which is covered in "What Is ECRS?"

Type 1: Remove the step where the error happens

If invoices are printed with the address and go into window envelopes, the label printing step and the hand-matching step disappear, and the address and contents can no longer be mismatched. Check the invoice layout settings to see whether your accounting software can print the address on the invoice.

Type 2: Place a check right after the step where it happened

Just before stuffing each envelope, match the customer code on the invoice against the label. The closer a check is to the step where the error happens, the better it works. Checking each pair before it goes in the envelope catches mix-ups better than a batch review at the end of the mailing.

Type 3: Make it impossible to get wrong

Set invoices and labels to print in the same customer-code order, and matching becomes simply stacking them from the top. The step remains, but the cause of the mix-ups — the different sort orders — is gone.

Write interim and permanent fixes separately

Write the interim fix that can be in place for this month's mailing (the Type 2 match) separately from the permanent fix that changes the system (the Type 1 window envelopes). For the cause found in Why 5, add "review the diagram of the steps before and after whenever a system is replaced" to the rollout checklist.

The "compare envelope count with invoice count" step in Figure 3 is a check for catching missing invoices, not a fix for mix-ups. Mismatches between address and contents no longer happen because Type 1 removed the step. If two invoices go into one envelope, the count won't match, and this check catches it.

Once the fix is in, update the process flowchart and the manual that same week. If you don't, things tend to slide back to the old way when the person in charge changes. How to put a manual in order is covered in "How to Write a Work Manual."

Minami

Process improvement lead

Isn't adding a double-check the safest option?

Spark

DrillSpark consultant

Stack checks on top of each other, and people start assuming the other person is looking, so things get missed. First see if you can remove the step. Then place one check right after the spot where the error happens.

5 Whys Report Format: 7 Fields

Give the report seven fields — title and date, problem, step where it happened, the 5 Whys, root cause, interim and permanent fixes, and how to check the results — and attach the before-and-after process flowcharts. Readers can then judge whether the fixes make sense.

The 7 fields and what to write

Don't include a field for individual names; name the department at most. If names stay on reports, the next mistake is less likely to get reported.

Attach before-and-after process flowcharts

Put the before and after diagrams side by side, like Figures 1 and 3, and readers can see at a glance which steps disappear and where a check goes in. Compared with a text-only report, the reasons for approving or sending it back become much clearer.

Decide how to check the results up front

Decide the period and what to count at the same time as the fixes, and write them in the seventh field. In the invoice example, for six months from December, when the permanent fix starts, record at each month-end the number of misdirected invoices and the number caught by the match. Compare over the same length of time as the original count (three cases in six months); if there are zero misdirected invoices for six months straight, you can judge the permanent fix effective.

5 Common 5 Whys Mistakes and How to Avoid Them

Most analyses that get called "pointless" fall into one of five traps — a vague problem, stopping at a person, a single path, fixes that are just reminders, or not updating the diagram — and every one of them can be prevented with the right procedure.

Mistake 1: Starting to dig while the problem is still vague

Start from something like "we make a lot of mailing mistakes," and each participant pictures a different incident, so the answers scatter. As in Step 1, put when, which document, and how many into one sentence before you begin.

Mistake 2: Answers stop at a person

When "carelessness," "didn't double-check," or "they were new" comes up, it's a sign the analysis is about to stall. Swap in the questions from the rewrite table and bring the conversation back to steps and systems.

Mistake 3: Digging a single path and missing other causes

If one "why" produces two answers and you only dig into one, the same mistake will come back through the cause you left behind. When you get two answers, branch. If there are too many candidates, widen the search with a fishbone diagram first, then dig.

Mistake 4: Fixes end with "be careful" or "more training"

Reminders and training alone leave the procedure unchanged, so the error comes back. Recast the fixes into the three types — remove the step, check right after, make it impossible to get wrong — and write down where the flowchart changes. Even when you add a check, rethink where it goes before stacking on double-checks.

Mistake 5: Not updating the diagram and manual after the fix

If the fix stays an informal verbal agreement, things slide back when someone new takes over a few months later. Update the diagram and manual on the day the fix starts, and check the results on the date set in the report's seventh field.

Summary: Map the Step Where It Happened, Then Ask "Why"

A 5 Whys analysis ends up as a blame session or an apology letter because the questions are aimed at people. Pin down the step on a diagram first and make "which step and what" the subject of your questions, and you'll reach the causes that remain no matter who does the work.

Write fixes as process changes, not "be careful," and attach the before-and-after diagrams to the report. Prevention isn't finished until you've updated the diagram and manual and counted the results to confirm it worked.

Start by picking one recent mistake, mapping the flow of that work, and marking the step where it happened.

Related Templates

Related Guides

FAQ