REPLY Definition of root cause (SD6787)

[SDMAIL Jack Harich]

Posted by  Jack Harich <jack at thwink.org>


Bill Braun wrote:
> Jack Harich opines that if the structure that produces the reference 
> mode is the root cause, then there is no root cause, per se. I ought 

In my first few years of working on the sustainability problem analysis, 
this is the viewpoint I started to drift into also. But I found it 
unproductive to say the root cause is the absence of A, and the solution 
is A. It's just too ex post facto.

My solution to problems like this has been to continuously improve the 
problem solving process, and reapply it after major improvements. This 
has led me deeper and deeper into the mysterious complexities of the 
problem.

One process improvement breakthrough was the realization that the human 
mind does not actually leap from root cause to solution. There are 
intermediate steps. After we find the root causes, then the question 
becomes how to resolve them. First we sense what NOT to do. This is the 
low leverage points we need to avoid, however attractive they may be. 
Then we sense what TO DO, by examining the model and hypothesizing what 
loops need to be dominant to resolve the root causes. Then we figure out 
how to do that in terms of where in the system to "push" on, which is 
the high leverage points. Now we know WHERE to push. But we don't know 
HOW to push. That is determined in the solution convergence step of SIP.

Now when we present model findings and recommendations to decision 
makers, we have a much richer and more persuasive case. We can say 
here's the model and here are the recommendations based on it. We can 
show how you can logically work backwards from the solution 
recommendations to the HLPs to the loops they will make dominant to the 
LLPs they are avoiding to the root cause. The solution will resolve the 
root cause, and hence is a reasonably "good" solution. This can be done 
in an easy to understand manner, because each explanatory step is such a 
small leap. The result is policy makers can feel they have fully grasped 
the central argument of the analysis. This empowers them.

Sorry if I'm repeating myself. This is all such a new way of thwinking 
that I just can't resist explaining it again.


 Additionally, I wonder if the term itself is doing us a disservice. 
 The term is singular, and suggests "just one thing". Is that a helpful 
 way to think about complex problems? It would seem to rule out the 
 interdependent interaction of two or more "roots".
A nice point. The field could use a better term, rather than continue to 
carry one with such a strongly established meaning that it leads folks 
astray.

Let's have a contest! Anyone can enter. What should the new term(s) be? 
The replacement term for root cause (or underlying cause) needs to have 
these qualities:

(1) It is clearly a major cause of the symptoms.
(2) It has no deeper cause.
(3) It can be resolved.

and a few new ones, based on our discussion:

(4) It is the most effective place in the causal chain/structure for 
solution intervention, given the problem definition. Recall this 
includes the constraints, deadline, and confidence level. Notice I did 
not say "cost effective" but just "effective." There is much more to 
consider than cost.

(5) It is stable enough to serve as a long term foundation for the 
subsequent analysis steps.

(6) It interacts with the other (root) causes in such a manner that 
resolving all of them solves the entire problem.

Now then, what are some possible new terms? Hmmmm...

Critical point?

Critical cause?

Failure point? That's got a nice ring to it.

Root flaws? I'm already using "flaw" in SIP strategy maps to mean root 
cause. Flaws allow defects to appear. Defects cause symptoms. Solutions 
resolve flaws. See 
http://www.thwink.org/sustain/articles/003/StrategyMaps.htm for an 
example. Click on the Proper Coupling Strategy Map for an example 
showing three flaws, one of which is unchangeable. Notice the short 
explanations for symptoms, defects, flaws, fixes, and deep structural 
changes. I've found these maps to be very helpful. They are a road map 
to the rationale behind the model.

Flaw layer?

Any more ideas? Maybe the practice of root cause analysis already has a 
better term? See http://en.wikipedia.org/wiki/Root_cause_analysis

> Posted by  "nickols at att.net" <nickols at att.net>
> Re Jack Homer's post
> I agree with Jack's assertion that searching for "root" or "real" or 
> "true" causes in complex social systems is a fruitless endeavor.  Not 
> only is there no end to the forces at play, they are also changing 
> over time.  Note also that Jack is careful to separate complex social 
> systems from engineered (what I take to be "physical") systems (e.g, a 
> production line).

