Problem Cause & Effect Analysis

Problem diagrams work from cause → effect (i.e. problem 1 causes problem 2).
• Effect-problems may be causes of other problems.
• By linking problems together, you see which problems are related and where your boundary of action can be.
• Think backwards, as well as forwards, to brainstorm causes of observed problems.
• Clusters of problems tend to suggest forms of solution: cause → (effect=symptom/cause) → (effect=symptom/cause) → solution requirements.
The point is to draw out all the problems which are communicated to you either directly from comments made by people, or indirectly by your analysis of a problem situation, to determine what causes these problems and what you can affect about them.

PCE1

Figure 1: Simple Cause & Effect Analysis

A simple example of a problem cause and effect analysis is shown in Figure 1. It demonstrates how problems involved in managing downtown parking  are related – solving one problem will not resolve all the problems necessary for parking management to work. Instead, we need to understand how problems are related, so we can identify clusters of problems and their symptoms to undermine with solutions. The analyst needs to realize that many problems are just beyond their pay-grade (or are just due to human nature). You need to be able to draw a boundary on any problem analysis, where problems inside the boundary can be attacked – and “external” problems act as known constraints. This is shown by the red line in Figure 1.

It helps to start in the middle. People in any situation will tell you about symptoms not problems, because they don’t stop to reflect on the real causes of things that bug them. So draw these out, then ask them “why does this happen,” “why does that happen,” and so on … keep working backwards until you get to human-nature, or “it’s just like that.” The levels of analysis are shown in Figure 2 to provide a guide to the scope of these analyses – they are there to help you to think about whether you have dug deeply enough into the problem situation. If they don’t help, or if your problem doesn’t fall into such layers, ignore them.

PCE2

Figure 2: Structuring A Cause & Effect Analysis

As you work, you will find that problems expand – different people add different perspectives and suddenly, your “simple problem” covers five sheets of paper! Done properly, a problem cause-and-effect analysis can be huge – mine often require piecing together many sheets of paper, as shown in Figure 3. The critical thing is to use the analysis to explore areas of problems, especially where multiple people’s area of responsibility overlap. Then you can define related “clusters” of problems to resolve, as shown in Figure 3.

PCE4

Figure 3: Exploring The Problem Situation and Identifying Clusters of Related Problems To Resolve

We can then dig deeper into just one cluster of problems, uncovering the details of why and how things happen- and defining a boundary for what problems can be tackled:

PCE2bFigure 4: Digging Deeper and Defining The Boundary of What Problems Can Be Tackled

We can also use the “big picture” problem analysis to identify patterns, such as vicious circles of causality that need to be broken before a problem can be resolved.  Figure 5 shows a real-life analysis, derived from a management workshop. In Figure 5, it can be seen that there is a vicious circle of problems bounded in red, which starts with the lack of ownership for order-capture, cycles around three separate branches of the same problem-cluster, then loops back through a time-constraint, to reinforce the lack of ownership. There is a cluster of problems bounded in blue which reflect limitations of the Marketing process – and the siloism of the Marketing function. The cluster of problems bounded in green reflect limitations of the bid preparation and response process (the original focus of this analysis). Its scope reflects only about one-third of the issues that need to be tackled, for bid response to be successful in winning new business.

PCE3

Figure 5: Identifying Problem-solving Constraints and Vicious Circles of Causality

The point of drawing a cause-and-effect diagram is:
(a) To distinguish between cause and effect, so that time and effort are not wasted in solving problems which are just symptoms of others
(b) To understand (as opposed to just listing!) what are the problems of the situation you are analyzing
(c) to understand which problems are within your scope of analysis and which problems are “somebody else’s problem”.
(d)You can draw a system boundary on the problem diagram – a line around those problems that are within your power to influence, but which excludes those which it is beyond your power to influence.

Issues With Problem Analysis

1) One of the main issues of problem analysis is that problems are never simple. They don’t tend to be related in straight lines.

PCE5a

2) This is exacerbated by people telling us about symptoms (my disk drive is full), rather than problems (I need a way to share data with someone else -> so we are sharing files via my local disk drive -> so my local disk drive is full as it was not provided for this purpose).

  PCE5b

3) Problems are over-simplified, as problem-analysts are trained to focus on specifics, rather than to think systemically  (even the problem in Figure 1 was simplified so it would fit into one diagram). Even when you bully them into reflecting a wider scope of analysis, they will artificially constrain this around the problems they understand best.

       PCE5c

4) “Lower-level” problems are related to “higher level” problems, in ways that create reinforcing problem-cycles (vicious circles of causality). You need to be able to take one of these problems out of the loop, so the vicious circle is disrupted, before you can solve the rest of these problems.

PCE5d5) Finally, many problems are just beyond the problem-solver’s pay-grade (or are just due to human nature). You need to be able to draw a boundary on any problem analysis, where problems inside the boundary can be attacked – and “external” problems act as known constraints.

© Copyright Susan Gasson, 2014-17. Created 12 December 2014.