Sample of a Fishbone Diagram

What is a Fishbone diagram?

Ishikawa diagrams, also known as fishbone diagrams, are a mechanism for generating and mining data to discover the cause and effect of an issue or observation. Kaoru Ishikawa created this diagramming technique in (1982) to show the causes of a specific event. A fishbone diagram is an analysis tool that provides a systematic way of looking at effects and the causes that create or contribute to those effects. Because of the function of the fishbone diagram, it may be referred to as a cause-and-effect diagram. The design of the diagram looks much like the skeleton of a fish. The technique has been adopted and used in many quality and analytical processes such as SAFe’s Inspect and Adapt process.

This diagramming technique is almost always used in combination with other techniques (see below). The diagram acts as a way to organize many potential causes of problems or issues in an orderly way and so that the root cause can be sifted out of the noise.

When should a fishbone diagram be used?

Does the team…

  • Need to study a problem/issue to determine the root cause?
  • Want to study all the possible reasons why a process is beginning to have difficulties, problems, or breakdowns?
  • Need to identify areas for data collection?
  • Want to study why a process is not performing properly or producing the desired results?

How is a fishbone diagram constructed?

Basic Steps:

  1. The subject of the study forms the  “head of the fish”. This is the problem statement. Note: Identify the problem statement before beginning to draw a fishbone diagram.
  2. Label each “”bone” of the “fish”. The major categories typically utilized are:
  • The 4 M’s: Methods, Machines, Materials, Manpower
  • The 4 P’s: Place, Procedure, People, Policies
  • The 4 S’s: Surroundings, Suppliers, Systems, Skills

Note: You may use one of the four categories suggested, combine them in any fashion or make up your own. The categories are to help you organize your ideas. There are no hard and fast rules for the number and types of categories; let the problem scenario guide you.

3. Use an idea-generating technique (e.g., brainstorming) to identify the factors within each category that may be affecting the problem/issue and/or effect under review. The team should ask… “What are the machine issues affecting/causing…”

4. Repeat this procedure with each factor under the category to produce sub-factors. Continue asking, “Why is this happening?” Add extra segments and factors as discovered. As the chart emerges, the facilitator should focus the team’s brainstorming efforts on areas of the chart that have the least detail. Continue until you no longer get useful information or the team loses focus as you ask, “Why is that happening?”.  Note: List factors (also know as a cause) in as many categories as required.

5. When team members agree that they have captured “enough” detail, analyze the results of the fishbone. Each major category needs to have detail under each major category. Do this by looking for those items that appear in more than one category. These become the ‘most likely causes”.

6. For those items identified as the “most likely causes”, the team should reach consensus on listing those items in priority order with the first item being the most probable” cause. – This is where data gathering and experimentation begin.