The Fishbone Session

When you are faced with a problem, or an opportunity, try running a Fishbone session with your staff. We have found it to be a very powerful yet simple way to generate innovative solutions, and we use it a lot. It is also important because it really gets your people involved in solutions in which they have a stake and a sense of ownership. Sometimes it is called a cause and effect session, but fishbone visually describes the diagram used.

Use This Diagram

Gather your troops at a blackboard and draw the diagram below:

This is the basic fishbone diagram using the Man-Method-Material-Machine format, which is only one possibility. It is probably best used for problem solving.

Here Are the Basic Steps and Rules

There are a number of steps and rules you should try to follow.

1. Define the problem or opportunity in a brief statement that all can agree upon.

2. It is often useful to use the Man-Method-Material-Machine format shown above to help organize possible solutions into categories. However, you may want to devise your own basic organizational scheme. These outgrowths become the main fishbones in your diagram. You will add smaller branches to some or all of these as you proceed.

3. The next stage is an open brainstorming session in which any idea (a cause for the defined problem, for example), no matter how far-fetched, is allowed and is added to the diagram as another fishbone "leg" on one of the appropriate major categories. The idea is to generate as many ideas as possible that would explain why the problem exists or how the opportunity might be seized. No discussion as to the merits of the idea and especially no negative comments are allowed. This absolutely must be strictly enforced! The only discussion might concern under which branch to place the idea, and the

moderator should quickly step in to make a placement in case of disagreement, even if the placement is arbitrary.

4. After your group has exhausted its ideas, discussion is allowed. It is most helpful if this takes the form of an explanation of the concept or thinking behind each idea by the one who proposed it, and even expansions on the idea. Try to keep things positive, and don't drag it out!

5. Number or letter each idea on the fishbone diagram and provide each person with a piece of paper. Each person is to select the five ideas he or she thinks have the most merit in defining the problem, causes, or opportunity and is to rank these five from most important to least important. The most important is given a numerical value of five, the next four, and so forth.

6. Now go around your group one by one and ask them for their rankings. Put a "5" on the board next to each person's highest ranked item, a "4" next to the second highest ranked item, and so forth until all five are on the board. Repeat this process with each person in the group.

7. Total the values next to each item on the fishbone diagram. The item with the highest total is the one the group has selected as having the most potential for defining or solving the problem or opportunity. It does not, of course, guarantee that this idea, or any of them for that matter, will actually work. It is instead a powerful tool for prioritizing problem or opportunity solving, for generating novel or innovative solutions, and for involving people intimately in the process. It is surprising how often this simple process generates good solutions and ideas.

It is simple to do, involves everyone in the solution process, and goes a long ways toward assuring strong support for solution implemetation. Well, we've given you one of our proven, better techniques for generating answers to tough problems.

Why not go fishing, or let us help you do so??

Cause-and-Effect Analysis

A cause-and-effect analysis generates and sorts hypotheses about possible causes of problems within a process by asking participants to list all of the possible causes and effects for the identified problem. This analysis tool organizes a large amount of information by showing links between events and their potential or actual causes and provides a means of generating ideas about why the problem is occurring and possible effects of that cause. Cause-and-effect analyses allow problem solvers to broaden their thinking and look at the overall picture of a problem. Cause-and-effect diagrams can reflect either causes that block the way to the desired state or helpful factors needed to reach the desired state.

When to Use It

A graphic presentation, with major branches reflecting categories of causes, a cause-and-effect analysis stimulates and broadens thinking about potential or real causes and

facilitates further examination of individual causes. Because everyone’s ideas can find a place on the diagram, a cause-and-effect analysis helps to generate consensus about causes. It can help to focus attention on the process where a problem is occurring and to allow for constructive use of facts revealed by reported events. However, it is important to remember that a cause-and-effect diagram is a structured way of expressing hypotheses about the causes of a problem or about why something is not happening as desired. It cannot replace empirical testing of these hypotheses: it does not tell which is the root cause, but rather possible causes.

