Fishbone (Ishikawa) Diagram

What this tool does

CM8-227 turns the fishbone diagram — the cause-and-effect drawing every quality team knows — into a working register. Each row is one candidate cause: it names the problem it belongs to, sits on one of the six bones, carries the why-behind-the-why detail, a likelihood judgement, an evidence grade, and eventually a verified-root-cause flag with an action, an owner and a status. The tool scores every cause, ranks them for investigation, shows which bones are crowded and which are suspiciously quiet, and prints the whole analysis as a report you can take into a customer meeting or a management review.

Everything runs inside this single file in your browser. There is no account, no upload and no network request, so a candid analysis of your own process failures never leaves the machine it was typed on.

What a fishbone diagram is

A fishbone diagram — also called an Ishikawa diagram or a cause-and-effect diagram — is a way of organising a brainstorm about why a problem happens. The problem, called the effect, is written at the head of the fish. The major categories of possible cause form the big bones off the spine, and individual candidate causes hang off those bones, with sub-causes branching further as the team keeps asking why. The diagram takes its second name from Kaoru Ishikawa, the Japanese quality pioneer who popularised it as one of the basic tools of quality control.

The drawing itself does not solve anything. Its value is that it forces breadth: instead of the whole room chasing the first plausible idea, every category gets asked its questions, and the result is a structured map of everything the problem could be — which is the correct starting point for finding out what it actually is.

The six M categories

Manufacturing fishbones conventionally use six bones, each starting with M:

• Man (People) — skill, training, experience, fatigue, staffing levels, communication. Example: a new starter still learning the spray pattern, or a task that depends on one person's unwritten knowledge.
• Machine — equipment, tooling, fixtures, maintenance condition. Example: a worn nozzle, a regulator that drifts during the shift, a fixture that no longer clamps square.
• Method — the process and procedure: settings, sequences, work instructions, standards or the absence of them. Example: no defined gun distance, a line speed raised without changing the recipe.
• Material — inputs and consumables: raw material variation, supplier changes, storage and shelf life. Example: viscosity varying between paint batches, a substituted thinner grade.
• Measurement — gauges, data and acceptance criteria: calibration, gauge repeatability, how and when the check is done. Example: operators judging coverage by eye between gauge checks, a gauge out of calibration.
• Environment — the physical and organisational surroundings: temperature, humidity, lighting, layout, housekeeping, and the working culture. Example: booth humidity swinging with the weather.

Service and office teams often relabel the bones. The 4S set — surroundings, suppliers, systems, skills — and the 8P set used in service and marketing — product, price, place, promotion, people, process, physical evidence, performance — cover the same ground with vocabulary that fits the work. The categories are scaffolding, not doctrine: use the set that makes your team think widest, and keep this tool's six bones as the storage structure underneath.

Running the brainstorm

A fishbone session has two phases, and mixing them up ruins both. Phase one is quantity: collect every candidate cause anyone can think of, without judging any of them. Evaluation during the brainstorm silences exactly the people most likely to know the awkward answer. Phase two — scoring, investigating, eliminating — comes after the board is full.

Practical habits that make the hour productive:

• Define the effect precisely first. "Coating thickness out of specification" can be investigated; "paint problems" cannot. If the effect is vague, the bones fill with vague causes.
• Walk every bone deliberately. Ask the room for machine causes, then method causes, and so on. The quiet bones are where the surprises live.
• Ask "why does that happen?" down each bone. "Viscosity varies" is a cause; "because incoming batches are not checked and thinning is done by eye" is the level at which something can be fixed. Put that deeper layer in the sub-cause detail field.
• Include the people who do the work. The operator who fights the problem daily holds more of the diagram than anyone in the meeting room.
• Causes, not blame. "Operator error" is where a bone starts, never where it ends. Ask why the error was possible and why nothing caught it.

From drawing to working register

A whiteboard fishbone dies when the meeting ends. This tool keeps it alive by giving every cause two working judgements and a score:

