Revision as of 14:44, 20 February 2022

By Tobias Stabrand

This article will describe the Ishikawa Diagram and provide guidance on the tool's application in project management and its usefulness within the fields of risk- and quality management in projects. The article is part of the course 42433 Advanced Engineering Project, Program, and Portfolio Management F2022 at the Technical University of Denmark (DTU).

Abstract

Managing projects can be difficult, and projects will oftentimes run into problems no matter how well-planned they are. It is therefore of great importance to monitor projects throughout their lifetime, to identify risks and quality issues, as they can have a significant influence on the desired objective of the project. The Ishikawa Diagram is a tool that can help in identifying and analysing why a problem occurred, what happened, how it can be fixed as well as how to prevent it from happening again.^[1] The tool can both be applied in the pre-project activities to identify potential risks associated with a new project, during the project process, and in the post-project activities for evaluation and improvements of future projects.^[2]

The Ishikawa Diagram provides a structured approach to finding root causes to given problem´s and breaking down the contributing factors systematically into smaller elements. The systematic breakdown of the problem can make the greatest causes and effects more evident, and thus allow for an effective problem-solving process. The intention is to solve problems at their root rather than at a more superficial level, to prevent the problems from reoccurring.

The purpose of this article is to present the Ishikawa Diagram and its historical context and give hands-on guidance on how to apply the tool to manage risk- and quality problems in projects. Moreover, the article will discuss and explore the application of the Ishikawa Diagram in conjunction with other project management tools. Lastly, the article will present possible limitations of the tool.

The Big Idea: The Ishikawa Diagram

Professor Kaoru Ishikawa was an organisational theorist and was employed at the engineering faculty of the University of Tokyo. He was an expert in quality management and highly respected for his innovations, which includes the Ishikawa Diagram. Due to the diagram’s visual appearance, the tool is also known as the fishbone diagram, but it is also referred to as the cause-and-effect diagram. The methodology was introduced in the 1940s but first popularised in the 1960s.^[3] Kaoru Ishikawa pioneered quality management processes at the Kawasaki shipyards, where he was employed and is today seen as one of the founding fathers of modern management.^[4] Kaoru Ishikawa invented the tool for managing product quality issues and root cause investigation in the manufacturing industry. However, today the tool is applied to various problems and situations in several industries.

Project management is about coordinating activities to direct and control the project to achieve desired and agreed objectives.^[2] Controlling projects are about comparing actual performance to planned performance as well as analysing these differences to be able to take proper corrective and preventive actions. A project should be completed, and objectives are reached within an identified number of constraints, such as: Budget, duration, risk level, governmental requirements, and quality standards.^[2]

The Ishikawa Diagram can be used to identify risks and find the potential root causes of an expected problem in risk management.^[5] Risk management revolves around increasing the possibility of achieving the project’s objective. This is a responsibility that all project members have and involves identifying, assessing, treating, controlling, and responding to risks.^[2] If a risk is experienced or identified at any time during a projects’ life cycle it must be recorded. Thus, it can be assessed for probability and consequence and prioritised for further action.

Quality management in project management is also essential. Quality management focuses on increasing the likelihood that the outputs are aligned with the performance levels that are required to be met.^[2] Quality in projects is important to ensure the project’s deliverables and hence quality control activities can focus on the corrective, detective, and preventive actions. For this purpose, the Ishikawa Diagram is good at tracking, identifying, and diagnosing why quality issues occur during project execution and finding effective solutions.^[1] Furthermore, the tool is useful to take preventive actions.

The tools use of visual representation of the problem or effect makes it easier to absorb data and turn it into valuable information. Visualisation of a problem eases the identification- and helps trace the undesirable effect back to its root cause.^[5] Since the Ishikawa Diagram combines brainstorming and visualisation of the causes, it makes the tool very good at both identifying risks and ensuring quality in projects.

Application of The Ishikawa Diagram

The Project Team

To make use of the tool it is necessary and important to gather a team of relevant people since the value of the results are dependent on the team’s ability to identify the causes of the problem of concern. Relevant people are people with an in-depth understanding of the problem, great experience, people closest to where the problem is detected or expected to occur, and people with familiarity with similar problems.^[6] The Ishikawa Diagram facilitates a process where the team members are encouraged to communicate and discuss the problem and the possibility of the various causes. Thus, this sets requirements for the project team that are put together as well as make demands for active participation by the team members. The team members should therefore be selected according to their ability to discuss and review the problem.^[7]

It can, however, be difficult to choose the right team and the correct amount of people to be part of it. If a too small and less diverse team is gathered it will likely be easier for the group to find common ground, but it might result in an insufficient and non-in-depth Ishikawa Diagram where all causes and perspectives have not been assessed. Hence, the result and plan of action to prevent or solve the problem may be inadequate and the issue might show during the project anyway.

Putting together a bigger and more diverse team can on the contrary shed light on and identify many more possible causes of the problem, which can be an advantage. However, obtaining common ground is crucial and this can be more difficult if the diverse group of people have a focus on their area of interest and the related causes. Thus, it can be difficult for the team to prioritise which of the causes are most likely and most unlikely to occur. This can lead to some causes being overrated while other causes being underrated, due to the diverse nature of the project team. Eventually, the problem might occur during the project anyway because the prioritisation of the causes was done incorrectly, and the plan of action can fall short.