Return to Resources

Back to top

Types of Cause-and-Effect Analyses

There are two ways to graphically organize ideas for a cause-and-effect analysis. They vary in how potential causes are organized: (a) by category: called a fishbone diagram (for its shape) or Ishikawa diagram (for the man who invented it), and (b) as a chain of causes: called a tree diagram.

The choice of method depends on the team’s need. If the team tends to think of causes only in terms of people, the fishbone diagram, organized around categories of cause, will help to broaden their thinking. A tree diagram, however, will encourage team members to explore the chain of events or causes.

Causes by Categories (Fishbone Diagram)

The fishbone diagram helps teams to brainstorm about possible causes of a problem, accumulate existing knowledge about the causal system surrounding that problem, and group

causes into general categories.

 

When using a fishbone diagram, several categories of cause can be applied. Some often-used categories are:

Human resources, methods, materials,

measurements, and equipment

Clients, workers, supplies, environment, and procedures

What, how, when, where

Return to Resources

Back to top

 

Categories for this type of cause-and-effect diagram vary widely, depending on the context. The group should choose those categories that are most relevant to them and feel free to add or drop categories as needed. A quality improvement team at San Carlos Hospital in Bolivia developed the fishbone diagram to improve the attention given to women in delivery and prenatal care.

A Chain of Causes (Tree Diagram) and the Five Why’sA second type of cause-and-effect analysis is a tree diagram, which highlights the chain of causes. It starts with the effect and the major groups of causes and then asks for each branch, "Why is this happening? What is causing this?" The tree diagram is a graphic display of a simpler method known as the Five Why’s. It displays the layers of causes, looking in-depth for the root cause. This tool can be used alone or with any of the cause-and-effect diagrams.

Tree Diagram

Example

Question 1: Why did the patient get the incorrect medicine?Answer 1: Because the prescription was wrong.

Question 2: Why was the prescription wrong? Answer 2: Because the doctor made the wrong decision.

Question 3: Why did the doctor make the wrong decision? Answer 3: Because he did not have complete information in the patient’s chart.

Question 4: Why wasn’t the patient’s chart complete? Answer 4: Because the doctor’s assistant had not entered the latest laboratory report.

Question 5: Why hadn’t the doctor’s assistant charted the latest laboratory report?Answer 5: Because the lab technician telephoned the results to the receptionist, who forgot to tell the assistant.

Solution: Develop a system for tracking lab reports.

Return to Resources

Back to top

How to Use Cause-and-Effect Analysis

Although several ways to construct a cause-and-effect analysis exist, the steps of construction are essentially the same.

Step 1. Agree on the problem or the desired state and write it in the effect box. Try to be specific. Problems that are too large or too vague can bog the team down.

Step 2. If using a tree or fishbone diagram, define six to eight major categories of causes. Or the team can brainstorm first about likely causes and then sort them into major branches. The team should add or drop categories as needed when generating causes. Each category should be written into the box.

Step 3. Identify specific causes and fill them in on the correct branches or sub-branches. Use simple brainstorming to generate a list of ideas before classifying them on the diagram, or use the development of the branches of the diagram first to help stimulate ideas. Either way will achieve the same end: use the method that feels most comfortable for the group. If an idea fits on more than one branch, place it on both. Be sure that the causes as phrased have a direct, logical relationship to the problem or effect stated at the head of the fishbone.Each major branch (category or step) should include three or four possible causes. If a branch has fewer, lead the group in finding some way to explain this lack, or ask others who have some knowledge in that area to help.

Step 4. Keep asking "Why?" and "Why else?" for each cause until a potential root cause has been identified. A root cause is one that: (a) can explain the "effect," either directly or through a series of events, and (b) if removed, would eliminate or reduce the problem. Try to ensure that the answers to the "Why" questions are plausible explanations and that, if possible, they are amenable to action.Check the logic of the chain of causes: read the diagram from the root cause to the effect to see if the flow is logical. Make needed changes.