Likelihood is the team's judgement of how likely the cause is to contribute to the effect. Evidence strength records what actually stands behind that judgement — nothing yet, an anecdote, repeated observation, or verification against data or a test. Multiplying them ranks the causes for attention: a likely cause with strong evidence outranks everything, and a likely cause with no evidence scores modestly — which is correct, because the score is telling you to go and get the evidence, not to act. The register colours high scorers red and mid scorers amber; both thresholds are adjustable on the Settings tab.

Each cause then moves through a simple life: hypothesis when raised, investigating while someone checks it, then either eliminated — ruled out with evidence, which is genuine progress — or confirmed as a root cause, and finally addressed once the fix is done. The status donut on the Reports tab shows whether the brainstorm is actually turning into an investigation or just ageing.

Evidence before confirmation

The most common failure of cause-and-effect analysis is confirming the cause the room liked best. The tool enforces one discipline against that: a cause cannot be ticked as a verified root cause, or given confirmed status, until its evidence strength is at least moderate — repeated observation or a data sample — and it should really be strong: verified with data or a test. The best verification is an experiment: change the suspected cause and watch the effect respond, or find the natural experiment in your records where the cause was absent and check the effect was too.

Record eliminations with the same care. "Checked the gauge against calibration foils — reads within tolerance" in the detail field is worth more next year than the memory that somebody once looked.

Fishbone and 5-why together

The two classic root-cause tools answer different questions. A fishbone is broad: it maps everything the cause could be, across every category, before the team commits to a direction. A 5-why is deep: it takes one candidate cause and drills vertically — why? because; why? because — until it reaches something systemic.

They combine naturally, in that order. Use the fishbone to lay out the field and the priority score to pick the two or three causes worth drilling; then run a 5-why down each of those, and put what the drilling finds into the sub-cause detail field. A 5-why run without the fishbone first tends to drill an efficient hole in the wrong place; a fishbone without the 5-why after it stays a list of first-level symptoms. The verified root causes that survive both steps are the ones that deserve actions, owners and money.

Saving and printing

Causes, settings and the report header are written to this browser's local storage as you type, and the toolbar shows the last save time. That storage belongs to one browser on one computer — a different machine, a private window or a site-data clean-up will not have it. Treat Export .json as the real save: one file holding everything, which Import .json restores anywhere. Export CSV gives you the register for spreadsheet work. Reset asks twice, then erases everything — there is no undo.

Print Report produces the full pack from whatever the current filter shows: the headline tiles, the four charts, the bone-by-bone diagram in list form, the confirmed root causes with their actions, and the register. The scope line states any filter in force — clear the filters before issuing anything described as the complete analysis.

FAQ

Can one file hold more than one problem? Yes. Every cause names its problem, so the file can carry several fishbones at once — spell each problem identically and the tool groups them automatically. The balance chart draws one bar per problem, and the bone-by-bone table keeps each problem's causes together. Use the filters when you want to work on one fish at a time.

What if a cause fits two bones? Pick the bone where the fix would live. A gauge nobody uses is measurement if the gauge is wrong, method if the instruction never calls for it, and people if the training never covered it. If the room genuinely cannot decide, that usually means it is two causes — split them.

How many causes should a fishbone have? A healthy first session on a real problem commonly produces ten to thirty. Fewer than six usually means the brainstorm stopped at the obvious; many more than forty means the effect was defined too broadly and should be split into separate problems.

Can there be more than one root cause? Very often. Most stubborn problems are the sum of two or three interacting causes — in the sample data, batch viscosity variation and by-eye coverage judgement are both confirmed, and fixing only one would have left the problem alive.

Should eliminated causes be deleted? No. An elimination with its evidence is part of the analysis — it stops the next investigator re-opening the same dead end, and it shows an auditor the conclusion was reached by ruling things out rather than by preference.

Accuracy & disclaimer

This tool structures an investigation; it does not perform one. The priority score multiplies two judgements you entered — it ranks hypotheses for attention, and it neither proves nor measures causation. A confidently scored diagram built on weak evidence looks exactly as tidy as a sound one.

Confirm root causes only against data or tests that someone is prepared to defend, and treat the printed report as a record of the team's reasoning, not as a substitute for it. This is an analysis aid, not advice of any kind.