Project Management
PMI Sites
Project Management
• Webinars
• Templates
• Community
• Topics
• Knowledge & Tools
• Events
• Other PMI Sites
• PMI Sites

Ishikawa Diagramming

 Contents 1 Applications 2 Procedures 3 Instructions 4 Examples

A graphic technique, (also known as a fishbone diagrams, herringbone diagrams, cause-and-effect diagrams, or Fishikawa), used for displaying characteristics of a given situation or problem.

The technique was developed by Kaoru Ishikawa in the 1960s, who put the technique into practice as a quality management tool at the Kawasaki shipyards in Japan.

Ishikawa diagrams are used for defect analysis (Root - Cause Analysis). It is very useful when the analysed defect has multiple causes. A problem or defect statement is placed at the "head" of the diagram, and categories for grouping potential causal factors are placed as "bones." This will be referred to as a "problem Ishikawa." The technique is useful in brainstorming sessions to identify potential causes and areas for further investigation. It could be used in affinity diagram sessions too.

Ishikawa diagrams can also be an effective tool for communicating what essential factors needed to achieve a positive outcome or result. As described here, this "positive Ishikawa" will have the desired effect at the "head" and categories of enablers or factors as the "bones."

Another methodology which complements the Fishbone diagram is the "5 Whys" Analysis. The 5 Whys Analysis can be used to complement the analysis that is required to complete the Fishbone diagram as it supports discovery of the ultimate root cause of the issue or problem. It is important to consider that 5 why method tends to determine only one root cause for every 5 why process.

Applications

• To display causal relationships of a given situation or problem.
• To brainstorm or identify potential causes, areas for further investigation, and/or solutions (problem Ishikawa).
• To depict factors leading to successful outcome or result (positive Ishikawa).
• To help cross-functional organizational units understand interaction relationships.

Procedures

1. Agree on the problem statement.
2. Review candidate problems.
3. Remove duplication.
4. Print problem list and cut problems into individual strips.
5. Construct general problem statement and place at "head" of diagram.
6. Identify cause categories (problem Ishikawa) or enabler categories (positive Ishikawa), and place at end of fish's "ribs"or "bones."
7. Review problem list and determine if cause or effect.
8. Determine most probable causes, and place on the final diagram.

Instructions

The first step in developing an Ishikawa diagram is to review all candidate problems from the consolidated lists obtained during the interview process (see Problem Analysis). Remove duplication and combine like problem statements to synthesize the list into a manageable size. (Assign original problem numbers for tracking.) Reprint the problem statements, cut them into individual strips, and tape the strips to a flip chart or board for review. Construct an overall problem, main effect, or customer satisfier statement at the "head" of the diagram (right hand side, see example which follows).

Identify and confirm cause categories for a problem Ishikawa (or enabler categories for a positive Ishikawa), and place in boxes at the end of the fish's "ribs" on the right hand side. This can be done using brainstorming or derived from interview notes. Typical categories (shown in the example) include system, policy, vendor, people, procedures, and/or technical expertise. The following categories may also be used to group causes or enablers: equipment, management, nature, budget, or the traditional quality categories of, manpower, machines, methods, and materials (4m's).

Examine each item from the list available, and determine the best "fit" under each one of the categories. If a list is not available, brainstorm to populate each category with potential causes (problem Ishikawa) and/or enablers (positive Ishikawa).

Alternatively, review each item in the consolidated problems list and ask: "Is this a cause, or does this sound like an effect?" then "Why?...Why?...Why?..." to separate root causes from their effects and to separate out problems from symptoms (see Root Cause Analysis). Exhaust the list of possibilities and discover additional causes. Circle or highlight the most probable causes, being careful not to include symptoms. Discuss and prioritize for analysis/solution generation with the team members.

Validate the most probable causes with the team members, review raw notes and other information collected by the team, and listen to gut hunches. These are the ones that will be placed on the final diagram.

Positive Ishikawa diagrams can provide a beginning to solutions development. The diagram will show factors needed to invent a new approach, new business philosophy, or achieve a goal. They are constructed in the same manner as a problem Ishikawa, except enablers replace causes and a desired effect or goal replaces the problem. This application of the technique can be quite useful, during goal setting or implementation planning. Actions to affect the required change can then be derived from reviewing the enablers.

This technique can also be used to analyze causes of problems inherent in an activity flow. Use the activity flow as the backbone of the Ishikawa with the desired activity result (or output) at the "head." For each activity on the flow, brainstorm possible causes (and/or enablers), and document them on the diagram radiating out from the activities.

Examples

 ishikawa