Fishbone Diagram

Revision as of 13:33, 20 February 2021

Abstract

The Fishbone Diagram is a helpful tool used in root cause analysis and is used to figure out cause-and-effect and to breakdown the contributing factors of an issue. The tool was originally invented by Professor Kaoru Ishikawa, a Japanese organizational theorist and pioneer of quality management, in the 1960s and published in his book “Introduction to Quality Control”. The tool was originally known as Ishikawa Diagrams, however due to its resemblance of a fish skeleton it is now commonly referred to as the Fishbone Diagram. The tool’s original intention was to analyze quality control; however, it has since then been applied in many situations and now mostly turned towards identification of root causes for problems.

The main objective of a Fishbone Diagram is to break down and organize the causes of an issue to reveal the elements that have the greatest impact. By grouping these causes into different categories means that you can think about the different element of the problem as separate from the overall issue. From here it should be possible to identify one or two of these causes to have the greater impact, which will then lead to the root of the problem. This structure also allows you to tackle smaller issues which have a large impact on the problem and thus making problem solving more manageable. This has made it a valuable tool for uncertainty and risk identification as it can help identifying how to best handle potential risks.

This article aims to provide an overview of how the diagram is best used as a risk management tool as well as discussing application and limitations. Hereby also mentioning different tools that can be used in combination with the Fishbone Diagram to strengthen the risk management of a project.

Big idea

While the Fishbone Diagram was originally invented in order to analyze quality control, the tool has today found more common use in risk management and more specifically; risk identification [1]. Risk identification tools are used throughout project, program and portfolio management domains; however, the large scale of programs and portfolios leads to less specific answers, which is why the word “cause” is often used instead of “root cause” as within complex environments, there is usually not a single cause that impacts the program/portfolio (Within the project management domain the term “root cause” is still applicable though). In general, there are multiple causes that can impact the program/portfolio system through various sections and should be dealt with from a holistic approach [The Standard for Portfolio Management — Fourth Edition].

Risk Management

In order to fully understand the purpose and application of the Fishbone Diagram it is important to know the importance of risk management for the success of a project/program/portfolio. Risk management is a branch within the uncertainty perspective of project management and an individual risk is an uncertain event that potentially can have a positive or negative effect on one or more objectives [DOING projects], [PMI standard for Risk Management]. Uncertainty is inherent in the nature of portfolios, programs, and projects. Risk arises out of uncertainty and generates uncertainty. The more risks one can identify, the more uncertainty is indicated [PMI Standard for Risk Management]. These risks represent the exposure of the organization and its stakeholders to the consequences of uncertainty and can potentially define the success or failure of a project depending on how it is managed. Uncertainty is inherent in the nature of portfolios, programs, and projects. Risk arises out of uncertainty and generates uncertainty. The more risks one can identify, the more uncertainty is indicated [PMI Standard for Risk Management].

Risk management is a holistic approach that extends through organizational levels and is exercised to handle the natural uncertainty inherent in projects/programs/portfolios with the aim of supporting organizational objectives, realization of the strategic vision, and creation of value. Risk management has a large influence in decision making throughout the project, program and portfolio domains, which through systematic use of management tools can suggest actions for countering threats and exploiting unknown opportunities.

The multiple different approaches and perceptions regarding risk management in each portfolio, program, and project management domain feed into one another in an iterative, interactive, and dynamic manner. Risks may be interconnected, have dependencies, and interact via feedback loops as shown in figure XXX [PMI Standard for Risk Management].

Risk Identification

In the risk identification section this article will mainly focus on risk identification in project management, however many of the tools and thoughts discussed in this section can be applied to both program and portfolio management. Risk identification is process of uncovering individual project uncertainty as well as sources of overall project risk while documenting the characteristics. The main benefit of identifying the risks of a project is that the process maps out potential dangers to the project while also providing information so that the project team can develop the appropriate response to the identified risk. This process is performed iteratively throughout the project. Popular inputs, tools and techniques, and outputs of the process are illustrated in the figure XXX. [Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide)].

In risk identification Fishbone Diagrams are typically used for root cause analysis. Root cause analysis is typically used to discover the root of the causes that lead to a problem/challenge with the main objective of developing preventive actions. It can be used to map potential project risks by investigating a problem statement and then explore which threats might stimulate the investigated problem. However, root cause analysis can also be used to find potential opportunities within a project by starting with a beneficial problem statement and explore which events may trigger that benefit. [Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide)]

