Fishbone Diagram in PM: Root Cause Analysis

Subject Matter: This guide outlines how project managers apply fishbone diagrams in systematic root cause analysis, with a specific focus on steps to create and apply context and how this visual problem-solving method shifts project issue resolution from reactive firefighting to proactive issue prevention.

Issues occur in every project. Timeframes are missed. Quality declines. Price tags rise. The instinct? Rush into solutions. Yet, resolving symptoms without understanding root causes ensures the issue returns, and often worse.

Fishbone diagrams (cause and effect, or Ishikawa diagrams) facilitate a systemic shift in this dynamic. Conceptualised in the 1960s by quality control engineer Kaoru Ishikawa, this visual aid helps teams systematically identify and analyse project issues and their underpinning causes. This technique is especially important for PMP certification training in the context of quality management and problem resolution.

To the eye, the diagram structure resembles a fish bone. The (project) issue statement is the "head," the major cause categories are the "bones" and the minor contributing causes are the "ribs." This visual structure acts as an organiser to guide the brainstorming activity in the order all the major causative categories are to be identified and analysed, so teams don't pre-empt or skip stages in the analysis.

Effective issue management requires far more than identifying and fixing issues. Managers often tackle problems with little thought beyond the original issue: they cover it up with an immediate solution. After only a few weeks, the problem is back, and the answer is a loss of deep cause analysis. Focus is lost on root cause analysis, which is one of the common causes of project failure. This reduces the chance of success and, ultimately, forces the problem to the back of the queue.

Rather than looking at an issue with a solvable focus, a Fishbone diagram pulls the issue apart. Rather than siloing within their own departments, Engineers, Operations, and Management contribute to the complete picture, and the approach is all collaborative to determine gaps, constraints, and the root cause. This solves the problem at a deeper level than an isolated intervention.

There is a time-saving effect, and issues aren't just problems: they cause problems in the future. Most companies that analyze problems with a cause-and-effect structure see a reduction of 30–40% in the level of recurrence. Projects improve their adherence to scheduling, and quality increases because deep-rooted issues are resolved instead of the symptoms being bandaged. Projects don't cause failures. With a deep understanding, they are able to utilize the analysis in the most effective way. This kind of analytical approach is often emphasized in PMP certification program modules.

The time invested in using different types of analysis will yield dividends for the business in the future, even creating value with regard to the time it took to address this problem.

Using root cause analysis provides underlying cause determination.

Collaborative efforts regarding time are minimal, deriving significant value afterwards.

A good example of this is using the fishbone method.

It provides systematic cause identification with minimal time investment while deriving moderate value.

The fishbone, also known as Ishikawa, organizes the different causes of concern. The framework that is the most utilized is the 6M framework. The framework is most relevant for operational and manufacturing-related projects.

Mannpower/People: They possess the skills, the training, and the experience to do the task. Communication is also important, as is human error.

Methods/Processes: These are the workflow procedures, the standards, and the documentation involved.

Machines/Equipment: The tools and the technology to do the task. Maintenance and capacity of the tools also count.

Materials: These are the inputs, the quality, and their availability, as well as the suppliers.

Measurement: These are the metrics that are used to assess the task, and poor data accuracy, as well as the way the metrics are used to inspect and measure the task.

Mother Nature/Environment: These are the working conditions, the temperature and the humidity of the place.

The 4P framework is also often used for service industries:

Processes: These are the work methods and the procedures involved.

People: This refers to the behaviours and the capabilities of the team.

Policies: These are the rules, the guidelines and the regulations.

Plant/Technology: The facilities and the equipment used.

These are not the only categories that exist, and it is even encouraged to adapt these categories according to the problem at hand. For example, software projects often use:

• Environment
• Testing
• Code
• Design
• Requirements
• Deployment

The most important thing is that there are sufficient categories to enable the team to think thoroughly about the possible causes.

Doing a fishbone diagram involves many steps. First, we need to figure out what the problem actually is. Saying that "we have bad quality issues" is too vague. Instead, we should be specific. Using the example, we could say "Software releases contain an average of 15 critical bugs per release." Being specific is optimal for analysis, and we want to make everything clear so that validation of our statements later on will be easier as well.

Using the problem statement, draw a horizontal arrow with the issue written at the arrow's head. This will be the 'spine' of the fish. Next, add some diagonal lines going upwards and downwards from the 'spine' and label them as the major cause categories.

Now for the most important part. Now that we all have a problem statement, we can do some collective brainstorming. Something that is useful is to do this on sticky notes as they can be rearranged and organized later easily. When brainstorming, the main rule is that there is to be no judgment. Capture everything, even 'foolish' ideas, as they can be useful.

