The Cause and Effect diagram is also known as a fish bone diagram, because it resembles the skeleton of a fish. Using a cause and effect diagram can be the most effective way to define the problems that you intend to solve with your product. Get your stakeholders engaged in your program with this compelling visual!
Getting To The Root Of The Problem
In our recent article about writing good problem statements, we pointed out a common mistake people make with problem statements – they confuse the manifestation of a problem with a problem.
Problem manifestation [noun] – an example of a way in which a problem is exhibited, without appreciating the true nature of the problem. Ex: The problem manifestation is that the tires on my car are under-inflated. The problem is that my car is too expensive to maintain.
This distinction is relevant. The cost of operating the car is too high. That is the problem. It happens to be that one reason that the cost is too high is under-inflated tires. If you focus your energy on getting properly inflated tires, it will help (by improving fuel economy a little, and by reducing the frequency of tire replacement) with costs anecdotally. But you will not have solved the problem that costs are too high. Unless you get lucky. Costs can be high because the engine is inefficient or damaged, the aerodynamics of the car are bad, or any of a number of reasons. If you solve the problem by addressing a single manifestation of the problem, without understanding the whole problem, it is only because of luck.
In the comments on that article, The Demon points out that it is not always easy to identify the right level of abstraction for your problem. The cause and effect diagram makes it brilliantly simple not only to get to the root of the problem, but to communicate this cause-and-effect hierarchy of problem decomposition.
Cause And Effect Diagram Example
The cause and effect diagram is so visceral that the easiest way to communicate how it works is to show an example. Here’s what the cause and effect diagram would look like for the example problem above, where the cost of operating the car is too high.
The main problem is that the cost of operation is too high. This is the far-right, or fish-head part of the diagram (it is sometimes called a fish bone diagram).
The problem can be decomposed into three separate problems: spending too much on fuel, maintenance, and payments. Each of those problems can be further decomposed. Note that “under-inflated tires” appears twice – once as a cause of low miles per gallon (MPG) and once as an excess maintenance cost.
Alternately, you could recognize that spending too much on fuel could be due to lower fuel economy or excessively high prices. You could then choose to decompose the problem slightly differently:
Either approach results in crystal clarity that under-inflated tires is one root cause of low fuel economy, which is one cause of excessive spending on fuel, which is one cause of excessive operating costs. This visual approach helps significantly when trying to identify the right level of abstraction for expressing the problems in your problem statement.
Problem Abstraction Is A Side Benefit
The really cool part is that the help you get in finding the right level of abstraction for your problem is just icing on the cake. [Ed: No jokes about fish-bone cake. Ick!]
The real benefit comes in communicating and validating the problem decomposition with your stakeholders.
Someone questioned me once on the value of writing passionate requirements. Show one of these to your team, and you’ll get enthusiastic, passionate responses. You’ll get kudos from the business for demonstrating that you understand their needs. You’ll get praise from the implementation team for providing them with context.
Using Visio To Create A Cause And Effect Diagram
Creating a cause and effect diagram in Microsoft Visio is really easy, there’s a built in template, and it’s a good one. Create a new drawing and select the “Cause and Effect Diagram Shapes” template (under “Business Process”):
Visio will create a new drawing with a blank cause and effect diagram set up for you:
Fill in the boxes with the large problems. To get to the next level of detail (such as “Fuel Economy is Too low” in the last example), select the “Primary Cause” shape and drag it onto the diagram. Attach the arrowhead to one of the branches (the fish “ribs”) and start typing. For once, Visio’s default layout is where you want it.
To get a secondary cause shape (such as “Bad Aerodynamics” in the last example), select the “Secondary Cause” shape and drag it onto the diagram. Attach the arrowhead to the “primary cause” arrow you just created.
Conclusion
You already have a good justification for defining problems at the right level of abstraction. Now you know how to easily create a cause and effect diagram to find the right problem definition. As a bonus, communicating with stakeholders just got a lot easier – include this in your BRD.
Hi Everyone,
I think Ishikawa (spelling check?!!) / Fishbone or Cause & Effect diagrams are often over looked as they have been in the analysis domain for a while and are, dare I say, considere a bit “passe” – I think this is really sad!! For all of the reasons you have pointed out.
A step I like to take, that helps to tie things together and get people to that sought after level of abstraction, is to ensure or make the effect on the far right of the diagram one of my organisations recognised benefits.
I have created a benefits model with 10 static “benefit buckets” in it that we model each project against. By tying the effect on the diagram to one of these yields some serious “eureeka” moments when the business see that their problem can be tied to the organisations strategic goals and benefits model.
for example, one of our 10 benefits is the ubiquitous “Cost Savings” – I would probably use this “benefit type” in the example above.
Hopefully this makes sense, if not I’m happy to explain further or knock up an example.
Yours in Analysis,
Grant The Demon Barbour
Hey Grant, thanks for the great comments!
The Ishikawa Diagrams are definitely very useful. And with a client IT department I worked with, it was an “everything old is new again” situation. Like bell-bottom jeans, there was an entire organization that had never seen, or forgotten about these things. Unlike bell-bottoms, they do have value.
I used to be a mechanical engineer (my wife says I always will be, I just don’t do it for a living), and used Ishikawa diagrams as part of failure analysis of systems controls. I had forgotten that that was the real name of these, and just went for the laugh with a picture of a fish head. Thanks for reminding us!
If I understand what you’re saying, you set up (up to) 10 diagrams, where the end goal (“Cost of operation is too high” in the example above) falls in one of your 10 buckets. Or maybe you have one or two diagrams for the business, with 10 branches (showing how the 10 buckets map into a corporate strategy). Or maybe it is both (One diagram showing why you have the 10 buckets, and then individual diagrams for each bucket). I like that idea a lot – especially for larger companies with complex agendas.
Definitely explain some more, in addition to driving better projects, these serve as great momentum-builders at the start of a project, and really help drive understanding and stakeholder buy-in. With this discussion, maybe we can help all the product managers and business analysts get a little better on the big-picture stuff (me included!).
Exactly right Scott, the technique I use can be used in a few ways. Mainly:
1 – Corporate strategy is to “Cut Costs”…. that is it, no plan, no tactics. The highly paid suits give this to the analysts or portfolio holders and ask us to make it happen… haven’t we all been there?
You can work back from “Cut Costs” or turn it on it’s head and give it a real effect, such as you have, “Cost of Operation Too Hight” thus using the cause and effect diagram as an idea or opportunity exploration tool.
2 – As you’ve said above, business come to us with an idea and we want to get to the right level of abstraction. By using the organisational benefits or goals we can tie up the effect of the proposal (the far right “Cost of Operation Too High” box on your example) with the strategy and make a far more robust case for taking this project forward. In this case I would indicate that the effect ties in with our “Cut Costs” goals or even replace the effect with this wording.
Hope this makes sense or I’m not pointing out what everyone already knows.
Thanks,
Grant, Sunny Scotland
About 10 years ago I used this diagram to compare the failure causes in a manufacturing environment to those in an office environment. One of the objectives was to introduce “Lean Office” concepts to a PI (Process Improvement) team and help them visualize how the legacy cause types (man, machine, materials and environment) in a manufacturing facility could be translated to today’s information-oriented employees. This particular presentation wasn’t so much to solve a particular problem at the time (for which these diagrams are most often used), but to show them how they could break down hidden causes behind office-related problems. For example, machines (in the old sense) normally meant a lathe, punch-press, milling machine or a similar device producing tangible, visible outputs, including scrap. The machine was a “tool”. Fast-forward to today where an office worker’s tool is usually their computer. In your problem analysis, you would hear things like “My computer’s too slow”; “The application causes me to go through too many screens to get what I want”, etc. In the old days the worker would complain to the supervisor that he couldn’t reach his production quota because his machine could only produce at half-speed. The main point here is that the problem was very visible (fewer parts per hour). The results of a “slow computer” aren’t all that visible, thus the need to elevate the visibility of the issues it causes (fewer orders processed; fewer invoices mailed) and tie them directly up the fishbone to the problem being examined; the “effect”. Once the analysts saw the relationships between the old and new views, they were better equipped to divide and conquer by breaking the causes down into 5 or 6 different types (primary causes) and then deep-dive as to secondary causes behind these.
Hey Ed, thanks, and welcome to Tyner Blain!
As a former mechanical engineer, I took to business process analysis (as an analog to manufacturing process analysis) like a fish to water. I’ve found you can extend the analogy to deal with “sources of error” and some of the other well-established analyses too.
Great anecdote about using the Ishikawa diagrams to help people visualize cause and effect!