Use 5 Whys when you need to deepen a bounded causal question. Use a fishbone diagram when you need to explore several plausible contributors before choosing where to investigate. Combine them only when both jobs are necessary. If the problem or its records are unclear, pause the analysis rather than filling the gaps with guesses.
A founder says the delays are a training problem. Operations suspects missing information. Finance points to approval rules. Asking “why?” repeatedly about training would give the first explanation an undeserved head start. A fishbone can keep the competing possibilities visible.
In another case, the team already knows exactly where an item stopped. A broad workshop may add little. The useful next question is why that particular condition arose.
Before arranging the discussion, decide which of those situations you are in.
Quick answer: 5 Whys vs fishbone diagram
5 Whys organizes successive questions about a possible cause. A fishbone, also called an Ishikawa or cause-and-effect diagram, organizes possible contributors around a defined problem. Both help structure inquiry; neither establishes that a suggested cause actually occurred.
| Comparison | 5 Whys | Fishbone diagram |
|---|---|---|
| Main job | Deepen a specific line of inquiry. | Broaden the possible explanations before narrowing. |
| Starting input | A bounded problem and a question grounded in what is known. | A bounded problem plus knowledge of different parts of the work. |
| Shape | Successive why questions; branch when answers genuinely diverge. | Contributor categories with smaller branches for possible reasons. |
| Useful output | A more specific causal question or provisional explanation. | An organized field of hypotheses and gaps. |
| Main risk | Following the first convincing story and overlooking alternatives. | Collecting suggestions without distinguishing evidence from speculation. |
| Effort | Can start as a focused discussion; records may still take time to obtain. | More preparation when knowledge is distributed across roles. |
This page helps you choose the aid. For the full investigation, including how to assess a proposed cause, use How to Find the Root Cause of a Business Process Problem. Choosing a method and accepting a finding are separate decisions.
Which tool fits the question you have now?
Choose according to the present information gap: depth, breadth, or missing facts. The apparent size of the problem is a poor substitute for that distinction.
The following is a practical selection aid, not a validated scoring model or a rule requiring a particular meeting length.
| What is true now? | Start with | Why it fits | Change course when |
|---|---|---|---|
| A specific condition is documented, and the unanswered question is why it arose. | 5 Whys | Keeps attention on that bounded question. | Credible independent contributors appear or the answers become unsupported. |
| Several parts of the process could contribute, and different people hold relevant knowledge. | Fishbone | Makes those possibilities visible together. | A particular branch needs deeper inquiry, or missing records prevent useful progress. |
| A fishbone has already exposed one promising, evidence-informed branch. | Focused why questioning on that branch | Adds depth without repeating the broad discussion. | The branch splits into distinct explanations that cannot honestly share one chain. |
| The team cannot agree on what failed, or cannot access the relevant cases. | Neither yet | A template would organize assumptions. | The problem boundary and necessary observations become available. |
| The event involves serious safety, regulatory, financial, or other consequential exposure. | The authorized investigation process | Method choice must fit the required expertise and controls. | The responsible specialist determines what supporting tools are appropriate. |
One person can sketch either tool. That does not make one person’s knowledge sufficient. Invite the people who know the relevant work; do not choose fishbone merely because the meeting is large, or 5 Whys merely because only the founder is available.
If you have not yet located the part of the process under strain, begin with How to Identify Bottlenecks in a Business Process. A diagram of possible causes should not substitute for finding where the problem occurs.
What 5 Whys is good at—and where it becomes misleading
5 Whys is useful for making a vague explanation more specific through successive questions. Each question follows the previous answer rather than starting an unrelated list of complaints.
Consider an invented service-business example. A reviewed onboarding case shows that the access request was left in an unassigned queue. The team wants to understand why no assignment occurred. A focused inquiry might ask why that request lacked an assignee, then why the relevant assignment rule did not cover that request type.
The assignment administrator can check which rule applied to that request. Until the rule has been inspected, “the rule missed it” remains a possibility, and the discussion has reached a useful stopping point for gathering information.
This method is attractive when the team can follow one question without concealing other plausible explanations. It becomes misleading when every answer is selected to support the founder’s opening diagnosis. A chain that ends in “people need to care more” has probably become a judgment about people rather than an explanation of the work.
There is no requirement to ask exactly five questions. The inquiry can also branch: an unassigned request might reflect a rule gap, an incorrect request category, or both. Keep those questions separate so each can be followed with the appropriate colleague.
What a fishbone adds to the discussion
A fishbone gives different possible contributors a shared visual home. The problem sits at the head; the main branches organize areas to consider; smaller branches hold specific suggestions.
For a service workflow, useful categories might be inputs, assignment rules, system behavior, and working conditions. Choose headings the team recognizes in its own work, adapting the familiar manufacturing categories where useful.
Now change the hypothetical onboarding situation. The team has reports of delayed access across several request types. The service desk mentions incomplete information; a manager mentions approval delays; an administrator mentions assignment behavior. There is enough context to explore several possibilities, but no justified reason to make one the whole story.
Fishbone is the better starting aid here because the immediate job is breadth. Each role can place its proposed contributor without having to accept another role’s explanation first. A bare entry such as “communication” needs a more specific question, such as whether the request reached the person authorized to approve it.
A crowded branch may simply represent the area the attendees know best. Blank branches can mean “not relevant,” “not discussed,” or “we lack the right person.” Mark the difference and leave room for the absent colleague’s contribution. Branches can remain uneven.
When should you combine or switch methods?
Combine the tools when a broad view has produced a question worth deepening. Switch when the present format starts hiding information: a why-chain conceals independent contributors, or a fishbone leaves a specific question too shallow.
In the second onboarding situation, the fishbone might expose assignment rules as one branch worth examining. A focused why discussion can then explore that branch. The other branches stay visible as unresolved possibilities; choosing where to look first does not clear them.
The reverse is also useful. In the first situation, a short why inquiry might reveal that request classification, approval availability, and assignment behavior could each matter. Widening into a fishbone is reasonable if seeing those possibilities together will help. Starting again from an empty template would discard useful work; carry the questions forward.
NHS England and NHS Improvement, in Using five whys to review a simple problem, describes fewer or more than five questions and the use of why questioning to deepen inputs from a fishbone. It also warns that 5 Whys is not suitable as a key technique for a systems-based patient-safety investigation arising from a complex system. This is healthcare guidance, not evidence that either tool is sufficient for a business investigation or that the examples here are proven outcomes.
The practical boundary is important: a more consequential problem does not automatically become safe to investigate because you chose the larger diagram. Follow the authorized process and involve the necessary expertise.
Write down the method choice
Before opening a template, write a short note that makes the choice inspectable. It can live beside the existing problem record; it does not require new software.
Problem already defined: Which observed failure are we examining?
Current knowledge: What do we know, and whose knowledge or records are missing?
Starting aid: 5 Whys, fishbone, a selective combination, or neither yet.
Reason: What will this format help us see, and why is the alternative less useful now?
Switch or pause condition: What would make us change the approach?
Next evidence question and owner: What must be checked, and who will obtain or review it?
For the first hypothetical onboarding case, that note might say: “Start with 5 Whys on the unassigned request. The immediate condition is documented; the assignment behavior is not yet understood. Include the request handler and assignment administrator. Widen if independent contributors emerge. Pause if the historical configuration cannot be recovered. The administrator will check which rule applied.”
Another operator can now see why the team chose a focused discussion, which information the administrator will bring back, and when a wider conversation would be useful.
When the obstacle is unreliable definitions or absent observations, How to Measure a Business Process provides the upstream starting point. Neither drawing technique can manufacture the missing facts.
If this exercise exposes broader friction in ownership or information flow, Download the Operational Drag Diagnostic Kit. The method-choice note is usable on its own.
Frequently asked questions
Is an Ishikawa diagram different from a fishbone diagram?
No. Ishikawa, fishbone, and cause-and-effect diagram are names for the same tool.
Does 5 Whys always identify one root cause?
No. Successive questions can reveal several contributing conditions or leave the cause unresolved. A form with space for one final answer should not force the evidence into one explanation.
Can a small team use a fishbone without a workshop?
Yes. Someone can sketch the categories and collect relevant colleagues’ input asynchronously. An administrator might annotate system behavior while the service desk adds what it sees at intake. Identify whose input is still missing before the team chooses a branch to explore.
What if the team keeps voting for the same explanation?
Voting can choose a question to examine first; it cannot establish a cause. If authority or familiarity is driving the choice, ask what relevant information is missing before spending more time extending that branch.
Do we need dedicated root cause analysis software?
Not for the choice described here. Paper or an existing shared document can hold the questions and their references. Consider software only if there is a real need to manage access, evidence links, versions, or many investigations. A paid template will not resolve uncertainty for you.
Bring the method-choice note to the next discussion so colleagues can challenge the starting point before extending it.
If conflicting records or unclear ownership prevent teams from agreeing how to examine the work, Book a SYSIPHANY discovery call to discuss the operating coordination problem. Specialist safety or regulatory investigations remain with the appropriately authorized experts.