How to build a fishbone diagram and investigate causes

An Ishikawa, or fishbone, diagram organises possible explanations for one problem into understandable groups. Put the problem at the head, groups on the main branches and proposed explanations on smaller branches. The resulting diagram identifies directions for investigation; it does not establish causes by itself.

State an observable problem

The ASQ description presents the diagram as a way to organise possible causes. Begin with an agreed statement of what happened. “Improve our work” describes a desired change but not yet a problem to investigate.

For an illustrative example, use: “Materials for the weekly meeting arrive after the agreed deadline.” Define the period, the materials included and where the deadline was recorded. Avoid inserting a ready-made accusation such as “because colleagues are irresponsible”.

If you do not yet have examples, collect them first. Some delays might follow a change in the agreement and concern a different situation. Combining unlike events makes the next investigation harder to interpret.

Draw the structure and choose branches

Write the problem on the right, draw a horizontal line towards it and add angled branches for groups. For meeting preparation, possible labels are “Task”, “Information”, “Tools” and “Workflow”. These are illustrative choices, not a compulsory set of categories.

Labels should help participants recall the conditions of the task. Manufacturing diagrams may use materials, equipment and measurement; an office team does not need to fill those headings with poorly fitting suggestions.

Include people who understand different parts of the process: assigning the task, preparing the materials and receiving them. They can contribute observations and possible explanations. Agreement across the group is not, by itself, evidence that an explanation is correct.

Add specific possible explanations

For each branch, ask what could have contributed to the outcome. Replace “poor communication” with a proposition you can investigate: “The deadline change was posted in a channel some participants do not read.” Keep it as a possibility until you have supporting evidence.

A smaller branch can describe a proposed connection in more detail. However, asking “why?” does not require inventing an answer when information is missing. “Unknown; needs checking” is a legitimate record of your current understanding.

Decide how to investigate the possibilities

For each significant proposition, identify an observation you can obtain. For the access issue, check whether the relevant participant can open the document. For the deadline issue, examine the message history and agreement about where changes are communicated.

Distinguish supporting evidence, contradictory evidence and unanswered questions. The guide to asking for specific feedback can help with follow-up conversations. Keep those conversations focused on the process rather than assigning blame.

If you have many records and need to select an area, analyse the frequency or time cost of delays. That can prioritise an investigation without establishing a causal connection.

Finish with an action beyond the diagram

Assign a particular check, an owner and a point for reviewing the result. For example: “The coordinator will check template access with participants before the next preparation cycle.” This investigates a condition; a decision about a new process depends on what it reveals.

Keep the diagram beside brief notes about the evidence. After a process change, observe a comparable situation. If an error has been identified, use the guide to correcting it and checking a safeguard.

For other contexts, explore the fishbone examples. The diagram is useful when it helps you choose what to investigate, not simply when every branch is full.