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!

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

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!).

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