Ishikawa diagram

The method finds the causes of a problem when several factors add up to it.

It was introduced by Kaoru Ishikawa, professor at the University of Tokyo.

When to use it

  1. When you know the problem comes from several causes laid on top of one another, and you want to see them laid out before acting against them.
  2. When 5 Why has not given you the answer you hoped for.

When not to use it

  1. When you still do not understand what exactly happened; see 5W+H.
  2. When you have not ruled out a single cause — in that case start with 5 Why.

The goal: used well, the tool names the few causes, out of many, whose removal will pay off most in future.

How to use it

The Ishikawa diagram lets you put the causes in order of what they contributed.

1. Ground rules — what to keep in mind

  1. That you are trying to understand:
    1. What combination of factors brought the problem about?
    2. How do you act against it?
    3. How do you build an early warning system?
  2. That solving the problem will mean removing several of the most important causes at once.

2. Gathering information

You can start by asking the 5W+H questions: Who? What? When? Where? Why? How?

If you need more:

  • What does the problem cost?
  • How big is it?
  • How many defects?
  • What is at risk?

3. Running the meeting

  1. Define the problem clearly. DESCRIBE THE PROBLEM VERY CLEARLY.
  2. Let the team paraphrase it, to see whether it has been understood as clearly as you think.
  3. Go through the ground rules from point 1.

Your team should be drawn from as many different roles and departments as you can manage, so that the problem gets looked at from several sides.

4. Settling the main categories

Agree which categories of cause you are going to work through. There are a few standard sets, and you can define your own.

5M (+E) — used in manufacturing: People, Machines, Materials, Methods/processes, Management, (Surroundings/environment).

4S — used in service businesses: Surroundings/environment, Suppliers, Systems, Skills.

Good practice: write down the categories your team arrives at — next time a similar problem comes up, it will save you the hour.

5. Writing out the causes

Asking why a given cause occurred is worth doing, but as the facilitator, keep the group from disappearing into a long digression about any one of them.

6. Working through the causes

Together, work out which causes, once removed, will do most to stop the problem recurring. Pick two to four of them.

Then work out how to remove each one. How do you act against this cause? What has to be added to the system, and what has to be checked, so that it does not come back? Write those strategies down.

Use it in TeamKit