The Ultimate Guide to the Fishbone Diagram
Want to rid your business of repeated problems? Well a Fishbone Diagram can help. Here’s a guide to show you what it is, how to use it… and even why bother at all.
What is a Fishbone Diagram? A Fishbone diagram or Ishikawa diagram, as it is often called, helps teams identify possible causes and root causes to a particular problem. It is called a fishbone diagram because of its resemblance to a fishbone: The head states the problem, and the spines represent possible causes to the problem in a logical order. The team use supporting data and observations, brainstorming as many ideas as they can to identify root causes to the problem, all on this one diagram.
Here’s a little more detail, so you can get up to speed with the Fishbone diagram in no time at all.
The Problem With Problems
I’ve mentioned it a number of times on this blog and in discussions with teams. The problem with most businesses is that they never really fix problems.
They encounter something and rally around to get over it. By doing this, they simply put band-aids over their problems to get the job or service completed.
Often, a short while later, the same problem returns, causing more mayhem. Before you know it, there are many issues that are rearing their ugly heads, because none of them (or very little) have been completely resolved in the first place.
By completely resolved, I mean sufficient time spent to:
- Identify why the problem happened
- Ascertain the root causes to the problem
- Put actions in place to eliminate these causes
- Check to ensure the problem has been eliminated
These bullet points represent true problem solving. And it all stems from what’s caused Root Cause Analysis (or RCA for short)…. Don’t stop until you know the problem and the root causes.
A measure of a quality focused business is their speed at identifying problems, conducting root cause analysis and implement RCA solutions, quickly.
The faster the better (obviously)!
Cue the Fishbone Diagram
As it happens, one of the more popular and simple methods to brainstorm issues and identify possible root causes, is the Fishbone Diagram.
Called a Fishbone because of it’s appearance…
It’s history stems from a Japanese organisational theorist called Kaoru Ishikawa.
And it’s simply used to show a cause and effect relationship of a number of factors, relating to a specific problem.
Fishbone diagrams have the following characteristics:
- The head of the fishbone represents the problem
- Running off the spines are the main cause categories
- The ‘bones’ running off each cause category represent possible deeper causes that are linked together
The fishbone diagram is a simple and visual way to see cause and effect.
It’s these cause and effect relationships which create problems. By brainstorming them on one visual diagram, it provides an effective way of seeing why a problem happens and all the possible factors that may affect this.
There may be a number of factors that contribute to the effect (the problem). Many cause and effect chains must be seen to really overcome the problem.
And by using the Fishbone diagram, it’s easy to see them.
Fishbone Diagram: It’s a Team Game
It’s not the diagram that is important, it’s the successful identification of causes to a problem. With that said, you need a team of different experience and specialisms to come together to go through the Fishbone process.
Doing it on your own at your desk is not root cause analysis. You need to work with a team. This team must have different views and angles to help analyse the problem.
For instance, if there’s a functioning error with a product, you may well include the following team:
- Design – so they can identify any design flaws
- Production – so they can help identify any manufacturing errors
- Customer service – so they can discuss from the customer perspective
By bringing cross functional people together, you’ll stand a better chance of fixing root causes.
Get Your Policy Right Before Engagement
I would advise that the first thing you do is to create a simple policy, so everyone knows what to do when problems are identified.
For instance, there’s no point implementing Root Cause Analysis, and at the same time not telling people what to expect when a problem is identified.
You’ll get little to no buy-in.
People will be too wrapped up in their own tasks to give you time to fix problems.
But if you have an agreed policy, whereby everyone knows what to do and when to respond if called upon… you’ll get a better chance of continuous improvement being implemented and sustained in your business.
A policy can be a simple statement, clarifying key standards to follow, like:
– What happens when a problem gets highlighted
– Who is on call to help when signalled
– What to do when the team come together
– How long this brainstorming activity should take
– How long to expect completion of actions to resolve the problem
How to Create a Fishbone Diagram
Once you have your team at the ready, there are 6 key steps to effective Fishbone brainstorming:
- Obtain supporting data
- Create the Fishbone head
- Create the fishbone categories
- Brainstorm the potential causes
- Go deeper – find root causes
- Agree potential root causes and take action
Step 1: Obtain Supporting Data
Gather data sheets, process information and observe the problem / process prior to the Fishbone session.
It’s important to be as informed as possible, so you can mix ideas and opinions with data. Try not to just rely on people’s opinions. It’s the actual observations and facts that allows us to see cause and effect relationships and which backs up opinions.
Step 2: Create the Fishbone Head
On a whiteboard or Flipchart paper, now draw a Problem Statement Box. Add the spine as well.
Write the problem statement in the Problem Statement box (the fish head).
Be very specific here. If your problem is too open ended, your fishbone analysis will not be as targeted.
Try to describe your problem in terms of:
- What happened? We want to know quickly and concisely, the problem
- When did it happen? We want to see if a certain time had an impact.
- Where did it happen? We want to be able to pinpoint exactly where the problem happened.
- How did it impact your goals? We need to be clear how it affected our goals.
Some Examples of Good Problem Statements
Here are some examples to get you into the right problem statement frame of mind.
What: Material was purged on the K2 mixing machine which meant 4 hours of downtime
When: During the night shift (Approximately 2.00 AM)
Where: K2 Mixing machine
How Did it Impact Goals:
– On time delivery affected: The customer didn’t receive their product on time; Production is now 4 hours behind; 2 additional customers will experience late deliveries
What: Machine 3 suffered 12 hours down time through computer program error
When: 8.00 AM (and is a consistent fault)
Where: Machine 3
How Did it Impact Goals:
– On Time Delivery: 12 hours behind plan. 5 customers affected.
– Customer satisfaction: Poor customer relations with 3 customers
Ensure that everyone agrees the problem specifically and clearly.
Step 3: Create the Fishbone Categories
As part of the spines, you’ll need to define the categories. These are what we’ll use to help the team brainstorm ideas better.
The standard categories for Fishbone Diagrams, are:
- Machine / Equipment
For a service business:
You don’t have to use these categories, though. Some groups prefer to choose what they feel is important and relevant to them.
But here’s a template of what you should see so far:
Step 4: Brainstorm the Causes
Using the main cause categories, allow the team to shout out potential causes that affect the problem statement.
For each category, ask: “What in (category name) could have an impact on the problem?
As you go, add each highlighted cause to each category. You’ll get something like this:
Use the data and process observations to generate as many ideas from the team as possible. Do this until the team run out of ideas.
Step 5: Go Deeper – Find Root Causes
In step 4, you identified the top level causes. As this is a root cause analysis tool, we need to delved deeper. We need to find secondary and tertiary causes, or sub causes I like to refer to them as.
Each time we probe, we get a better understanding of the problem. We also get closer to the root causes. These are the real and unseen reasons for the problem we’re seeing.
For each cause, simply ask, “Why?” or “Why does this happen?”
- Primary cause to late deliveries: Drivers get lost
- Asking why does that happen, results in: Drivers don’t know the town
- Asking why again: New drivers
- Asking why again: High staff turnover
Now we’re getting somewhere. If we stopped at drivers just getting lost, we wouldn’t fix the issue. But fixing deficiencies around why staff turnover is high, will yield deep root and long lasting results.
By following this why questioning, you’ll get a Fishbone Diagram that looks something like this: (each additional spine shows linking sub causes and chains). These causes relate to each other.
Sub cause A is the effect of sub cause B. Sub cause B is the effect of sub cause C… and so on.
You can keep branching off the spines to show deeper cause and effect as you go.
A Fishbone Diagram Example
Here’s a completed version to help show you what to expect. Notice all the related sub causes linked together as spines:
Step 6: Agree the Potential Root Causes and Take Action
You’ll have a wonderfully populated Fishbone Diagram, complete with all the bells and whistles… looking similar to the one above.
You now need to weed out the possible causes.
Here are 3 ways to do this:
- Select the most common causes that keep popping up during your analysis
- Gain consensus from the team as to what they feel the root causes are
- Select the causes that occur based on their frequency in the workplace
After this, it’s then a case of taking action.
For each agreed potential root cause, ask, “Who’s doing what by when?”
Assign clear owners for each action. Take note and record these actions, so you can keep track of project progress, using something like the following:
When the actions have been completed, measure the process again…multiple times if you have to. Ensure that what you brainstormed, and improved has actually worked!
How long should a Fishbone Diagram session take? The idea of these sessions, like everything else in lean, is to be fast, effective and thorough. For the majority of problems. these sessions shouldn’t take that long – perhaps around 15 minutes. If you’re there 3 hours later, you’re probably doing it wrong. Be to the point, get people to stand up and take part. Keep the meeting brisk. Keep it on track and stick to the 6 steps.
Who Should be Involved? As mentioned above, don’t do it on your own! Agree a cross skilled team, so you can see and investigate the problem from many different angles. Create a policy to ensure that everyone gets involved in process improvements and shares responsibility.
Should We do Fishbone Diagrams for Every Problem Identified? If you’re starting this process from scratch, chances are, you’ll have so many issues, it can be hard to keep up. In this case, prioritise your problems and Fishbone sessions to a handful each time. As your business starts to get on top of things, then you can do more Fishbone Diagrams.
How do We Keep Hold of our Fishbone Diagrams to Track Progress? The simple and fast answer is this: If you’re using a standard board, take a photo of the session and actions and then erase it for the next group. Print it out and keep it in the problem solving area, by the board. And use it when the team come together to track project progress and completion of actions.