Step 5. Have the team choose several areas they feel are most likely causes. These choices can be made by voting to capture the team’s best collective judgment.Use the reduced list of likely causes to develop simple data collection tools to prove the group’s theory. If the data confirm none of the likely causes, go back to the cause-and-effect diagram and choose other causes for testing.

CautionRemember that cause-and-effect diagrams represent hypotheses about causes, not facts. Failure to test these hypotheses—treating them as if they were facts—often leads to

implementing the wrong solutions and wasting time. To determine the root cause(s), the team must collect data to test these hypotheses. The "effect" or problem should be clearly articulated to produce the most relevant hypotheses about cause. If the "effect" or problem is too general or ill defined, the team will have difficulty focusing on the effect, and the diagram will be large and complex.It is best to develop as many hypotheses as possible so that no potentially important root cause is overlooked. Be sure to develop each branch fully. If this is not possible, then the team may need more information or help from others for full development of all the branches.

Fishbone DiagramDeli.cio.us   Digg

Feedback EMail

The fishbone diagram is a graphical method for finding the root causes of an effect.

The effect can be either a negative one, such as a process defect or an undue

process variation; or a positive one, such as a desired process outcome. Kaoru

Ishikawa, a famous Japanese consultant developed this method in the 1960s. It is

also known as "Cause-and-Effect Diagram" or "Ishikawa Diagram". The balance

chapter details the steps required to construct a fishbone diagram. The example

effect to illustrate the concept is "high petrol consumption in a car".

Step I

Identify the process effect to be analysed. Develop an Operational Definition to

ensure that it is clearly understood. Write the effect in a box on the right side and

draw a horizontal arrow from left to right that touches the box as illustrated in the

figure below.

Step II

Identify the main categories of causes resulting in the effect under consideration.

These categories can easily be selected from the applicable six key process

elements. These process elements are people, environment, material, method,

machinery, and measurement. Add selected categories in the diagram as

illustrated in the following figure.

Step III

Identify as many causes under each category and add them to the corresponding

category. Detail each cause further (recursively) to the lowest level possible.

Deli.cio.us   Digg

Feedback EMail

Analyse this diagram to identify the causes that require deeper investigation. As

fishbone diagram identify only potential causes, it may be a good idea to use a

Pareto Chart to determine the cause(s) to focus on first.

You can manage,  what you can measure;You can measure,  what you can define;You can define,  what you understand.

Applying the Fishbone diagram and Pareto principle to DominoPart 1

Level: IntroductoryDhanasekar Dhandapani (dhanasekar.dhandapani@wipro.com), Lotus Notes consultant, Wipro Technologies21 Jun 2004The Fishbone diagram is a simple problem-analysis tool that you can use to analyze Lotus software-related issues. This article, part one of two, introduces you to the Fishbone diagram and as an example, applies it to an actual Notes/Domino issue.

In any organization problem analysis and management tools are crucial to success. In software quality management, there are two tools that you may want to make use of: the Fishbone diagram and the Pareto principle. In this two-part series, we introduce you to the problem analysis tool known as the Fishbone diagram and to the management principle known as the Pareto principle. We discuss how these techniques are relevant to Notes/Domino and how to use them through examples. The purpose of the Fishbone diagram is not to find solutions to Notes/Domino-related problems, but to determine the root cause--module, design element, or application--of a problem. The article is intended for experienced Notes application developers and Domino administrators with little or no knowledge of the Fishbone diagram.

