Ishikawa Fish Bone, Applications in Organizations

02/02/2021 0 By indiafreenotes

Ishikawa diagrams (also called fishbone diagrams, herringbone diagrams, cause-and-effect diagrams, or Fishikawa) are causal diagrams created by Kaoru Ishikawa that show the potential causes of a specific event.

The fishbone diagram or Ishikawa diagram is a cause-and-effect diagram that helps managers to track down the reasons for imperfections, variations, defects, or failures.

The diagram looks just like a fish’s skeleton with the problem at its head and the causes for the problem feeding into the spine. Once all the causes that underlie the problem have been identified, managers can start looking for solutions to ensure that the problem doesn’t become a recurring one.

can also be used in product development. Having a problem-solving product will ensure that your new development will be popular provided people care about the problem you’re trying to solve. The fishbone diagram strives to pinpoint everything that’s wrong with current market offerings so that you can develop an innovation that doesn’t have these problems.

Common uses of the Ishikawa diagram are product design and quality defect prevention to identify potential factors causing an overall effect. Each cause or reason for imperfection is a source of variation. Causes are usually grouped into major categories to identify and classify these sources of variation.

Advantages

  • Highly visual brainstorming tool which can spark further examples of root causes
  • Quickly identify if the root cause is found multiple times in the same or different causal tree
  • Allows one to see all causes simultaneously
  • Good visualization for presenting issues to stakeholders

Disadvantages

  • Complex defects might yield a lot of causes which might become visually cluttering
  • Interrelationships between causes are not easily identifiable

Variation = Imperfection

When it comes to quality and efficiency, variation is your enemy. Whatever your business is, you don’t want to leave anything up to chance. From the moment your client contacts you, a predictable process should be followed with its aim being complete customer satisfaction. Variation in the process will mean variation in the product.

Fishbone diagrams help you to determine the variables that may enter the equation. They allow you to make your plans so that you know how to deal with them in such a way that the quality of your final product is still up to standard and without significant variation.

Applications

  • To analyze and find the root cause of a complicated problem
  • When there are many possible causes for a problem
  • If the traditional way of approaching the problem (trial and error, trying all possible causes, and so on) is very time consuming
  • The problem is very complicated and the project team cannot identify the root cause

Construct a Fishbone diagram

Here are the various tasks involved in constructing a Fishbone diagram:

  1. Define the problem
  2. Brainstorm
  3. Identify causes

Define the problem

The first step is fairly simple and straightforward. You have to define the problem for which the root cause has to be identified. Usually the project manager or technical architect, we will refer to this role as the leader throughout the rest of the article decides which problem to brainstorm. He has to choose the problems that are critical, that need a permanent fix, and that are worth brainstorming with the team. The leader can moderate the whole process.

After the problem is identified, the leader can start constructing the Fishbone diagram. Using a sheet of paper, she defines the problem in a square box to the right side of page. She draws a straight line from the left to the problem box with an arrow pointing towards the box. The problem box now becomes the fish head and its bones are to be laid in further steps. At the end of the first step, the Fishbone diagram looks like:

Brainstorm

People have difficulty understanding how to structure the thought process around a large problem domain. Sometimes it is useful to focus on logically related items of the problem domain and to represent them in the Fishbone diagram, which will convey the problem solving methodology. There are quite a few tools available that can help us in this regard, including:

  • Affinity Chart
    Organizes facts, opinions, ideas, and issues into a natural grouping. This grouping is in turn used as an aid in diagnosing complex problems.
  • Brainstorming
    Gathers ideas from people who are potential contributors. This process is discussed further in the following sections.
  • Check sheet
    Acts as a simple data recording device that helps to delineate important items and characteristics to direct attention to them and verify that they are evaluated.
  • Flow charts
    Organizes information about a process in a graphical manner and makes it clear who is impacted at every stage.

