What to Do After a Fishbone Diagram: Decide Which Cause Deserves the Money

A completed fishbone diagram is full of branches. The next step is not to pick the cause the room agrees on. It is to test which branches rest on evidence and which are comfortable assumptions. Skip that, and the corrective actions address the wrong cause.

I watched a quality team at an automotive parts supplier complete a fishbone diagram after a run of dimensional defects on a machined housing. The diagram had twenty-three branches across the six Ms: Manpower, Method, Machine, Material, Measurement, and Mother Nature. The facilitator asked the room which cause to address first. Within ten minutes, the team had circled "operator training" under the Manpower branch. It was actionable, low-conflict, and something the plant manager could approve before the end of the week.

Six weeks later, the defects returned. A maintenance engineer who had not been in the original session pulled the tooling records and found that the cutting inserts on two CNC machines had exceeded their recommended service life by 40 per cent. The wear pattern matched the dimensional variation exactly. The fishbone had included "tooling condition" as a sub-branch under Machine, but nobody in the room had data on insert life. The team chose the cause they could act on over the cause the evidence supported.

The tool did its job. It generated branches, organised them into categories, and gave the team a visual structure for their thinking. The step that failed was not the diagram. It was what happened next: selection without verification.

1. Rewrite each branch as a testable claim. "Insufficient training" becomes "We believe the operators lack the skill to hold tolerance on this process."
2. Score each claim on influence and confidence. High influence + low confidence = the branch that needs investigation before it receives a corrective action.
3. Investigate the high-risk branches. One measurement, one record check, one conversation with the people closest to the work.
4. Assign corrective actions only to verified causes. The Walk provides a structured way to test which branches deserve resources before the corrective action plan commits them.
5. Assign ownership and a review trigger. Each corrective action gets a named owner and the condition under which the finding should be reconsidered.

After a fishbone diagram, the standard next step is prioritisation and corrective action. The step worth taking first is to test whether each branch is an assumption or something the data supports.

The standard next step: prioritise and act

Kaoru Ishikawa introduced the cause-and-effect diagram in his 1976 Guide to Quality Control as a tool for sorting potential causes into categories so that relationships between them become visible. The diagram organises a brainstormed list of possible causes under major headings. In manufacturing, these headings are typically the six Ms: Manpower, Method, Machine, Material, Measurement, and Mother Nature. In services and healthcare, variations such as the five Ps (Patients, Providers, Policies, Processes, Place) serve the same structural purpose.

The standard next step, as taught in most quality training, is to narrow the branches. Teams use dot voting, multi-voting, or a Pareto analysis to identify the most likely cause, then assign a corrective action. The American Society for Quality describes the diagram as a tool that helps "identify the many possible causes for a problem by sorting ideas into useful categories." The emphasis is on generating and organising ideas. What happens after the organising step is left to the team.

Rewrite the cause your team picked as a claim and test it before the corrective action commits resources to a guess. Start the Walk →

What the prioritisation step adds

A fishbone diagram is an identification tool: it asks what could be causing this problem. The output is a structured list of potential causes. The prioritisation step is a selection tool: it asks which cause the team should address first. The selection is the contribution. It forces the team to narrow twenty or thirty branches to one or two, which is a genuine improvement over leaving the full diagram on a whiteboard.

Doggett compared the cause-and-effect diagram with the interrelationship diagram and the current reality tree and found that all three tools have the capacity to find root causes with varying degrees of accuracy and quality. The fishbone scored well on breadth: it generates a wide set of potential causes. It scored less well on depth: it does not distinguish between a cause the team has evidence for and a cause the team is guessing at.

That gap matters. A fishbone that produces thirty branches and a voting exercise that narrows them to one has moved the team from a broad list to a narrow list. It has not moved them from assumptions to evidence. The same gap appears across problem-solving techniques in business: tools that generate options without testing them produce action plans built on the preferences of whoever was loudest in the room.

Where the standard playbook breaks down

The prioritisation step introduces a problem of its own. It treats the team's collective judgement as a proxy for evidence. The cause that gets the most votes is not necessarily the cause with the most data behind it. It is the cause that the most people in the room are familiar with, or the cause that carries the least political cost.

Kumah and colleagues reviewed the diagram's role in healthcare quality improvement and emphasised that the fishbone generates and organises potential causes for further analysis, not root causes. The further analysis is the step that gets skipped. Teams generate the diagram, vote on the branches, and write corrective actions, often in the same meeting. The speed feels productive. The productivity is an illusion when the selected cause has not been verified.

Liliana's study of manufacturing quality assessment demonstrated that even a carefully constructed Ishikawa diagram with sub-branches across all categories produced a complete picture of all potential causes but not a confirmed picture. The word "potential" does the heavy lifting. A potential cause entered into a corrective action plan becomes a confirmed cause by administrative default, not by investigation.

I have seen this pattern across nearly fifty years of working with teams on problem solving and decision making. The fishbone sits in the conference room, the branches are neatly labelled, and the corrective actions are assigned to people who can execute them. Three months later, the problem recurs because the team addressed a symptom that looked like a cause, not the cause the data would have shown if someone had checked.

The deeper issue is that fishbone diagrams treat every branch as equal until the team votes. There is no structural mechanism for distinguishing a branch the team is confident about from a branch the team is guessing at. Complex problems generate more branches, but more branches do not produce more clarity unless each one is tested. Across the full range of strategic problem solving, the tools that generate options outnumber the tools that verify them. The diagram expands the search. It does not evaluate the findings.

The step to take first

The prioritisation step is not the problem. The problem is prioritising before testing. Before a branch enters a corrective action plan, it needs to survive a simple question: what are we assuming here?

Take each branch and rewrite it as a claim. "Insufficient training" becomes "We believe the operators lack the skill to hold tolerance on this process." Then ask two things about that claim: how much influence does it have on the defect, and how confident are we that it is true? A branch with high influence and low confidence is the one that needs investigation before it receives a corrective action.

A branch you are confident about and that matters to the problem can enter the corrective action plan. A branch you are guessing at and that carries the entire countermeasure should not. The same test applies to every category on the diagram. A branch earns a corrective action only after someone tests whether it is true.

The team from the opening would have listed "insufficient operator training" under Manpower. Rewritten as a claim: "We believe the operators lack the skill to hold tolerance on this process." Influence on the defect: moderate, because other branches also contribute. Confidence: low, because nobody had checked the training records against the error patterns. That branch needed verification before it received a corrective action, not after the training program had been budgeted and delivered.

When I work with teams after a fishbone diagram, the first thing I do is separate branches they have evidence for from branches they are assuming. The separation takes ten minutes, and it changes which causes survive into the corrective action plan. Most teams have never been asked to make that distinction, because the diagram does not require it.

This is the step between completing a fishbone diagram and committing resources to the corrective actions it generates. Separate assumptions from findings. Test the ones that carry the fix. The Universal Decision-Making Method calls this "recognise assumptions" and places it before any commitment, because a corrective action built on an untested branch is a guess with a deadline.

---

Grant Purdy is the co-author, with Roger Estall, of Deciding (2020), and the architect of the Universal Decision-Making Method.