A fishbone diagram is a tool used to facilitate root cause analysis for a defined problem. The diagram provides a structured way to record potential root causes during brainstorming, encouraging teams to think about a problem systematically and to dig deeper to discover less obvious causes.

Cause and Effect diagrams have been illustrated in many ways. One of the most novel is called the “fishbone” or “Ishikawa” diagram, named after Dr. Kaoru Ishikawa, it’s originator. Dr. Ishikawa was an expert in Quality Control Theory. Why it is called “fishbone” becomes obvious when the diagram is completed, in that it looks like a fish skeleton.

The analysis starts with a problem to be investigated. This problem is written in the form of a question on the right side of the page. An arrow, or sometimes a drawing of a fish head, will point to the question under consideration. To the left of the problem statement, a horizontal line divides the paper in two. This is the “backbone” of the fishbone diagram.

The next set of bones represents the most important categories of the factors which might lead to the basic cause; the names of these categories are written along the top and bottom of the paper, with angled arrows pointing back to the backbone as well as towards the head, thus forming a herringbone pattern.

There are six categories that relate to manufacturing problems: machine, methods, material, maintenance, man and mother nature. There are other categories such as equipment, process, environment and Management that are added on to this. Experts use several factors to analyze service and administrative problems such as: price, promotion, processes, place, policies, procedure and the product. A service industry for example would use the following factors to figure out problems: surroundings, suppliers, systems and skills. This is why conventions have been developed to provide categories to help determine the problem areas in these fields.

Analysis gets underway after the fundamental skeletal structure is in position. Variables are listed that play a part in each subset of elements that result in the underlying or root cause. These are displayed on top of arrows directing you to the subset lines, which themselves may possess lines of their own directing toward them, further delineating the variables that play a part. While this may proceed ad infinitum, naturally it will be hard to sketch more than a minimal number of levels.

With the skeleton of the diagram in place a team brainstorms about each category, looking for reasons that produce the end result. Generally, it is good to phrase a problem as a question and ask team members to answer the question in the context of each category. In general, the question is “Why is this happening?” Then, for each category, the question shifts to “How are factors in this category causing this?”

The brainstorming continues until team members can no longer think of useful items to add to the diagram.  At this point, the results are analyzed to identify the most likely root causes of the problem. Finding the same issue within multiple categories is a good indication that it is an important root cause in the system. Likewise, areas of the diagram that are densely populated with detail are likely to point to areas of significance.