Fishbone / Ishikawa Diagram: Turn a Vague Delay Problem Into a Ranked Set of Testable Causes

The Fishbone / Ishikawa Diagram sits in the Analyse phase of RDMAICS. By the time you reach Analyse, you have recognised a problem, defined its scope, and measured it. You know something is wrong and you know how big it is. What you do not yet know is why.

The tool lets you build a cause hierarchy directly on a standard fishbone. You write the problem statement at the head. You place main causes on the bones. You drag causes between categories and drop sub-causes beneath their parent causes. The structure is not decoration. It forces you to separate a cause from the condition that allows that cause to exist.

Use it when a team has many opinions and no agreed structure. Use it before you start collecting more data, so that the data you collect answers a question somebody actually asked. Do not use it as a substitute for measurement. The fishbone produces hypotheses. It does not produce evidence.

This case is fictional. It is the sample data built into the tool, and it exists so you can see the method without needing your own dataset first.

The problem statement reads: average pizza delivery time is 48 minutes against a 30-minute promise. That statement does two useful things. It names a measured value and it names the standard the value fails against. A weaker statement would be deliveries are slow. That version gives the team nothing to argue against and nothing to test.

Notice what the statement does not contain. It does not name a cause. It does not say drivers are too slow or the kitchen is behind. If a cause appears in the problem statement, the analysis has already been decided and the fishbone becomes a formality.

The tool opens with the standard six categories: Man / People, Machine, Method, Material, Measurement, and Mother Nature / Environment. In the sample case, each category carries two main causes. That balance is not a rule, but it is a useful discipline early on, because it stops the team from dumping everything into the one category they know best.

Here is how the twelve main causes distribute across the six bones:

A main cause tells you what is happening. A sub-cause tells you why it keeps happening. This is where most fishbones stop too early, and it is where the tool earns its place.

Take the first entry. The main cause is too few drivers during peak demand. Underneath it sit two sub-causes: the roster is based on average demand, and there is no standby coverage for absence. Those two lines change the conversation. The obvious response to too few drivers is hire more drivers. The response to a roster built on average demand is rebuild the roster against the demand curve. The second response is cheaper and faster.

The same pattern repeats across the diagram. Dispatch depends on shift-lead judgement has no standard assignment rule beneath it. The driver app has no live traffic rerouting has routes remain static after dispatch. Kitchen handoff does not consistently follow FIFO has completed orders are staged in different locations. Delivery zones ignore current traffic has zones are reviewed only quarterly. Each sub-cause is closer to something you can change on Monday.

Drag and drop matters here. Teams misfile causes constantly. Somebody places insufficient bags at busy stores under Method when it belongs under Material. Rather than deleting and retyping, you drag it to the correct bone. The structure stays editable while the thinking is still forming.

Once the diagram is populated, the tool calculates a result. For this sample data the completeness figure is 85 per cent, with the six category counts shown beneath the problem statement: Man / People 2, Machine 2, Method 2, Material 2, Measurement 2, Mother Nature / Environment 2.

Read that 85 per cent carefully. It is a measure of how thoroughly the diagram has been built, not a measure of how correct the causes are. The gap in the sample data is visible if you look: two causes, the roster is based on average demand and no standby coverage for absence, carry no sub-causes of their own. Depth is uneven, and the score reflects that.

The tool also offers an AI review that explains the result in plain language. Treat it as a second reader. It can point out where a category looks thin or where a cause reads like a solution in disguise. It cannot replace the person who stands in the store on a Friday night.

A completed fishbone is a planning document for the rest of the Analyse phase. Every cause on it carries a status: hypothesis, observed, data supported, validated, or rejected. In the sample case the causes sit at hypothesis. That is the honest starting position.

Your next decision is which hypotheses to test first. The sample data makes one group stand out. The Measurement bone contains dispatch wait is mixed with travel time, with no timestamp for driver assignment beneath it, and late-delivery reason codes are inconsistent, with stores use free-text explanations beneath it. Until those are fixed, you cannot test anything else properly. You cannot prove the dispatch screen is the problem when dispatch time is not separately recorded.

So the measurement causes move first. Then you test the operational causes with clean data behind you. The fishbone has told you the order of work, which is a more useful output than a list of suspects.

Most fishbone failures are predictable. They come from habit rather than from lack of skill.

Watch for these:

The fishbone will not tell you which cause is the real one. It has no data behind it at the point you build it. Every line on the diagram is a claim made by a person in a room. The 85 per cent score in the sample case says the diagram is well built. It says nothing about whether too few drivers during peak demand actually drives the 48 minute average.

It will not rank causes by impact. The diagram gives equal visual weight to road congestion varies by delivery zone and to no standard assignment rule. One of those may account for most of the delay. The other may account for almost none. You need a Pareto analysis or a controlled test to separate them, and that work sits outside this tool.

It will not detect a missing cause. If the whole team shares the same blind spot, the fishbone will record that blind spot neatly in six categories. Completeness measures what you entered. It cannot measure what nobody thought of.

It will not calculate savings, effort or feasibility. Nothing on the diagram tells you that staging delivery bags is cheap and rebuilding the driver app is not. That judgement belongs in the Improve phase.

Used within those limits, the tool does one job well. It converts a crowded, contested conversation into an organised set of testable statements, with the cheap tests visible and the sequence of work clear. That is enough to ask of it.