# Ishikawa Diagram

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

Chapter III, Problem solving · 3.01 · Origin: Kaoru Ishikawa (1968) · Time: 30 to 60 min · Solo or group

**Use it when** you need to list every possible cause of a problem before choosing one.

Interactive workspace: https://kogu.tools/tools/ishikawa-diagram

## 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.

## Method

1. **Write the problem at the head.** Describe the effect as something specific you can observe, including where and when it happens.
2. **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. **Fill each bone.** For each category, ask what could be contributing. Write each cause as a short phrase.
4. **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. **Mark the likely roots.** Pick the few causes the evidence points to. Test them before you announce anything.

## 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.

## 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.

## References

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