It is recommended to point out a facilitator, who can help narrow down the scope and provide guidance during the process. It should be the project manager and the facilitator that points out the relevant participants. However, it is recommended to hold the participation of management individuals at a minimum, as their presence may inhibit the other team members from speaking up.^[7] Active participation, information sharing, communication, and discussion of the problem in-depth are paramount to the result obtained using the tool. Thus, it is a fine balance that the facilitator and the project manager must manage, when putting together the team.

The Procedure

1. 1. Identify the Problem

After having gathered the right project team to conduct the Ishikawa Diagram, as described in the previous section, the “head” of the diagram is drawn to the right side e.g., on a whiteboard, addressing the problem or effect that needs to be solved. The problem is written precise and concise to ensure common ground among the team members. Therefore, the problem must, first, be critically discussed to define it correctly to obtain common ground among the participants. Some draw an arrow rather than just a line pointing at the problem to imply that the causes that are to be found are the reasons for the problem, but it has no functional importance.^[6]

FIGUR!!!

1. 2. Identify the Major Factors

Next, the team identifies 4-8 main causes to which they can group the sub-causes. The team can either come up with some main causes, that they find relevant to the problem if it is very specific, or they can make use of the 5 M’s, 4 S’s, or 8 P’s, depending on the type of problem. The 5 M’s, 4 S’s, or 8 P’s will be described in more detail later in the article. To allow sufficient space for each main cause and the related sub-causes the “bones” of the diagram should be placed at good distance, to ensure the space is not a limiting factor when performing the analysis.

FIGUR!!!

1. 3. Identify Possible Causes

Now the brainstorming process can start. Each “bone” and its corresponding main cause is examined and every sub-cause that the project team can think of will be added as a sub-branch to the diagram. The facilitator can write the things that the team member shout out or the use of sticky notes can be utilised. Using sticky notes can enable more introverted people to participate actively as not all might find it comfortable to speak out loud.

As the branches and sub-branches are being filled in the Ishikawa diagram, the team can start to explore the branches and sub-branches further using the five whys technique. The five whys are used to analyse more levels down, by asking “why” a problem happened up to five times until the root cause has been reached. The technique allows for solving the problems at the root rather than at an immediate more obvious level. It is, however, important to know when to stop asking “why” and not exaggerate the use of it, as it can be counterproductive to the process.

Referencer:

Larsen, S. B. (2018). Projekter & Rapporter: på tekniske uddannelser (1st ed.). Hans Reitzels Forlag.

Jensen, T. J., et al. (2011). Kvalitetsstyring og Måleteknik (1st ed.). Erhvervsskolernes Forlag.

Bicheno, J. and Holweg, M. (2016). The Lean Toolbox: a handbook for lean transformation (5th ed.). PICSIE Books.

Christiansen, T. B., et al. (2010). LEAN: implementering i danske virksomheder (1st ed.). Lindhardt og Ringhof.

Wong, K. C., et al. (2016). Ishikawa Diagram. Quality Improvement in Behavioral Health (1st ed. pp. 119-132). Springer International Publishing. https://doi.org/10.1007/978-3-319-26209-3_9

Liliana, L. (2016). A New Model of Ishikawa Diagram for Quality Assessment. Iop Conference Series: Materials Science and Engineering — 2016, Volume 161, Issue 1, pp. 012099. Institute of Physics Publishing. https://doi.org/10.1088/1757-899X/161/1/012099

References

1. ↑ ^{1.0 1.1} Aldridge, E. (2022). Root Cause Analysis Steps PMP Exam Guide. Projectmanagementacademy.net. https://projectmanagementacademy.net/resources/blog/root-cause-analysis-steps-pmp-exam-guide/. Accessed 20 Feb. 2022.
2. ↑ ^{2.0 2.1 2.2 2.3 2.4} International Organization for Standardization. (2020). Project, programme and portfolio management – Guidance on project management (DS/ISO 21502:2020). https://sd.ds.dk/Viewer?ProjectNr=M351700&Status=60.60.
3. ↑ Wong, K. C., et al. (2016). Ishikawa Diagram. Quality Improvement in Behavioral Health (1st ed. pp. 119-132). Springer International Publishing. https://doi.org/10.1007/978-3-319-26209-3_9.
4. ↑ Liliana, L. (2016). A New Model of Ishikawa Diagram for Quality Assessment. Iop Conference Series: Materials Science and Engineering — 2016, Volume 161, Issue 1, pp. 012099. Institute of Physics Publishing. https://doi.org/10.1088/1757-899X/161/1/012099.
5. ↑ ^{5.0 5.1} Project Management Institute. (2021). A guide to the Project Management Body of Knowledge (PMBOK guide) (7th ed.). Project Management Institute. https://app-knovel-com.proxy.findit.cvt.dk/kn/resources/kpSPMAGPMP/toc?kpromoter=federation.
6. ↑ ^{6.0 6.1} LBS Partners (2022). HOW TO MAKE AND USE A FISHBONE DIAGRAM TEMPLATE. Lbspartners.ie. https://www.lbspartners.ie/insights/how-to-make-and-use-a-fishbone-diagram/. Accessed 20 Feb. 2022.
7. ↑ ^{7.0 7.1} CMS.gov. (2022). Guidance for Performing Root Cause Analysis (RCA) with Performance Improvement Projects (PIPs). CMS.gov. https://www.cms.gov/medicare/provider-enrollment-and-certification/qapi/downloads/guidanceforrca.pdf. Accessed 20 Feb. 2022.