About the Fishbone diagramThe Fishbone diagram is also known as the cause and effect diagram, the root cause analysis, and the Ishikawa diagram, named after its originator Kaoru Ishikawa, the Japanese quality pioneer. It is generally called the Fishbone diagram because the diagram resembles that of a fishbone. In simple terms, Fishbone is brainstorming in a structured format. The technique uses graphical means to relate the causes of a problem to the problem itself, in other words, to determine cause and effect. The diagram focuses on the causes rather than the effect. Because there may be a number of causes for a particular problem, this technique helps us to identify the root cause of the problem in a structured and uncomplicated manner. It also helps us to work on each cause prior to finding the root cause.This technique is very much applicable to the software industry and to Notes and Domino. There are problems in Notes-based applications and in Domino administration in which root cause analysis is important. For example, replication problems can occur for a number of reasons, including replication settings, database access levels, document security, or other factors. The Fishbone diagram helps us to arrive at the root cause of a problem through brainstorming.

When to use itYou may find it helpful to use the Fishbone diagram in the following cases:

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

When not to use itOf course, the Fishbone diagram isn't applicable to every situation. Here are a just a few cases in which you should not use the Fishbone diagram because the diagrams either are not relevant or do not produce the expected results:

The problem is simple or is already known. The team size is too small for brainstorming. There is a communication problem among the team members. There is a time constraint; all or sufficient headcount is not available for brainstorming. The team has experts who can fix any problem without much difficulty.

Back to top

Document options

Rate this page

Relevance of the Fishbone diagram to Notes application supportMost of you have experience in supporting and administering Domino. You have probably solved problems ranging from the simple to the complex that take anywhere from a few minutes to hours or even days to resolve. For the problems that stumped you most, you may have approached your colleagues, friends, technical architects, or others for help. You might even have uncovered a lot of potential causes for a problem without knowing their actual relevance to the problem context, and you might have analyzed each and every one of them. This can lead to increased time taken to find the root cause of the problem.Using the Fishbone diagram, you can approach the same problem in a more systematic and uncomplicated manner. After listing the possible causes for a problem, you and your team analyze each one carefully, giving due importance to statements made by each team member during the brainstorming session, accepting or ruling out certain causes, and eventually arriving at the root cause of the problem. In general, Fishbone diagrams give you increased understanding of complex problems by visual means of analyses.

How to construct a Fishbone diagramHere 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:

Figure 1. Fishbone diagram, Step one

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.

MaterialMaterial 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.

Back to top

Evaluate, decide, and take actionIt 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.

ExampleThe Fishbone diagram can be used to troubleshoot Domino administration and Notes application-related problems. Some complicated administration issues, such as SMTP mail routing, replication, server crashes, and so on, and application issues, such as database replication, can be better studied and analyzed using Fishbone diagrams.Let's look at how to apply the Fishbone technique to find the root cause of a Domino server crash. The idea in this example is to explain how to apply the Fishbone technique rather than how to identify the cause of the crash because a crash may happen for a number of reasons.Define the problem In this example, the problem is already defined--Domino server crash. The team knows that the crash occurred because the server ran out of resources, but an analysis is still needed to determine why the resources are running low. The leader starts drawing the Fishbone diagram by mentioning the problem in the fish head as shown below. The time of crash, frequency of crash, and crash details are all gathered prior to the brainstorming session.Brainstorm The team now is involved in the brainstorming session to identify the root cause of the problem. We used the categories listed above as our starting point of discussion to identify the major causes first. We analyzed each category and their relevance to the problem. The following lists each of categories that figured in our discussion and whether it was accepted as a major cause.

Method The method or way of doing things was considered by the team as a possible cause. Because programs written for the Domino environment using @formulas, LotusScript, Java, and so on may cause server overload (and therefore a crash), it was considered a major possible cause.

Men The team discussed the possibility of people being the cause of the problem. It is accepted as a major cause because a few less experienced administrators handled the mail and application servers. Inexperience, negligence, and complacency are some reasons for mistakes that can eventually lead to a server crash.

Management The project management team was not a possible cause because the issue here is more technical rather than managerial. The team unanimously ignored this category.

Material The team also ignored this category because material is not relevant to the problem.

