Fishbone Diagram

From apppm
Revision as of 13:15, 20 February 2021 by S16389 (Talk | contribs)

Jump to: navigation, search

Contents

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

Cascading Risk ManagementGHW.png



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

provide guidance on how to use the tool, concept or theory and when it is applicable

Does the article provide hands on guidance? Can the reader (at least prototypically) apply the method after reading the article?


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 [3]

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

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox