Beyond Amazing
The Strategy Toolkit

Operations & process

Fishbone Diagram

Ishikawa's cause-and-effect diagram. A team maps every plausible cause of a defined problem onto structured category branches, classically the six Ms, turning a tangle of opinions into an organised set of hypotheses that can then be verified against data.

Also known as Ishikawa diagram, Cause-and-effect diagram, Herringbone diagram. First set out by Kaoru Ishikawa in 1943; the primary source is cited in full below.

Format
Mapping
Level
Team
Best for
Plan execution · Assess risk
Decision stage
Diagnose · Review
Difficulty
Introductory
Time to apply
One facilitated session of 60 to 90 minutes; verification of the shortlisted causes takes days to weeks.

Plate · The model

Man (people)MachineMethodMaterialMeasurementMother nature(environment)The effect (theproblem)
6 factors bearing on the effect (the problem), read one at a time.
I

The components

1

The effect (the problem)

The defined, preferably quantified problem under investigation, written at the head of the fish. Every branch of the diagram exists to explain this one effect, which is why its precision matters more than anything else on the page.

2

Man (people)

Causes rooted in the people doing the work: skill, training, staffing, fatigue, communication and adherence to method. Modern practice usually relabels this branch People. Handle it carefully; it is the branch most prone to blame and least often the true root.

Signals of strength
Defect rates differ by shift, crew or individual · New starters or agency staff on the affected line · Training records out of date for the current method · Known workarounds that differ from standard work

3

Machine

Causes in equipment and tooling: wear, maintenance state, calibration drift, capability and setup. Often relabelled Equipment.

Signals of strength
Defects correlate with one machine or tool among several · Maintenance overdue or recently performed on the affected asset · Settings drift between setups or shifts · Equipment running outside its designed range or speed

4

Method

Causes in how the work is specified and performed: procedures, sequence, parameters, scheduling and the gap between the written method and actual practice. Often relabelled Process.

Signals of strength
No current standard for the operation, or several competing ones · Process parameters adjusted informally to chase throughput · The documented method differs from what observation shows · Defects appear after a procedure or schedule change

5

Material

Causes in raw materials, components and consumables: supplier variation, batch differences, storage, handling and specification.

Signals of strength
Defects cluster by supplier, batch or delivery · Incoming inspection missing or specification loosely defined · Material properties vary within tolerance yet affect the process · Storage or handling conditions differ from specification

6

Measurement

Causes in how the effect and the process are measured: gauge accuracy, inspection method, sampling, and inconsistency between inspectors. A measurement problem can manufacture a defect that does not exist, or hide one that does.

Signals of strength
Judgement-based inspection with no reference standard · Two inspectors or gauges disagree on the same item · Calibration lapsed on the measuring equipment · The defect rate changed when the measurement method did

7

Mother nature (environment)

Causes in the surrounding conditions: temperature, humidity, dust, lighting, vibration and seasonality. Usually relabelled Environment in modern usage.

Signals of strength
Defect rate varies by season, weather or time of day · Process is sensitive to temperature or humidity swings · Environmental controls absent or overridden · Problems concentrate in one physical location or line

II

When it earns its keep

  • A problem has many plausible causes and the team is talking past itself. The diagram forces the discussion onto one shared page.
  • You are in the Analyse phase of a DMAIC project, or partway down a Five Whys chain, and need to widen the search before narrowing it. Fishbone opens the funnel that data then closes.
  • A recurring defect keeps being 'fixed' and keeps returning, a reliable sign that only one branch of the cause structure has ever been examined.
  • You want to run cause analysis with a mixed group, operators, engineers and managers together, and need a format where a machinist's observation carries the same weight as a director's.

