Problem Cause & Effect Analysis
Designs often fail to be used as intended because problems are over-simplified. Problem root-causes and their effects are treated as both clearly-defined (obvious) and linear (i.e. a single cause leads to a single effect). This is only true for really structured problems, for example a set of rules to play a simple game like tic-tac-toe. In real life, we face wicked problems, problems that consist of a tangle of other problems, that are defined differently by different people, and that evolve over time as you learn more about the situation. So we get poor solutions that don’t solve the problems we actually face, especially in the design of technology and organizational change.
Systemic cause & effect analysis explores the complexity of a situation, reflecting the multiple perspectives we encounter and reducing the time needed to learn about how problems “work.” Using problem cause & effect analysis reduces the time needed to understand a problem-situation.
Modeling Problem Cause & Effect, Systemically
Systemic analysis means thinking through the system of influences that effect a problem. 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. To achieve a systemic problem analysis, we draw problem diagrams that work from cause → effect (i.e. problem 1 causes problem 2). But instead of limiting the analysis to a single cause or effect, we try to include as many factors as we can. Then we validate these models with the people involved in the situation, asking what elements or connections we have missed.
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,” and in turn, “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 1 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. We stop when we get to problems such as “it’s human nature,” or “that’s the company culture.” These are things we cannot control, but it’s important to model them so we understand the constraints on solving the problem.
After working backwards, we work forwards until we start seeing the need: fragments of a solution that might comprise part of how to solve our problem. These will often be suggested by the stakeholders – although it is important to note these, they may have a partial and uninformed perspective on how to solve the problem, as they only see those parts of the situation that they encounter daily. In the end, it is by integrating multiple points of view that solutions start to emerge.
A simple example of a problem cause and effect analysis is shown in Figure 2. 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 2.
When modeling problems, bear in mind:
• 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.
• You need to understand the boundary of what can be affected by your (design) solution and what factors are outside of this boundary.
• Factors outside of the boundary-line act as constraints on your design, so it is important to note these.
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.
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).
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.
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. For example, by defining a problem with work being done as the consequence of a company culture of not employing enough people, you are admitting defeat before you even try to solve the problem by reinforcing the vicious circle of causality. If, however, you define the cause as too few people to do the work required, you have two potential solutions: (i) employ more people, or (ii) reduce the work required. Either of these will break the vicious circle you encountered, without a political battle over company culture(!).
5) Finally, many problems are just beyond the problem-solver’s pay-grade (i.e. those that are due to human nature).
You need to be able to draw a boundary on any problem analysis model, to distinguish problems that are inside the boundary of influence – which can be dealt with – and “external” problems that act as known constraints on the system of work inside the boundary.
Systemic Problem-Analysis is Complex: Real-Life Examples
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 7.
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:
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 9 shows a real-life analysis, derived from a management workshop.
In Figure 9, we can see three separate clusters of problems, each of which relates to a different aspect of change that can be considered (and resolved) separately – even though some of the issues are related.
- There is a vicious circle of problems bounded in orange 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.
It takes quite a lot of modeling, validation with stakeholders, and arrangement of problem-elements to get to this type of “tidy” model. But the understanding that results from this analysis means that obtaining buy-in for change becomes much easier.
Summary
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.
Don’t over-simplify your analysis or accept “obvious” suggestions for root-causes. People often take a limited view of why things happen in the way that they do, suggesting “symptoms” of problems as the root cause, rather than bending their brains around why things really happen in a certain way. It is better to model everything that stakeholders suggest – or you (the analyst) observe – then split your analysis into clusters of problem-elements to be dealt with separately.