Once potential causes have been identified, we need to ask 'why' for every potential cause. This could be done by posing the simple statement 'not enough testing was done,' for example. Why was testing inadequate? Perhaps because there was 'insufficient time.' Why was there insufficient time? 'Unrealistic schedule' was the root cause. Why was there an unrealistic schedule? This could be because there was a 'poor' initial estimation of the time that needs to be allocated to the project. This is an example of going down the "why" rabbit hole. Each why uncovers even more issues, and this is the ultimate goal.

After we have populated the diagram, we need to change gears and start analyzing our data. Which of the causes can be easily backed by evidence? Which are more based on speculation? This is the time when we need to gather our data, review the documentation and talk to the stakeholders. The 5 Whys technique can be used to figure out which causes are most likely to generate the most improvement.

Lastly, formulate targeted solutions that address the root causes you have identified. Assign ownership, deadlines, and evaluation criteria to measure the success of the implementation. This changes analysis into actions.

I have applied fishbone methodology in a number of projects. In one software project that was experiencing the same problems with failed deployments, we were able to list 23 potential causes and categorize them into 6 groups. Based on the data, we identified three root causes: a checklist for deployment that was incomplete, poor synchronization of environments, and a rollback process that was substandard. By addressing these three factors, we were able to reduce the deployment failures by 85%.

This technique is also very beneficial for construction projects. When a building project was experiencing delays in the delivery of construction materials, a fishbone analysis was used to identify the cause of the delays in the construction process and organized them into the following groups: vendor communication, process of order placement, transportation logistics, and the preparation of the construction site. After solutions were implemented for each of these areas, the delays were reduced by 60%.

In many cases, there are multiple reasons for schedule overruns. A fishbone analysis may identify a number of overlapping reasons: poor planning at the outset, over-optimistic estimates of durations, low availability of resources, uncontrolled increase in the scope, and poor management of interdependencies. In the above examples, standard analysis might highlight one or two reasons. The fishbone methodology takes into consideration every aspect. In many cases, learning to develop project management plan is enough to avoid problems that would otherwise need to be diagnosed with fishbone analysis.

The same can be said for budget issues. Errors in estimating costs, vendor pricing changes, scope changes, inefficient processes, and issues with the use of resources can all contribute to budget problems. Fishbone diagrams can assist teams in focusing on the interaction of these factors and how they compound.

The team you choose is the most important part of the analysis. Bring in people who are close to the work, and not just managers. The scheduler who tracks the tasks every day has more insight on the reasons for delays than a project director who only looks at the weekly report.

Make sure you allocate the right amount of time. Fishbone analysis is not a process that has a timebox in it. Allocate at least 60 to 90 minutes, and more for complicated issues. Build a safe space where people can highlight process gaps or mistakes without blame.

Be careful of the pitfalls. Do not stop at obvious symptoms. If "poor communication" is on your diagram, go to the next level down. What about communication broke down? Too many emails? Requirements that were not clear? Missing a decision maker? Ambiguous language often leads to vague answers.

Don't create an overly complex diagram. If you have 20 categories and 200 causes, it can be a lot to deal with. If you are overwhelmed with complexity, you probably haven't organized your causes properly, or you are dealing with multiple problems at the same time. When analyzing issues, complex problems should be tackled in smaller, more focused analyses.

Never let a good diagram become wallpaper. Many teams make nice Fishbone Diagrams and then file them away. The diagram is a means to an end, and that end is to achieve the implementation of solutions that eliminate recurrence. The professionals who train for the PMP certification acquire the skills to embed these quality tools into the workings of a project.

The use of Fishbone Diagrams can also be integrated with other problem-solving models. The 5 Whys can encourage the investigator to penetrate each branch for more granular, underpinning causes. From the various causes that have been identified, the Pareto analysis quickly spotlights those which most importantly impact the problem.

With Fishbone Diagrams and control charts, you can determine when a process has gone beyond normal limits, and then why. FMEA (Failure Modes and Effects Analysis) is also based on cause-and-effect logic, but incorporates a scoring system for the probability of occurrence and the severity of impact.

For each analysis to achieve continuous improvement, Fishbone Diagrams contribute to lessons learned repositories. The utilization of lessons learned leads to the documentation of an organization's memory regarding the causes of and the solutions to problems. This wisdom influences future projects.

You don't need expensive software to get started. A pack of markers and a whiteboard are great for team meetings. Drawing together is often good for more discussion than looking at a computer screen.

You can use basic tools for documentation and distribution. PowerPoint and Google Slides can generate professional-looking diagrams in minutes. A quick search will provide plenty of free templates. There are other specialized apps like Lucidchart, Miro, or Canva that offer fishbone diagram templates and drag-and-drop features.

Some project management apps have the ability to create fishbone diagrams, so if your team is already using one of those, you can take advantage of the built-in features. That said, don't let the choice of software keep you from getting started. The analysis is what's important, not the drawing.