Things go wrong… that’s just a fact of life. To paraphrase the infamous bumper sticker, “Stuff” happens. In the world of software projects, that stuff consists of bugs (software defects), bad/unclear requirements, missed delivery dates, inappropriate expectations and so forth. And when those things go wrong, all too frequently, the symptoms end up getting treated, only to return in the future when the real problem manifests itself again.
Root Cause Analysis helps you to think through causes of a problem thoroughly. Their major benefit is that they push you to consider all possible causes of the problem, rather than just the ones that are most obvious. So you treat the real problem, not only symptoms.
The Fishbone Diagram is a neat little visual tool. It helps with the brainstorming process of determining causes and root causes. It also provides a quick visual representation of cause density. It’s called the fishbone diagram, because when you’re starting out, it has a sideway tree look to it which resembles a fish skeleton. Sometimes it’s called a cause and effect diagram or Ishikawa diagram because of what it depicts and who came up with the thing, respectively.
How to draw a fishbone diagram ?
1. Identify the problem
Write down the exact problem you face in detail. Where appropriate identify who is involved, what the problem is, and when and where it occurs. Write the problem in a box on the right hand side of a large sheet of paper. Draw a line across the paper horizontally from the box. This gives you space to develop ideas.
2. Work out the major factors involved
Next identify the factors that may contribute to the problem. Draw lines off the spine for each factor, and label it. Here are some commonly used cause branches when performing Fishbone Analysis :
- The 8 P’s : Procedures, People, Price, Promotion, Processes, Plant, Product, and Policies.
- The 6 M’s : Machinery, Materials, Maintenance, Methods, Mother Nature, and Man.
- The 4 S’s : Skills, Surroundings, Systems, and Suppliers.
Try to draw out as many possible factors as possible. If you are trying to solve the problem as part of a group, then this may be a good time for some brainstorming. This is when the cause and effect diagram starts to look like a Fishbone diagram.
3. Identify possible causes
For each of the factors you considered in stage 2, brainstorm possible causes of the problem that may be related to the factor. Show these as smaller lines coming off the ‘bones’ of the fish. Where a cause is large or complex, then it may be best to break the it down into sub-causes. Show these as lines coming off each cause line.
After this point, the diagram stops resembling a fishbone pretty quickly. I suppose that’s when it evolves into a full‐fledged Ishikawa diagram.
4. Analyze your diagram
By this stage you should have a diagram showing all the possible causes of your problem. Try to figure out which of the causes, at the deepest level, is associated with the largest volume of events. Sometimes, it’s obvious from all of the results where the problem lies, and sometimes you’ll have to prune out the silly or distracting ones. And bear in mind that there can be more than one “root cause”.
Depending on the complexity and importance of the problem, you can now investigate the most likely causes further. This may involve setting up investigations, carrying out surveys, etc. These will be designed to test whether your assessments are correct.
Software to draw Fishbone diagrams
The best software is… brain(s) with paper and pen. But I also recommend these two software, if you need to include your diagram in a document for example :
- xMind : open-source mind-mapping software. xMind is easy-of-use and lets you create really good looking Fishbone diagrams very easily.
- Creately : free online diagramming software. Creately offers multiple Fishbone diagrams template to start from.
If you haven’t use Fishbone diagram, you should consider using it. And if you are using Root Cause Analysis and Fishbone Diagram to help you solve problems, have you some tips to share or other tools to recommend ? Your feedback is welcome in the comment section.
– Geoffrey
No related posts.
[...] blog has migrated PO Toolbox : How to diagnose causes of a problem ? Feb [...]
Hello Geo,
I didn’t know the existence of this kind of diagrams as a way to solve problems but I would be glad to add it to my systems engineering mental toolbox. Nevertheless I can’t help but notice the resemblance with what we call a Multiple Cause Diagram and its quantitative brother, the Sign Graph, which are both recommended by Peter Checkland in his Soft System Methodology. And they pretty much cover the same area (at least how you described it) : finding the root causes behind a recurring problem. Is there any advantage in using fishbone diagram instead of the MCD/SG duet or can they be used at the same time without being redundant ?
PS : By the way, Software doesn’t have a plural form
I am impressed with all this useful information. Was WAY more than I expected. I just cannot keep up with your posts. So much information to read about.
Hi Jeremie,
Thanks for the typo, I’ve corrected the blog post.
With Sign Graph, you don’t classify the causes in different categories. So I would say that you can use a Sign Graph once you have identified the cause, to analyse it more deeply.
Ishikawa is good to have an overview of the root cause, not so much to analyse it more deeply.
Very interesting blog post thank you for writing it I just added your site to my favorites and will check back
By the way this is off subject but I really like your web page layout.
Thanks for your comment Gabriele !