You have finished a fishbone diagram. The team has listed possible causes under headings such as people, process, equipment, and materials. Now you need to decide what to investigate and what to change.
Start by checking the evidence behind the possible causes. Then use 5 Whys to investigate a specific, supported line of inquiry. Test a change that addresses what you find, and monitor whether the problem improves.
A completed diagram gives you a useful investigation map. The ideas on its branches still need checking.
What a fishbone diagram tells you
A fishbone diagram helps a team organize possible causes of a problem. ASQ describes it as a way to sort ideas into useful categories and structure brainstorming. Its procedure also allows deeper questions to appear as smaller branches. ASQ: Fishbone
That means you may already have started asking “why” while drawing the diagram. You do not need to restart the investigation or copy everything onto another worksheet.
The next task is to separate three things:
- Observations: What happened, according to records or direct observation.
- Hypotheses: Explanations that could account for those observations.
- Evidence gaps: What you still need to check before accepting an explanation.
For example, “the label printer stopped twice” is an observation if the logs confirm it. “Printer failures caused our late dispatches” is a hypothesis until you connect those failures to the affected orders.
1. Make the problem specific
Before choosing a branch, check the problem written at the head of your fishbone.
“Dispatch is unreliable” leaves too much open to interpretation. A more useful statement describes the expected result, the actual result, and the period being examined.
Consider this fictional example:
During ten working days, 18 of 120 orders scheduled for the afternoon collection were not ready by the 4 p.m. cutoff.
The team’s fishbone includes:
- Missing delivery details.
- Label-printer faults.
- Stock discrepancies.
- Packing queues.
- Unclear handovers.
These are starting points. The example does not yet establish which ones caused the delays.
2. Check which branches deserve investigation
Review the affected orders and compare them with orders that were ready on time. Look at timestamps, exception records, equipment logs, and what people actually do during dispatch.
In our fictional example, the records show:
- Twelve late orders had label-rejection messages for missing delivery details.
- Their labels were generated only after someone obtained those details.
- The recorded printer faults occurred at different times.
- Six late orders did not have the missing-details issue.
The missing-details branch now deserves closer investigation. The printer branch has less support for these particular cases. The other six delays remain open.
Do not choose a branch simply because it received the most votes or fits someone’s preferred explanation. Consider the evidence, the impact of the problem, and the consequences of leaving a possible cause unresolved.
This narrowing step matters. Lean Enterprise Institute advises understanding the work, collecting facts, and identifying patterns before starting a detailed 5 Whys investigation. Lean Enterprise Institute: Clarifying the 5 Whys Problem-Solving Method
3. Use 5 Whys on the specific problem
Instead of asking “Why are dispatches late?” again, start with the narrower finding:
Why did these twelve orders reach dispatch without the delivery details needed to produce their labels?
ASQ explicitly describes using 5 Whys alongside a cause-and-effect diagram. Each answer becomes something to investigate more deeply. ASQ: Five Whys and Five Hows
Here is how the fictional investigation could develop.
Why 1: Why were the twelve orders not ready by the cutoff?
The team was waiting for missing delivery details before it could produce shipping labels.
Evidence: Label-rejection messages, correction timestamps, and dispatch records support this sequence.
Why 2: Why were those details still missing at dispatch?
The orders entered the packing queue without a completeness check for the affected delivery service.
Evidence: A walkthrough of the workflow and the order histories show no earlier check.
Why 3: Why did the workflow allow incomplete orders through?
The order-entry form allowed the relevant field to remain blank, even though the label system required it for that service.
Evidence: The field settings and a controlled test reproduce the mismatch.
Why 4: Why were the two systems’ requirements different?
The team suspects that a carrier-requirement change was applied to label generation but not to order entry.
Status: Hypothesis. Review the carrier notice, change records, and implementation decisions before accepting this explanation.
The fourth answer is deliberately unfinished. A plausible story should stay marked as a hypothesis until it has adequate support.
The verified form mismatch already provides a specific condition to address. Understanding how the mismatch arose may also reveal how to prevent similar problems during future changes.
4. Check the chain, including its limits
Read the proposed explanation forward:
The form permits missing information. Those orders reach dispatch. Label generation rejects them. Corrections take time. Some orders miss the cutoff.
Does each connection match the records? Were there incomplete orders that still dispatched on time? If so, what was different? Did missing details combine with a late packing finish or slow response from another team?
A single chain can hide contributing conditions. Keep the other fishbone branches available and create separate lines of inquiry where the evidence supports them. Complex problems can have more than one root cause. ASQ: Problem Solving
In this example, the analysis still does not explain the other six late orders. Fixing one cause should not close their investigation.
Do you have to ask exactly five whys?
No. Both ASQ and Lean Enterprise Institute explain that the number can vary. The aim is to understand the cause-and-effect relationship, rather than fill five spaces. ASQ: Five Whys and Five Hows, Lean Enterprise Institute: 5 Whys
Pause when the next answer would be a guess and collect evidence. Avoid stopping at labels such as “human error” without examining the conditions behind the action.
You also do not need to keep asking increasingly broad questions after you have identified a supported cause and a practical way to address it. Keep the investigation connected to the problem you defined. Lean Enterprise Institute: How Many Whys Should I Ask?
5. Test a change linked to the evidence
For the dispatch example, a proposed change is to check the required delivery details before an order enters packing.
The test should answer a specific question:
Does checking this information earlier reduce label-related delays without creating an excessive order-entry backlog?
A practical test plan could include:
- Scope: One delivery service and a defined set of orders.
- Change: Validate the required field before release to packing, with a clear route for genuine exceptions.
- Owner: A named person responsible for implementing and reviewing the test.
- Measures: Missing-detail label rejections, late dispatches, and time spent resolving incomplete orders.
- Comparison: The same measures before the change, accounting for differences in volume and order mix.
- Review: An agreed date and enough relevant orders to give the test a useful opportunity to expose problems.
ASQ recommends testing a chosen solution on a small scale where possible and watching for unintended consequences. ASQ: Problem Solving
An improvement during the test supports the proposed explanation. A quiet day alone is not enough to establish that the issue has been resolved.
6. Monitor the result and keep unresolved causes open
Track both the specific failure mode and the original problem.
For this example, that means monitoring:
- Orders rejected at label generation for missing details.
- Orders ready by their scheduled cutoff.
- Orders held earlier in the process.
- Delays caused by other issues.
Use rates as well as counts when order volumes change. Six late orders out of 60 tells a different story from six out of 600.
If the change works consistently, update the workflow and assign responsibility for maintaining it. If it does not, check whether the change was applied correctly and whether the original explanation needs revision.
Continue investigating the remaining delays. A reduction in one failure mode is useful progress, even when other causes remain.
Your next step after the fishbone
Choose one specific branch, write down what you know, and identify what you need to verify. Use 5 Whys to deepen that investigation, then connect the findings to a test and a measurable result.
For a printable starting point, the $9 Seven Quality Tools Worksheets pack includes a fishbone worksheet for organizing possible causes. Record your follow-on 5 Whys questions, evidence, and actions alongside it.
For a broader guide to selecting and combining methods, explore Root Cause Analysis Tools.