Figure XXX depicts the structure of the Fishbone Diagram, where the problem statement or effect is located in the “fish head”. This could be “customers complain of poor service”. From here multiple “fish bones” represent different causes to the problem statement, which could be “staff” or “long waiting time”. The causes are then split into sub-causes or “ribs”, which help further analyze and identify the causes that have the greatest impact, which will then lead to the root of the problem. The process of making new "ribs" on the fish continues until the team agrees that the root cause has been reached. By dissipating the problem into smaller more manageable issues, which have a large impact on the problem, it makes the problem-solving process easier and more effective. [2]

In order to effectively solve the root causes identified through the Fishbone Diagram and develop preventive actions, it is important to evaluate the probability and investment required in order to solve the problem. For this process the project team should focus on causes that are “Very High” or “High” in probability and “Very High” or “High” in impact” in the Probability/Impact, which will be discussed in the Application chapter [DOING PROJECTS]. This exercise is carried out to avoid wasting time and effort developing preventive actions for a cause that is either unlikely to happen or expensive/impossible to treat.

Application

The following section will describe how to use the Fishbone Diagram in a step-by-step guide, which should fully equip the reader with all the necessary information to apply the method after reading this article.

Step 1: Identify the problem or opportunity

The first step in the application of the Fishbone Diagram is to write down the problem statement or effect that you wish to analyze. It is important to think about who is involved, what the problem is, and when and where it occurs. Then write this problem statement in a box/head on the right-hand side on a blank surface. This could be a whiteboard, large sheet of paper or electronically depending on preferences. From the box with the problem statement draw a line across the paper horizontally. This arrangement will be the head and the spine of the fish and will provide the main structure for brainstorming ideas.

Then, write the problem in a box on the left-hand side of a large sheet of paper, and draw a line across the paper horizontally from the box. This arrangement, looking like the head and spine of a fish, gives you space to develop ideas. [3]

Step 2: Identify the main causes involved

The next step is to identify the causes or factors that may be involved. Potential causes could be systems, equipment, materials, external forces, people involved with the problem, and so on. Try to think of as many causes as possible. Later, causes commonly used for tackling problems from specific sectors will be introduced, but for now you should focus on your problem statement. Write down the identified causes and draw a line from each cause to the spine of the diagram. [4]

Step 3: Identify possible sub-causes

For each of the main causes involved there will now be considered possible sub-causes. The sub-causes will be fitted into the diagram by drawing horizontal lines from the “bones”. The number of necessary sub-causes and level of detail is largely up to the project team and the complexity of the problem statement. The process of dividing causes into sub-causes can be iterated an infinite amount of times or until the project team has reached the desired level of detail. [5]

Step 4: Finishing touches

All that is left to do is finish the diagram up with a tail and you are ready to analyze the diagram.

Step 5: Analysis of the Fishbone Diagram

At this point the Fishbone Diagram should be complete and showing all of the possible causes to the problem statement that the project team could think of. It is now possible to begin the analysis diagram in order to identify the most important causes. Depending on the complexity and importance of the problem, you can now investigate the most likely causes further. This may involve setting up investigations, carrying out surveys, and so on. On the basis of this systematic approach, it is now possible to develop solutions to the root cause, which should be the goal of the cause analysis. [6]

This step-by-step guide can easily give the image that the construction of a Fishbone Diagram is a very linear process. However, it often happens that the project teams fill out a cause with sub-causes before making the next or once they have filled out all the causes recognize that some of the sub-causes from several of the causes are linked and creating a new cause “bone” especially for them is the most appropriate way of treating them. It is encouraged that the teams go back in steps to alter the diagram. It means that the team has acquired new knowledge throughout the making of the diagram and is figuring out something new about the project.

Area of application

While this article has already covered the use of the Fishbone Diagram to identify root causes in great depth, it will now identify some of the most common application sectors and how the tool is modified and standardized in order to best accommodate the specific area of application. Figure XXX provides an overview of common uses and the possibilities of the Fishbone Diagram.

The three most common areas the Fishbone Diagram is used is manufacturing, services and product marketing, all three of which has adapted and modified the Fishbone Diagram in order to better suit their specific problem area and find common causes.

Manufacturing

When used for root cause analysis in the manufacturing sector, the Fishbone Diagram is often modified to fit the 5M Model:

• Man (people): including the physiology and psychology of those involved, as well as their performance and proficiency.

