Ishikawa Diagram

Lay out the possible causes of a problem on a fishbone, then pick the likely ones.

Use it whenyou need to list every possible cause of a problem before choosing one.

Origin
Kaoru Ishikawa, 1968
Time
30 to 60 min
Works
Solo or group
Loading the workspace
§1

Abstract

When something breaks, the first explanation people reach for is usually incomplete. An Ishikawa diagram makes you check every area before you settle on one. The problem goes at the head of the fish. Each bone is a category of cause, traditionally methods, machines, materials, measurements, environment and people.

Having to fill every bone pushes a team past its favourite theory. Once the causes are written down, you dig one level deeper on the strongest candidates and decide what to test first.

§2

Method

  1. 01

    Write the problem at the head

    Describe the effect as something specific you can observe, including where and when it happens.

  2. 02

    Draw the bones

    Add one bone per category. The classic six are methods, machines, materials, measurements, environment and people. Rename them to suit your work.

  3. 03

    Fill each bone

    For each category, ask what could be contributing. Write each cause as a short phrase.

  4. 04

    Go one level deeper

    For the causes that look important, ask why again. The sub-cause is often the thing you can actually fix.

  5. 05

    Mark the likely roots

    Pick the few causes the evidence points to. Test them before you announce anything.

§3

When to use it

  • A defect keeps coming back and there's no obvious single cause.
  • Everyone on the team has a pet explanation.
  • You want a record of what you considered before choosing a fix.
§4

Common pitfalls

  • Writing symptoms on the bones. Each item should be a possible cause, and a restated symptom doesn't help.
  • Stopping at the first layer. Ask why at least once for the causes that look important.
  • Treating every cause as equally likely. The diagram lists possibilities, and you still need data to pick between them.
  • A vague problem statement, which makes every cause look relevant.
§5

Origin and references

Attributed to Kaoru Ishikawa (1968).

  1. Ishikawa, K. (1968). Guide to Quality Control. JUSE Press. English edition: Asian Productivity Organization, 1976.
  2. Ishikawa, K. (1985). What Is Total Quality Control? The Japanese Way. Prentice Hall.
§6

Related tools