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 causeand-effect analysis stimulates and broadens thinking about potential or real causes and

facilitates further examination of individual causes. Because everyones 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 teams 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 oftenused 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 WhysA second type of cause-andeffect 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 Whys. 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 patients chart. Question 4: Why wasnt the patients chart complete? Answer 4: Because the doctors assistant had not entered the latest laboratory report.

Question 5: Why hadnt the doctors 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 teams best collective judgment.Use the reduced list of likely causes to develop simple data collection tools to prove the groups theory. If the data confirm none of the likely causes, go back to the cause-and-effect diagram and choose other causes for testing. Caution Remember that cause-and-effect diagrams represent hypotheses about causes, not facts. Failure to test these hypothesestreating them as if they were factsoften 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 DIAGRAM
Deli.cio.us Feedback Digg 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 Feedback

Digg 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 Domino

Part 1

Level: Introductory Do Dhanasekar Dhandapani (dhanasekar.dhandapani@wipro.com), Lotus Notes consultant, Wipro Technologies 21 Jun 2004 The 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. Ra 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. Fishbone diagram is not to find solutions to Notes/Domino-related problems, but to determine the root ca design element, or application--of a problem. The article is intended for experienced Notes application de Domino administrators with little or no knowledge of the Fishbone diagram.

About the Fishbone diagram

The Fishbone diagram is also known as the cause and effect diagram, the root cause analysis, and the Is named after its originator Kaoru Ishikawa, the Japanese quality pioneer. It is generally called the Fishbon the diagram resembles that of a fishbone. In simple terms, Fishbone is brainstorming in a structured form uses graphical means to relate the causes of a problem to the problem itself, in other words, to determin The diagram focuses on the causes rather than the effect. Because there may be a number of causes for problem, this technique helps us to identify the root cause of the problem in a structured and uncomplica 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 prob based applications and in Domino administration in which root cause analysis is important. For example, problems can occur for a number of reasons, including replication settings, database access levels, docum other factors. The Fishbone diagram helps us to arrive at the root cause of a problem through brainstorm

When to use it
You 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 s consuming The problem is very complicated and the project team cannot identify the root cause

When not to use it

Of course, the Fishbone diagram isn't applicable to every situation. Here are a just a few cases in which y the Fishbone diagram because the diagrams either are not relevant or do not produce the expected resul

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

Relevance of the Fishbone diagram to Notes application support

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

How to 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 caus identified. Usually the project manager or technical architect--we will refer to this role as the leader throu the article--decides which problem to brainstorm. He has to choose the problems that are critical, that ne 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 p the problem in a square box to the right side of page. She draws a straight line from the left to the probl arrow pointing towards the box. The problem box now becomes the fish head and its bones are to be laid 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 domai useful to focus on logically related items of the problem domain and to represent them in the Fishbone di convey the problem solving methodology. There are quite a few tools available that can help us in this re

Affinity Chart Organizes facts, opinions, ideas, and issues into a natural grouping. This grouping is in turn used diagnosing complex problems. Brainstorming Gathers ideas from people who are potential contributors. This process is discussed further in the Check sheet Acts as a simple data recording device that helps to delineate important items and characteristics 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

No single methodology is applicable to all problem domains. Based on experience and study, you can ide analyze, and maintain the methodology and the related problem domains. In the example given later in t brainstorming as the problem solving methodology. Categorize When you apply the Fishbone technique to business problems, the possible causes are usually classified i

Method Man Management

Measurement Material Machine

Though the above are a few important problem categories, during the brainstorming session, the team is come up with all possible categories. The above categories give the team direction to help find the possib the categories listed above may or may not be applicable to software or to Domino in particular. Let's loo category. Category Method Man Management Measurement Description

Methods are ways of doing things or the procedures followed to accomplish a task. A typic Method category is not following instructions or the instructions are wrong.

People are responsible for the problem. The problem may have been caused by people wh inexperienced, who cannot answer prompted questions, and so on.

Management refers to project management; poor management decisions, such as upgradi simultaneously rather than deploying changes serially may cause technical problems.

Measurement refers to metrics that are derived from a project. Problems may occur if mea wrong or the measurement technique used is not relevant.

Material

Material basically refers to a physical thing. A bad diskette is one typical example. Softwar handle errors caused by bad material, for instance a bad backup tape, so while material m likely cause, it is a possible cause.

Machine