And when it doesn't

  • The cause is already known and verified. Drawing a skeleton around a solved problem is decoration.
  • You need to establish which cause actually drives the effect. The diagram generates and organises hypotheses; it contains no mechanism for testing them. Pair it with Pareto analysis, stratified data or experiments.
  • The causes interact heavily or form feedback loops. The fishbone's tree structure shows each cause on one branch and hides interdependence; an interrelationship digraph or systems map serves better.
  • The problem statement is vague. 'Morale is poor' at the fish's head produces a poster of grievances; sharpen the effect into something specific and measurable first.
III

How to run it

Before starting, gather the inputs the analysis depends on:

  • A specific, agreed problem statement, ideally quantified: the effect that goes at the head of the fish.
  • A cross-functional group that includes people who touch the process daily, since the diagram is only as good as the causal knowledge in the room.
  • A chosen category set: the classic manufacturing six Ms, or a variant suited to the domain, agreed before brainstorming starts.
  • Whatever evidence exists already: defect logs, complaint records, shift reports, to keep the brainstorm anchored to the observed problem.
  1. 1

    Define the effect

    Write the problem at the head of the fish, specific and preferably measured: 'misshapen loaves at 4.1% of output', rather than 'quality issues'. Every ambiguity here multiplies across the branches.

  2. 2

    Choose the category branches

    The canonical manufacturing set is the six Ms: Man, Machine, Method, Material, Measurement and Mother nature. Modern practice often relabels them People, Equipment, Process, Materials, Measurement and Environment, and service teams use variants such as the 4 Ss or 8 Ps. Pick one set and resist inventing categories mid-session.

  3. 3

    Brainstorm causes onto the branches

    Work branch by branch, or let causes land where they fit, asking 'why does this effect happen?' for each category. Record causes as stated by the people closest to the work; tidy the wording later.

  4. 4

    Drill into sub-causes

    For each significant bone, ask why again and hang sub-causes off it. This is where the diagram earns its keep: 'operator error' is never a root cause, only a bone that has not been drilled yet.

  5. 5

    Review, prune and prioritise

    Step back with the team, cluster duplicates, and mark the causes that are most plausible, most supported by existing evidence, or easiest to check. Circle no more than a handful for verification.

  6. 6

    Verify against data

    The diagram ends where measurement begins. Take the circled candidates and test them: stratify the defect data, run a Pareto analysis, or change one factor and watch the effect. A fishbone that never meets data is a well-organised set of guesses.

IV

Reading the result

A single shared picture of every plausible cause of a defined problem, organised by category and drilled to sub-causes, with a shortlist of candidate root causes marked for verification against data.

  • The canonical form is the fish skeleton, the effect at the head and category branches as ribs; the hub layout shown here is a category view of the same structure, with the effect at the centre and the six Ms around it.
  • Read the diagram as a map of hypotheses, never as findings. Density on a branch shows where the team's attention is, and possibly its bias, rather than where the truth is.
  • Bones that stop at a single word ('training', 'the machine') are unfinished; a well-drilled branch reads as a causal chain you could go and check.
  • An empty branch is information: either the category truly contributes nothing, or nobody in the room knows that part of the process. Find out which.
V

A worked example

An industrial bakery hunts the causes of misshapen loaves

A UK industrial bakery runs a high-speed line producing 7,000 sandwich loaves an hour for supermarket own-label contracts. Misshapen loaves, dipped tops, slumped sides and out-of-gauge height, are running at 4.1% at depanning against a 1.5% standard, costing about 6,500 pounds a week in waste and downgrades. The shift managers, line operators, a process technologist and the maintenance lead spend ninety minutes building a fishbone before anyone is allowed to propose a fix.