Machine The team discussed the machine being a possible cause. Insufficient hardware configuration may be a problem leading to overloading and finally to server breakdown. The team accepted it as a major possible cause.

Technology The team discussed the impact of the technology that has been used. Issues like anti-virus software, third-party tools, and software problem reports on the current Domino releases were pointed out, so technology was also identified as a possible cause.

Procedure The team discussed the various procedures used within the Domino environment. Procedures used in user registration, application roll-out, and migration were analyzed. The team decided that procedure could not be a possible cause. The team thought that if procedure was the reason, then the server might have crashed while executing the procedures. That didn’t happen, so this category was ruled out.

Policy The team discussed various policies used in the organization for the Domino environment. Policies are quite specific to every organization, so a problem in an organization due to policy is not applicable to other organizations. Policies like scheduled agents, their schedules, servers, and APIs are studied as potential causes. We considered policy as a major cause.

At the end of the preliminary brainstorming session, we constructed the following Fishbone diagram.

Figure 2. Fishbone diagram, Step two

All major causes identified above are connected as the bones in the Fishbone diagram.Identifying the causes The next step involved continuing to refine the major causes to find the secondary causes or the various causes occurring under each of the major categories listed above.

Method The team looked into the tasks (agents) running at the time of the crash. They analyzed the code of each of these tasks (agents) and studied their impact on server performance.

Men The team felt that the less experienced administrators may have overloaded the server by forcing replication or mail routing, which leads to higher workload on the server and eventually brings the server down.

Machine The machine was Windows-based and was sufficiently powerful to handle the workload. To date, no issue was reported of server inefficiency, and the administrators were confident that it was not the cause. The team decided to ignore this category, but kept it as the last option to revisit at.

Technology The administrators analyzed bugs/issues with the current release (in our case, it was Domino 6.5). They also considered other tools like Norton AntiVirus software and its release installed on the server machine and a third-party tool that makes a copy of all outgoing mail messages.

Policy The team discussed agent scheduling, tasks that ran on the server, and C/C++/Java API codes used for specialized operations.

At the end of this session, all possible causes under each category were identified and connected as bonelets in the Fishbone diagram. Rather than analyze individual secondary causes, the team stopped the brainstorming session at this stage. The team felt that sufficient information was available to identify the root cause of the problem. The team studied the time of crash, frequency of the crash, and the crash information stored in a file. At the end of the session, the Fishbone diagram looked like the following. Causes from each category were constructed as bonelets in the diagram. The team went about analyzing individual causes.

Sometimes the Fishbone diagram can become very large because the team may identify many possible causes. This make the diagram complex-looking. A simple and neat-looking Fishbone diagram may indicate that a thorough brainstorming is not done or that the team lacks sufficient knowledge about the problem domain. A good Fishbone diagram is one which is complete and has explored all the possibilities for a problem. The team should identify all possibilities to arrive at a good Fishbone diagram.Method The team discussed the two points listed above. Agent coding was done in LotusScript and Java. The team agreed that Java coding was very minimal and done at a basic level, so it could not be a problem. But they were suspicious about LotusScript code in the agents. It was identified as a potential cause.Men The team discussed with the less experienced administrators issues that occurred when the senior administrator was away, but none had occurred. The crash occurred while the senior administrator was present. Men were not the likely cause.Policy The schedule of the various agents was checked. There was no overscheduling of agents, so the server was not overloaded. A couple agents employed API code, but minimally. The agents ran without problem for the past year. The team assumed that these issues could not be potential cause.Technology The team analyzed the log of the anti-virus software and the third-party tool used, but nothing specific was reported. Also, the tools had been running without a problem for the past two years. The team assumed that technology could not be the potential cause. The Domino version was upgraded recently, and the team was suspicious about it. The team analyzed the SPRs/QMRs/QMUs for any reported bugs, but none were found.Now the team was left with one important potential cause: the LotusScript code of the scheduled agent. The agent had approximately 5,000 lines of code involving lots of loops and checks. A FOR loop ran almost 5,000 times, and each time it ran, 100 IF statements were evaluated. This leads to a performance impact on the server machine and eventually caused it to crash. The team had identified the root cause.