• Machine (equipment): including the design, manufacture, maintenance, reliability, performance, etc.

• Medium / measurement (environment, inspection): including weather, terrain, obstructions, lighting, etc.

• Mission (purpose): the reason these three factors are brought together.

• Management (leadership): the prevailing supervisory approach in terms of regulations, policies, procedures, and attitude involved in establishing, operating, maintaining, and decommissioning.

These have been expanded by some to include an additional three, and are referred to as the 8M Model:

• Material (includes raw material, consumables, and information)

• Method / mother nature (process, environment)

• Maintenance

Services

In the service industry the Fishbone Diagram is build up around the 4S Model:

• Surroundings

• Suppliers

• Systems

• Skill

Product marketing

The 8P Model is commonly used for identifying crucial attributes for planning in product marketing and is also often used in root-cause analysis as causes for the Fishbone Diagram:

• Product (or service)

• Price

• Place

• Promotion

• People (personnel)

• Process

• Physical evidence (proof)

• Performance

Combination tools

The Fishbone Diagram can be used in combination with many different tools used within project, program and portfolio management. It is naturally used in conjunction with Brainstorming as this tool is used when coming up with new causes and sub-causes. A Mind Map is also naturally occurring when using the Fishbone Diagram as it helps structure and link the causes and sub-causes from the Brainstorming into groups, which can then be inserted into the Fishbone Diagram as the “bones”. Another popular tool to use in combination with the Fishbone Diagram, is the 5 Why’s; a tool that forces the user into thinking of five causes, give or take one, to a given problem until the root causes have been found. However, knowing when to stop is important, or else the project team risks “analysis by paralysis” and frustration. Use common sense. A useful indicator of when to stop generating new causes, is when the cause is more than one level of management removed from the group [7].

The Probability/Impact Matrix is often used together with the Fishbone Diagram, and while the other tools presented in this chapter are related to generating ideas for new causes, the Probability/Impact Matrix is a tool that helps structuring which causes should be treated and thus identifying the causes with the greatest impact [DOING PROJECTS]. When used, the project team should focus on causes within the red and orange areas of the Probability/Impact Matrix illustrated in figure XXX.

Limitations

critically reflect on the tool/concept/theory and its application context. What can it do, what can it not do? Under what circumstances should it be used, and when not? How does it compare to the “status quo” of the standards – is it part of it, or does it extent them? Discuss your article in the context of key readings / resources provided in class. Substantiate your claims with literature

Depth of treatment: Is the article interesting for a practitioner or academic to read? Does it make a significant contribution beyond a cursory web search?

Annotated bibliography

Provide key references (3-10), where a reader can find additional information on the subject. The article MUST make appropriate references to the and reference material provided in class – either incorporating it as a source, or critically discussing aspects that are missing from it but covered by this article. Summarize and outline the relevance of each reference to the topic (around 100 words per reference). The bibliography is not counted in the suggested 3000 word target length of the article.

Critical reflection on status quo of standards: To what degree are the core arguments of your wiki article covered by the P/P/P standards and literature? To what degree does your article extend (or maybe contradict) the status quo? Use of reference material provided in class: Elements from the reference material were appropriately incorporated into the article. Annotated bibliography: Does the article properly cite and acknowledge previous work (reference material provided, and appropriate other sources where necessary)? Does it briefly summarize the key references at the end of the article?

References

1. Geraldi, Joana, et al. Doing Projects. A Nordic Flavour to Managing Projects: DS-Handbook 185:2017. Dansk Standard, 2017

2. Project Management Institute, Inc. (PMI). (2019). Standard for Risk Management in Portfolios, Programs, and Projects. Project Management Institute, Inc. (PMI). Retrieved from [8]

3. MIHAELA LOREDANA, E. CO BI CI. “THE ANALYSIS OF CAUSES AND EFFECTS OF A PHENOMENON BY MEANS OF THE ‘FISHBONE’ DIAGRAM.” Analele Universităţii Constantin Brâncuşi Din Târgu Jiu : Seria Economie, Academica Brâncuşi, 2017.

4. Ipsen, Christine, et al. The Fishbone Workshop: How to Transform. 2018.

5. Walsh, Ronan; Fishbone Diagram - How to Make and Use a Fishbone Diagram, http://lbspartners.ie/fishbone-diagram/ , (August 3, 2017)

6. Cause and Effect Analysis - Identifying the Likely Causes of Problems, https://www.mindtools.com/pages/article/newTMC_03.htm