Every project has its problems. It’s not uncommon and can happen at any stage. What sets projects apart is how well the project manager can deal with problems and avoid a repeat in future projects.
Effective problem-solving begins with determining the cause of the issues promptly. One of the ways to do this is with a structured root cause analysis—and that’s where the fishbone (also known as Ishikawa) diagram comes in.
In this article, we discuss:
What is the fishbone or Ishikawa diagram
When to use a fishbone diagram in project management
Advantages and disadvantages of Ishikawa fishbone diagrams
How to create a fishbone diagram in 4 steps
Fishbone diagram examples
Let’s jump straight in!
What is the Fishbone or Ishikawa Diagram?
A fishbone diagram is a problem-solving tool used by project managers to determine why products have defects or variations and why there are failures within a process. In other words, organizations use it to help arrive at the root cause of an issue.
Also known as the Ishikawa diagram, this project management diagram allows you to analyze even the most complex projects and pinpoint any factors contributing to breakdowns. Given that complex projects have many moving parts, isolating and addressing problems may be difficult without an appropriate root cause analysis tool.
As the name suggests, a fishbone diagram mimics a fish skeleton. Teams place the underlying problem as the fish’s head (facing right). The ribs of the “fish” branch off the back and denote major causes. The bones of the fish skeleton branching off the ribs represent root causes.
Kaoru Ishikawa, a Japanese organizational theorist, popularized this project management tool in 1960. It has expanded to become an essential part of many modern-day systems and is one of the most popular tools in Six Sigma.
There are three common types of fishbone diagrams that project managers can use for projects with varying processes, complexities, and more:
- Simple Fishbone diagram: A simple fishbone diagram has just a few branches and doesn’t include pre-labeled categories. The uncomplicated nature of this diagram encourages the user to go straight to the key causes.
- 4S Fishbone diagram: The 4S fishbone diagram includes four categories: surroundings, suppliers, skills, and systems. This diagram can help you identify issues such as critical supply chain disruptions, skills shortages, or process shortfalls.
- 5M/1E Fishbone diagram: In the 5M/1E fishbone diagram, the categories are: man, machine, method, material, measurement, and environment. This diagram is generally used in manufacturing as it includes material and machine classifications.
When to use a Fishbone Diagram in Project Management
So when does the Ishikawa diagram truly become useful in project management? Developed initially as a quality control tool, you may find a fishbone diagram helpful when:
- Analyzing a complex problem with many causes.
- You need a different point of view to analyze a problem.
- Brainstorming possible root causes for a problem and appropriate solutions.
- You want to uncover bottlenecks and identify why a process isn’t working.
- You want to improve your process or improve the quality of your outputs.
- You don’t have enough time to implement time-consuming traditional problem-solving tactics.
Advantages and Disadvantages of Ishikawa Fishbone Diagrams
Of course, these diagrams come with their unique mix of pros and cons.
Let’s start with the advantages. Fishbone diagrams:
- Help organizations identify cause-and-effect relationships with underlying problems.
- Accelerate joint brainstorming discussions. Brainstorming sessions enable teams to use broad thinking instead of sticking to limited thinking patterns that can lead to getting stuck.
- Enable project managers and their teams to ponder on why something happened repeatedly as they draw the diagram. This process helps examine nearly every possible cause of a problem instead of just concentrating on the most obvious ones. Teams can then drill down to one or more root causes.
- Help teams see which relevant causes they should prioritize.
Some disadvantages of the fishbone diagram include:
- All the information added to a fishbone diagram is based on opinion rather than evidence.
- If a project is too complex and has multiple factors, they may be too difficult to display in a fishbone diagram.
How to Create a Fishbone Diagram in 4 Steps
Now let’s look at how to create a fishbone diagram in four simple steps.
Step #1: Identify the problem
To start your Ishikawa diagram, write down the exact problem you’re facing. With your team, figure out when and where it occurs and who is involved.
Next, place the problem statement on the right side of the diagram (the fish head). Then draw a horizontal line extending to the left from the problem statement (the spine).
Step #2: Pick the major categories of causes
Once the team has adequately defined the problem, they must decide how to categorize the causes of the issue. Categories can include people, equipment, materials, systems, external forces, etc. In manufacturing, categories usually revolve around the 6Ms we discussed earlier.
In your diagram, draw a line off the fish’s spine and add a cause as you identify it.
Step #3: Identify actual causes
Here’s when the real brainstorming starts. Team members can begin to identify possible causes of the problem related to each category. Draw shorter lines off of the “bones” of the diagram and add these potential causes.
Step #4: Analyze the diagram
This final step involves analyzing your complete fishbone diagram that visually displays all possible causes of the problem statement. For this step, you will need other tools, such as the 5 whys technique, to scrutinize the problem further and find out which potential causes are contributing to the problem.
Fishbone Diagram Examples
Not sure exactly how to put the Ishikawa diagram to work for your project management needs? Let’s take a look at a couple of examples to help you understand.
Example one: The customer churn of a product is so high
A software company is wondering why people aren’t renewing their subscriptions, despite initial product sales doing well. Here, the team deduces that users don’t seem to see continued value in the product after their initial purchase. Their job is to identify why and try to solve the problem.
On reviewing the subscription data, the team also learns that the biggest problem is that 40% of users cancel their subscriptions after the first month. It’s obvious that this is a key metric to improve. The team decides they want to aim to lower the churn rates to 20% or less.
Further brainstorming reveals possible causes of churn as:
- The subscription system: There are multiple issues with the subscription management system. Payment and registration procedures are challenging to navigate, there are few payment options available, there are no reminders sent at renewal time, and also, customers aren’t being alerted when their on-file credit cards have expired.
- Users: Registered users don’t understand the full benefit of the software, they’re unable to perform basic operations, and since they don’t use the software consistently, they often simply forget about the product.
- Software: Finally, there are issues with the actual product itself. It’s unstable, crashes regularly, can be challenging to use, installation requires multiple additional plugins to function well, and vital functionality requires other subscriptions.
Out of these many causes, the team needs to continue brainstorming with the help of their diagram, to hone in on the main cause of the churn and attempt to fix the issues.
Example two: A maintenance technician slips and injures himself during a routine inspection
It’s come to the attention of a large restaurant that a maintenance technician slipped and injured himself while conducting a routine inspection of the hotel’s kitchen. The manager wants to find out what caused the technician’s slip and who could be responsible for the accident.
They gather their team and, together, categorize the causes of the problem as follows:
- People — who could have been responsible for the accident include maintenance staff, the inspector, MRO staff, and supply staff.
- Material – The parts used on the machines the technician was inspecting could have been substandard.
- Method – Maybe the maintenance technician hadn’t received proper inspection or maintenance training. It’s also possible that key maintenance procedures weren’t followed.
- Machine – The machine could be old and may have been long overdue for inspection and maintenance.
From here, the team needs to dig deeper to determine which of these causes is the root cause of the accident.
Using the Fishbone Diagram within Project Management
As you can see from the examples above, the fishbone diagram is an efficient way to identify issues within complex projects. Although it can be time-consuming, incorporating it into your project management methodology and procedures can help you implement critical quality improvements and corrective measures. The diagram allows you to go deep into the root cause of the issue and solve the problem for good.
Project management software like Mission Control, the Salesforce Project Management Software application, can make the process of creating a fishbone diagram much less time-consuming. You can quickly generate reports and use them to analyze past performance to help you come up with the causes. You can also refer to your Kanban Board or Gantt chart to identify project bottlenecks that you could investigate to come up with the causes and solutions. Make sure you check out our other Project Management Best Practices.
Request a demo to see how Mission Control can help your organization embrace the fishbone diagram and put it to work for your project management needs.