Decide and take actionThe team decided to change the IF statements to SELECT CASE. The code was modified and scheduled to run at the same time as before. This time, however, there were no server crashes. The agent completed successfully.

Back to top

ConclusionThe above example details the application of the Fishbone diagram in identifying the root cause of a software problem. We hope that you find this method useful in diagnosing your own software problems. You can apply the Fishbone diagram to any number of issues that your IT organization encounters. In part two of our series, we cover the Pareto principle and how it can help you to manage problems that you determined using this analysis tool.

 

Cause & Effect Diagram

TopicsDiscover underlying causesUse it when you start investigating a problemHow to draw a CE diagramDifferent types of CE diagramProduct classification typeCause enumeration typeWhat to do with the completed CE diagramGood and bad CE diagramsOther references

  Discover underlying causes

The Cause & Effect (CE) diagram, also sometimes called the ‘fishbone’ diagram, is a tool for discovering all the possible causes for a particular effect. The effect being examined is normally some troublesome aspect of product or service quality, such as 'a machined part not to specification', 'delivery times varying too widely', 'excessive number of bugs in software under development', and so on, but the effect may also relate to internal processes such as 'high rate of team failures'.

The major purpose of the CE Diagram is to act as a first step in problem solving by generating a comprehensive list of possible causes. It can lead to immediate identification of major causes and point to the potential remedial actions or, failing this, it may indicate the best potential areas for further exploration and analysis. At a minimum, preparing a CE Diagram will lead to greater understanding of the problem.

The CE Diagram was invented by Professor Kaoru Ishikawa of Tokyo University, a highly regarded Japanese expert in quality management. He first used it in 1943 to help explain to a group of engineers at Kawasaki Steel Works how a complex set of factors could be related to help understand a problem. CE Diagrams have since become a standard tool of analysis in Japan and in the West in conjunction with other analytical and problem-solving tools and techniques.CE Diagrams are also often called Ishikawa Diagrams, after their inventor, or Fishbone Diagrams because the diagram itself can look like the skeleton of a fish.

Use it when you start investigating a problem

Construct a CE Diagram whenever you need to investigate the causes or contributing factors for an effect (be it a quality characteristic or other outcome) which is of concern to you. This will most likely be after you have conducted a general investigation of problems for a particular function, product, or service, and ranked them using a Pareto Chart. The effect ranked highest provides the starting point for a CE Diagram.

For example, you may just have completed an investigation of all the reasons recorded for goods being returned by customers and found that the highest incidence relates to incorrect goods being sent. A CE Diagram can be constructed to explore the possible causes for this.

Developing a CE Diagram in a team meeting is a very effective technique for,

concentrating team members' attention on a specific problem pooling, and reflecting back, team thinking

constructing a picture of the problem at hand without resorting to the tight discipline of a flowchart

How to draw CE diagram

This is a three step process.

Step 1

Write down the effect to be investigated and draw the 'backbone' arrow to it. In the example shown below the effect is 'Incorrect deliveries'.

Step 2

Identify all the broad areas of enquiry in which the causes of the effect being investigated may lie. For incorrect deliveries the diagram may then become:

For manufacturing processes, the broad areas of enquiry which are most often used are Materials (raw materials), Equipment (machines and tools), Workers (methods of work), and Inspection (measuring method).

Step 3

This step requires the greatest amount of work and imagination because it requires you (or you and your team) to write in all the detailed possible causes in each of the broad areas of enquiry. Each cause identified should be fully explored for further more specific causes which, in turn, contribute to them.

You continue this process of branching off into more and more directions until every possible cause has been identified. The final result will represent a sort of a 'mind dump' of all the factors relating to the effect being explored and the relationships between them.

Different types of CE Diagram