A penetrating distinction. What might differentiate the classes of 
problems where root cause analysis is and is not applicable?
 
Thanks for this keen observation. You must be using your binoculars! :-)


 Kim Warren wrote:
> A *static* analysis of why our sales revenue is less than we want 
> would therefore identify these 3 items as the root causes. But that's 
 Kim,

Hi there. Thanks for the explanation. Let's zero in on your "This means 
that to continue the quest for root-causes..." As you do this, you 
hypothesize about how to change the model so that it includes the true 
root causes. This is also called creating the structure it takes to 
exhibit the reference mode graphs, for the right reasons. If the right 
reasons are deep enough, then you have your root causes.

What must be added to the model to do this is the root causes. Without 
them the model is only close, or in the first few iterations, it may be 
far away. Think in terms of a causal chain that weaves its way through 
your model. At the logical end of one end is the problem symptoms. At 
the other end is the root cause. It takes a bunch of these causal chains 
to connect all the root causes to the symptoms.

To make this more clear, suppose you have a model. To get it to deeply 
explain the system's behavior, you may have to add a node, such as the 
false memes size node in the Dueling Loops model, at the bottom of the 
page at: 
http://www.thwink.org/sustain/articles/005/DuelingLoops_Paper.htm. 
Without that node the race to the bottom has no inherent advantage over 
the race to the top. So although the broad root cause here is a 
collection of concepts as I quoted earlier, the bottom most one (the 
root root cause :-) is that node. It can be used to inflate the size of 
false memes, while the opposing loop, the race to the top, has no such 
advantage.

We can truthfully say that everything in a model causes its behavior. 
But it is more productive to think in terms of what are the key elements 
of the model that cause it to behave the way it does. Managers think 
this way all the time, when they rattle off phrases like key strategies 
and core competencies. They know that at the root of their plans and 
capabilities lies a very small handful of concepts that account for over 
90% of their competitive advantage. All we're doing with the concept of 
root cause is the same thing. It's unfortunate that the term has such 
baggage in its connotations and has never been formally defined for our 
field.

Does this explain my viewpoint?

> I suppose the last and critical extension is to
> identify what it is about the decision[s] - i.e. the policy-rule that 
> guides those decisions - that lead to problems or suboptimal 
> performance. So perhaps the true root-cause is always a dysfunctional 
> policy?   

No. I used to think this way. Then I noticed this is a decision maker 
centric mindset, and too easily leads to trying to intuitively tinker 
with existing policies to solve the problem. This rarely works on 
difficult problems. There is a more productive alternative. This is to 
always think in terms of what step of the problem solving process are 
you in.

In SIP step 2B you find the root causes. You are trying not to think 
about whether existing policies are dysfunctional, because that usually 
provides no clues to hard to find root causes. All it does is point to 
attractive LLPs, usually. Thinking about solution failures will bias 
your analysis, in step 2B unless you use that info to objectively help 
you find the root causes.

For example, Kepler didn't think about why other astronomers failed to 
explain why planets moved around the sun in the path they did. He 
studied the data from Tycho Brahe. That led him to see patterns in the 
data no one else had noticed. Out of this emerged the discovery that the 
planets travel in elliptical paths. So we need to study the actual 
system, and not distractions like other solutions.

Saying that the root cause is always a dysfunctional policy is like 
saying that the cause of the problem is solutions that are not working. 
It is a tautology. (Unless no solutions are in place since it's a new 
problem.) It's always true, in a sense. But in the sense that a process 
like SIP uses the term, it is not true. The cause of the problem is an 
unresolved root cause. This is the subtle but more powerful mindset I'm 
trying to help you think in.

Have I succeeded?

Good luck,

Jack


Posted by  Jack Harich <jack at thwink.org>
posting date  Wed, 05 Mar 2008 09:51:37 -0500