A machine in software usually refers to the hardware, and there are a lot of possibilities th 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 a causes, finally arriving at the root cause. The team can either analyze each of the above categories for po look into other categories (not listed above). Identify causes While brainstorming, the team should strive toward identifying major causes (categories) first, which can discussed, and then secondary causes for each major cause can be identified and discussed. This helps th 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 Fishb are represented as slanted lines with the arrow pointing towards the backbone of the fish. See Figure 2 la Sometimes it is difficult to arrive at a few major causes. The team may come up with a lot of causes, whi brainstorming more difficult. In this case, the leader can assign 10 points to each team member for each let them assign the rating (from 1 to 10, 10 being most likely cause) to each cause. After everyone on th the causes, the project manager totals each of the causes and ranks them based on their ratings. From t 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 identified, each one of them is discussed in further detail with the team to find out the secondary causes. secondary causes are further discussed to obtain the next level of possible causes. Each of the major cau 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 complete. However, the team has enough information to begin discussing the individual causes and to an relevance to the problem. The team can use analytical, statistical, and graphical tools to assist in evaluat causes. The Pareto principle (explained in part two of this article series) is also used to find the elements problems and to list them as major causes in the Fishbone diagram. Software metrics that are obtained d support can also be used here for further assistance. Back to top

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 m into consideration. Also, the major causes can be ranked in order with the most likely cause at the top of After the evaluation process is complete, the action plan has to be decided. If one possible root cause is i

action plan has to be derived to rectify it. Sometimes, it may be difficult to arrive at the root cause; there 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 permanently. If there are a few possible root causes, all the action plans are to be executed, and the mo is identified and fixed.

Example

The Fishbone diagram can be used to troubleshoot Domino administration and Notes application-related p complicated administration issues, such as SMTP mail routing, replication, server crashes, and so on, and 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 id is to explain how to apply the Fishbone technique rather than how to identify the cause of the crash beca 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 oc server ran out of resources, but an analysis is still needed to determine why the resources are running lo drawing the Fishbone diagram by mentioning the problem in the fish head as shown below. The time of c 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 listed above as our starting point of discussion to identify the major causes first. We analyzed each categ relevance to the problem. The following lists each of categories that figured in our discussion and whethe a major cause.

Method The method or way of doing things was considered by the team as a possible cause. Because prog the Domino environment using @formulas, LotusScript, Java, and so on may cause server overloa 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 m a few less experienced administrators handled the mail and application servers. Inexperience, neg 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 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 leading to overloading and finally to server breakdown. The team accepted it as a major possible Technology The team discussed the impact of the technology that has been used. Issues like anti-virus softwa tools, and software problem reports on the current Domino releases were pointed out, so technolo identified as a possible cause. Procedure The team discussed the various procedures used within the Domino environment. Procedures use registration, application roll-out, and migration were analyzed. The team decided that procedure c possible cause. The team thought that if procedure was the reason, then the server might have c executing the procedures. That didnt happen, so this category was ruled out. Policy The team discussed various policies used in the organization for the Domino environment. Policies to every organization, so a problem in an organization due to policy is not applicable to other orga like scheduled agents, their schedules, servers, and APIs are studied as potential causes. We cons 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 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 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 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, n reported of server inefficiency, and the administrators were confident that it was not the cause. T 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 considered other tools like Norton AntiVirus software and its release installed on the server machi 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 us operations.

At the end of this session, all possible causes under each category were identified and connected as bone diagram. Rather than analyze individual secondary causes, the team stopped the brainstorming session at this stag that sufficient information was available to identify the root cause of the problem. The team studied the t frequency of the crash, and the crash information stored in a file. At the end of the session, the Fishbone like the following. Causes from each category were constructed as bonelets in the diagram. The team we individual causes. Figure 3. Fishbone diagram, Step three

Sometimes the Fishbone diagram can become very large because the team may identify many possible c the diagram complex-looking. A simple and neat-looking Fishbone diagram may indicate that a thorough not done or that the team lacks sufficient knowledge about the problem domain. A good Fishbone diagram complete and has explored all the possibilities for a problem. The team should identify all possibilities to Fishbone diagram. Method The team discussed the two points listed above. Agent coding was done in LotusScript and Java. The team coding was very minimal and done at a basic level, so it could not be a problem. But they were suspiciou 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 admin but none had occurred. The crash occurred while the senior administrator was present. Men were not the Policy The schedule of the various agents was checked. There was no overscheduling of agents, so the server w A couple agents employed API code, but minimally. The agents ran without problem for the past year. Th 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 w the tools had been running without a problem for the past two years. The team assumed that technology potential cause. The Domino version was upgraded recently, and the team was suspicious about it. The t 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. approximately 5,000 lines of code involving lots of loops and checks. A FOR loop ran almost 5,000 times, ran, 100 IF statements were evaluated. This leads to a performance impact on the server machine and e to crash. The team had identified the root cause.

Decide and take action

The team decided to change the IF statements to SELECT CASE. The code was modified and scheduled to time as before. This time, however, there were no server crashes. The agent completed successfully. Back to top

Conclusion

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

Topics
Discover underlying causes Use it when you start investigating a problem How to draw a CE diagram Different types of CE diagram Product classification type Cause enumeration type What to do with the completed CE diagram Good and bad CE diagrams Other references

Cause & Effect Diagram

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 Technique False Faces Next Technique Five 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"