The effect (the problem)
Written at the head as 'misshapen loaves at depanning: 4.1% of output over the last four weeks against a 1.5% standard, worst on the night shift'. The team rejects the first draft, 'poor loaf quality', as too vague to analyse.
Man (people)
Night shift relies on agency cover for two of the five line roles; moulder setup is adjusted by feel and each setter has their own settings. Sub-cause drilled: no photographed setup standard exists for the moulder, so 'inexperienced staff' actually resolves into a Method gap.
Machine
The moulder's pressure boards are worn and due for replacement; the final prover's chain has developed a sway that rocks pans at one transfer point. Maintenance notes the divider's oil level alarm has been triggering weekly, which can vary dough piece weight.
Method
Proof time is being trimmed by up to six minutes on the night shift to recover schedule after changeovers, and dough temperature targets are hit by adjusting water without logging it. The heaviest bone on the diagram once sub-causes are drilled.
Material
Flour arrives from two mills; protein content varies within specification between silo deliveries, and operators say the dough 'handles differently' for two days after a switch. Yeast batch changes are not recorded against quality data, so nobody can check a suspected link.
Measurement
Shape is judged by eye at line speed with no go/no-go gauge; the day and night QA leads disagree about borderline loaves. Part of the apparent night-shift excess may be a stricter inspector, which would change the problem's size without changing the process.
Mother nature (environment)
Bakery ambient humidity swings when despatch doors are open in cold weather, and the proofer struggles to hold setpoint on winter nights, which is consistent with the seasonal pattern in the waste data.

The read. The diagram does what it should: it converts a blame conversation about agency staff into three checkable hypotheses, informal proof-time trimming interacting with flour variation, worn moulder boards, and inconsistent shape judgement between shifts. The team's next step is measurement, a simple height gauge and two weeks of stratified data by shift, flour delivery and proof time, before any money is spent. The honest reading is that the fishbone has produced candidates, and the verdict belongs to the data.

VI

Pitfalls

  • Treating the finished diagram as the analysis. The fishbone organises conjecture; without verification against data it changes what a team believes rather than what it knows.
  • A vague effect at the head. If the problem statement would fit any bad week in any factory, the branches will fill with generic complaints.
  • Stopping at category-level causes. 'Machine' with three one-word bones is a diagram that ended before the thinking started; drill until each bone is specific enough to check.
  • Letting the loudest function fill the diagram. Branch density follows who is in the room; missing perspectives leave whole categories falsely empty.
  • Using the People branch as a blame channel. 'Operator error' written as a root cause almost always conceals a Method, Measurement or Machine cause that management owns.
VII

What the critics say

Comparative research on root cause analysis tools finds the fishbone diagram easy to use and good for participation, but weak at representing interdependence between causes: its tree structure cannot show one cause feeding several branches or causes reinforcing each other, which tools such as the interrelationship digraph and current reality tree handle better.

Doggett, A. M. (2005) 'Root Cause Analysis: A Framework for Tool Selection', Quality Management Journal, 12(4), pp. 34-45.

Critiques of root cause analysis practice in healthcare, where fishbones are standard equipment, argue that the tools give an unwarranted sense of closure: teams produce tidy causal diagrams, pick weak administrative countermeasures, and the same incidents recur. The diagram's neatness can substitute for the harder work of verification and systemic fix.

Peerally, M. F., Carr, S., Waring, J. and Dixon-Woods, M. (2017) 'The problem with root cause analysis', BMJ Quality and Safety, 26(5), pp. 417-422.
VIII

Sources and further reading

  • Ishikawa, K. (1976) Guide to Quality Control. Tokyo: Asian Productivity Organization.
  • Ishikawa, K. (1985) What Is Total Quality Control? The Japanese Way. Translated by D. J. Lu. Englewood Cliffs, NJ: Prentice-Hall.
  • American Society for Quality, 'What is a Fishbone Diagram? Ishikawa Cause and Effect Diagram'. ↗
  • Doggett, A. M. (2005) 'Root Cause Analysis: A Framework for Tool Selection', Quality Management Journal, 12(4), pp. 34-45.

Pairs well with Five Whys·DMAIC·Pareto Analysis·PDCA Cycle·Failure Mode and Effects Analysis·compare side by side

Near neighbours (computed from shared tags)·AI Risk Management Framework (NIST AI RMF)·Team Psychological Safety·Customer Journey Mapping