The Fishbone Diagram (sometimes called the Ishikawa diagram) is used to identify all the factors that have an impact on your problem.
It is primarily an issue analysis technique but it also has a motivational and team building effect on participants as they go through the process.

A completed Fishbone Analysis
There’s nothing like building a shared understanding of a tricky problem to unite a team.
The process is called Fishbone Diagram because of the way in which the information gathered is arranged visually – like the skeleton of a fish.

Download free slides... enter your email address at the bottom to get this team building activity in your inbox

Download free slides... enter your email address at the bottom to get this team building activity in your inbox
Objective
When Would You Use It?
Why Would You Use It?
Resources Required
Process
- 1The Facilitator writes down the problem on the right-hand side of the paper.
- 2The Facilitator draws a straight line to the left (like the backbone of a fish).
- 3The Facilitator draws stems at a 45° angle to the backbone line.
- 4After discussion and agreement with the Participants the Facilitator, at the end of each of these stems, lists 5 – 6 key factors /headings of the problem or issue that can be brainstormed.

- 5Each of the key factors can then be broken down into subsidiary factors that need to be understood before moving on to solutions in the development phase.
- 6The Participants should be encouraged to brainstorm each main ‘bone of the fish’ in turn.

I recommend altering your process for using the fishbone diagram. Your process flows: Problem-Key Factors-Subsidiary Factors. Most group discussions will jump from the problem statement directly to each person’s experiences with the problem (the subsidiary factors). When I use this technique, I listen to someone talk, write it on a Subsidiary Factor line off a blank Key Factor line. If the next person’s idea is related, I write it off the same Key Factor line, if not, I start a new one. After several related Subsidiary Factors are listed off a Key Factor line, it’s now easy to identify/name/categorize that line.
Thanks for the build David. So what you’re saying is to not force the group to name the main arms up front but to simply talk about their experiences naturally in relation to the problem statement? I can see how that would work for sure.
In my experience some people need the triggers of the key factors to be able to talk about the subsidiary and having the overview upfront means people know how far they have to go in the session.
You don’t want the group stuck on one key factor for the full session right?
please i need to explain the cause and effect of an after-math incidence
High fuel consumption of vehicle