No single methodology is applicable to all problem domains. Based on experience and study, you can identify, thoroughly analyze, and maintain the methodology and the related problem domains. In the example given later in this article, we use brainstorming as the problem solving methodology.

Categorize

When you apply the Fishbone technique to business problems, the possible causes are usually classified into six categories:

  • Method
  • Man
  • Management
  • Measurement
  • Material
  • Machine

Though the above are a few important problem categories, during the brainstorming session, the team is encouraged to come up with all possible categories. The above categories give the team direction to help find the possible causes. Some of the categories listed above may or may not be applicable to software or to Domino in particular. Let’s look briefly at each category.

Category Description
Method Methods are ways of doing things or the procedures followed to accomplish a task. A typical cause under the Method category is not following instructions or the instructions are wrong.
Man People are responsible for the problem. The problem may have been caused by people who are inexperienced, who cannot answer prompted questions, and so on.
Management Management refers to project management; poor management decisions, such as upgrading two components simultaneously rather than deploying changes serially may cause technical problems.
Measurement Measurement refers to metrics that are derived from a project. Problems may occur if measurements are wrong or the measurement technique used is not relevant.
Material Material basically refers to a physical thing. A bad diskette is one typical example. Software can’t always handle errors caused by bad material, for instance a bad backup tape, so while material may be the least likely cause, it is a possible cause.
Machine A machine in software usually refers to the hardware, and there are a lot of possibilities that a problem can be due to the machine, such as performance issues.

Other possible categories include policies, procedure, technology, and so on.

After identifying a problem, the leader initiates a discussion with the project team to gather information about the possible causes, finally arriving at the root cause. The team can either analyze each of the above categories for possible causes or look into other categories (not listed above).

Identify causes

While brainstorming, the team should strive toward identifying major causes (categories) first, which can be further discussed, and then secondary causes for each major cause can be identified and discussed. This helps the team to concentrate on one major cause at a time and to refine further for possible secondary causes.

After the major causes (usually four to six) are identified, you can connect them as fishbones in the Fishbone diagram. They are represented as slanted lines with the arrow pointing towards the backbone of the fish. See Figure 2 later in this article.

Sometimes it is difficult to arrive at a few major causes. The team may come up with a lot of causes, which makes brainstorming more difficult. In this case, the leader can assign 10 points to each team member for each possible cause, and let them assign the rating (from 1 to 10, 10 being most likely cause) to each cause. After everyone on the team has rated the causes, the project manager totals each of the causes and ranks them based on their ratings. From the list, the top four to six causes are identified as major causes and connected as bones in the diagram.

The diagram looks a little like the skeleton of a fish, hence the name Fishbone. After the major causes of the problem are identified, each one of them is discussed in further detail with the team to find out the secondary causes. If needed, the secondary causes are further discussed to obtain the next level of possible causes. Each of the major causes is laid as a fishbone in the diagram and the secondary causes as “bonelets.”

The diagram now has a comprehensive list of possible causes for the problem, though the list may not be exhaustive or complete. However, the team has enough information to begin discussing the individual causes and to analyze their relevance to the problem. The team can use analytical, statistical, and graphical tools to assist in evaluating each of the causes. The Pareto principle (explained in part two of this article series) is also used to find the elements that cause major problems and to list them as major causes in the Fishbone diagram. Software metrics that are obtained during application support can also be used here for further assistance.

Evaluate, decide, and take action

It may be very difficult to come up with consensus on a large team for one possible root cause, but the majority is taken into consideration. Also, the major causes can be ranked in order with the most likely cause at the top of the list.

After the evaluation process is complete, the action plan has to be decided. If one possible root cause is identified, then the action plan has to be derived to rectify it. Sometimes, it may be difficult to arrive at the root cause; there may be a few possible root causes. In this case, the action plan has to be drawn for each of the possible root cause.

After the action plan is ready, the leader can designate an individual or team to work on the plan and to rectify the problem permanently. If there are a few possible root causes, all the action plans are to be executed, and the most likely root cause is identified and fixed.