There are three different types of CE Diagram. The basic type explained above is called the Dispersion analysis type. The other two are the Production process classification type and the Cause enumeration type.

Production classification type

This type differs from the basic type above in that each discrete stage in the production process leading up to the effect being examined is shown along the main arrow or 'backbone' of the diagram. Possible causes are then shown as branches off these as shown in the illustration overleaf.

This type of CE Diagram is often easier to construct and understand because those involved are already familiar with each of the production steps identified.

Cause enumeration type

This is not so much a different type of diagram but a different method of constructing a diagram. Instead of building up a chart gradually (starting with the 'backbone', deciding broad areas, then adding more and more branches), you postpone drawing the chart and simply list all the possible causes first. Then draw the chart in order to relate the causes to each other. This method has the advantage that the list of possible causes will be more comprehensive because the process has a more free-form nature. The disadvantage is that it is more difficult to draw the diagram from this list rather than from scratch.

This method of drawing a CE Diagram can be used in conjunction with Brainstorming by using it to distil the brainstorm output down into a logical and useable set of information.

What to do with the completed CE diagram

Most of the value of CE Diagrams lies in the process used to produce them. This process leads to ideas and insights into the problem which you would not otherwise have had, and which will give you leads for further investigation or for experimenting with possible solutions.

When developed by a team, the CE Diagram becomes a sort of 'shared conceptual space' in which the problem is examined in common by all team members with the results that,

possibilities will be uncovered which would otherwise have remained hidden all team members will benefit from each other's contribution and develop a common understanding

of the problem

Since it takes some time to get to the heart of most problems, the CE Diagram can also be used as a working document which is changed as new data is collected and different solutions tried.

Good and bad CE diagrams

A good CE diagram is one which explores all possibilities so it is likely to be large and complex-looking as twig after twig sprouts for each new related idea noted down. Be suspicious of CE Diagrams with few factors, or which are neat and well ordered. These may reflect a lack of knowledge of the situation, or show that the effort to draw the diagram was not creative and exhaustive enough.

Other references

Kaoru Ishikawa, Guide to Quality Control, Asian Productivity Organisation, 1991

 

  Please see our new web site for further articles on knowledge management, operational effectiveness, compliance and quality management.

Fishbone Diagram

From Mycoted

Jump to: navigation, search

A to Z of

Creativity Techniques

Previous TechniqueFalse Faces

Next TechniqueFive Ws and H

The fishbone diagram (see below) originally developed by Professor Kaoru Ishikawa, is often referred to as an Ishikawa Diagram. The technique can help to structure the process of identifying possible causes of a problem (see also Causal Mapping)

The diagram encourages the development of an in depth and objective representation ensuring all participants keep on track. It discourages partial or premature solutions, and shows the relative importance and inter-relationships between different parts of a problem.

The method is ideally organized over a number of meetings, enabling the team to become deeply immersed in the problem. Fresh suggestions regarding possible causes can arise during the break and members are more likely to forget who originated every idea, thus making subsequent discussions less inhibited.

The procedure is as follows:

On a broad sheet of paper, draw a long arrow horizontally across the middle of the page pointing to the right, and label the arrowhead with the title of the issue to be explained. This is the ‘backbone’ of the ‘fish’.

Draw spurs coming off the ‘backbone’ at about 45 degrees, one for every likely cause of the problem that the group can think of; and label each at its outer end. Add sub-spurs to represent subsidiary causes. Highlight any causes that appear more than once – they may be significant.

The group considers each spur/sub-spur, taking the simplest first, partly for clarity but also because a good simple explanation may make more complex explanations unnecessary.

Ideally, it is eventually re-drawn so that position along the backbone reflects the relative importance of the different parts of the problem, with the most important at the head end.

Circle anything that seems to be a ‘key’ cause, so you can concentrate on it subsequently.

Retrieved from "http://www.mycoted.com/Fishbone_Diagram"