REPLY Definition of root cause (SD6821)

[SDMAIL Jack Harich]

Posted by  Jack Harich <register at thwink.org>

Ulrey, Michael L wrote:
> Jack,
>
> Thank you for your comments. They prompted me to do some more thinking 
> on my original post, for which I am grateful. First of all, the 
> "prominent accident expert" I referred to is the psychologist James 
> Reason, who has contributed greatly to human factors issues in the 
> fields of health and aviation, among others. (I couldn't remember who 
> said it in my first post, so I looked it up). Second, I may have 
> sounded dismissive of searching out causes or contributing factors for 
> accidents in my zeal to promote the systems thinking approach. Of 
> course, one has to try to find such causes or factors and either 
> eliminate them or mitigate against them. I believe the main point that 
> experts like Reason and Woods and Hollnagel and Leveson are making is 
> that in airplane accidents, for example, pilot error is the most cited 
> cause, and that although this may help lawyers pin blame, it is not 
> very helpful in preventing future accidents. 
Yes, yes, yes!

> One must look deeper into human factors issues having to do with the 
> pilot's interface to the "system" (airplane systems and instruments, 
> air traffic control clearances and information, etc.) in order to 
> uncover possible sources of confusion that would have caused even the 
> most expert pilot to make the same or similar "mistake".
>   
These would be the root causes, rather than the intermediate causes that 
popular understanding stops at.

> It is way too easy to analyze an accident carefully and fully in a 
> relaxed environment AFTER the accident, and conclude that a pilot 
> should have done this or that, when in fact he/she had to make a 
> decision quickly, usually under considerable stress, and with partial 
> or misleading information. Thus, the point is not that we should cease 
> looking for causes or contributing factors, but that we should broaden 
> the scope of the investigation to include human-system interface 
> issues, and not be too quick to lay blame on the person at the sharp 
> end of the stick.  
Good point. You're getting into the fundamental attribution error here. 
This is to attribute a problem to a social agent (like a person or 
organization) rather then system. As you have explained, it is usually 
the system that predisposed the agent to behave they way they did.

>     P.S. Here is a relevant link you my find interesting, from the 
> health field. I came across it while looking for James Reason 
> references on the Web.
>
> http://www.sentinel-event.com/theory.php
>   
Thanks. I like the definition: "Root cause analysis is a set of 
processes by which the underlying causes of adverse outcomes may be 
identified, with the goal in mind of preventing the reoccurrence of such 
events."

Further down the article says: "In the health care industry, root cause 
analysis is for the most part still viewed as yet another regulatory 
requirement which is neither value-added nor inexpensive.  As a 
consequence, there is resistance to the performance of root cause 
analyses, resistance to learning about their performance, and lack of 
support at all levels for their effective usage."

Are we seeing similar resistance in the SD industry? Not for the same 
reason, but for others?

Wow. The rest of the article was very impressive, in the way it explains 
the resistance in the health care field to the use of RCA. I had no idea 
this existed. That it is due mostly to the "blame" issue is interesting, 
even fascinating.

I was glad to see "Errors must be accepted as evidence of systems flaws, 
not character flaws."

SDMAIL Jack Homer wrote:
> Posted by  "Jack Homer" <jhomer at comcast.net>
>
> Jack Harich writes:
> John Sterman is talking about the essential feedback structure that 
> explains the dynamics of the real system, not the dynamics of a 
> computer model.  This feedback structure will go into the model, but 
> models typically include a lot of other variables, as well, either to 
> spell out the details that are glossed over in the dynamic hypothesis, 
> or to add some other variables that the audience for the model would 
> expect to see in there, even if it turns out later that those 
> additional variables are not so important after all. (Remember, the 
> dynamic hypothesis may turn out to be incorrect and have to be revised.)
>
> Based on his postings, I suspect that Jack Harich may be confusing 
> looking for root causes in the real system with looking for root 
> causes in a computer model.  
Thanks Jack for your efforts to help us understand this.

Last week in a meeting I said "everything in a node equation represents 
a relationship in the real world." The meeting leader then pointed out 
that was an important statement. Based on this, I suspect I'm not 
confusing the difference between a model and what it is modeling. 
Perhaps this is a common error.

I like your explaining for Sterman that what he really means is the 
*essential* feedback structure is the root cause. This is helpful.

But still, the field of system dynamics, as represented in Sterman and 
SDR articles, seems to eschew the concept of root cause. I continue to 
find this puzzling, because the practice of searching for root causes 
has been so helpful in so many fields. Substituting a general, vague 
phrase like "dynamic hypothesis" for "root cause" misses the point of 
the concept of "root cause."

Why? Because in system dynamics models a "dynamic" hypothesis is a 
modeler's hypothesis for what in the real system, and in the model, is 
causing the symptoms. This is the entire structure of the model, because 
that's what must be built to reproduce the symptoms.

In standard SD practice, much effort is put into building a model that 
can reproduce the symptoms for the "right reasons." A key point I'm 
trying to make is that you can have a model that reproduces the problem 
symptoms, but if it's a difficult problem then the model probably does 
not yet contain the root cause. You have to drill down deeper with why 
questions and iterations. Phrases like the "right reasons" are not 
nearly as focusing as the "root cause."

The reason this is an important point is I think it's one place the 
average modeler goes astray. "Formulation of a dynamic hypothesis" that 
contains the root cause is too big a step for most mortals to do 
reliably on difficult problems. Better, as in the System Improvement 
Process or another suitable process, is to decompose this one big leap 
into several smaller ones, namely:

A. Find the feedback loops that are currently dominant.
B. Find the root cause of why they are dominant.

Most models that fail to lead to solution or deep insights on difficult 
problems omit step B. They *think* they have done it, but they haven't. 
As I mentioned earlier, the classic example of this is World3. Yes, it 
reproduces the problem symptoms. No, it does not contain the root cause 
of why the P and the A and the T in the IPAT equation embodied in the 
model are so hard to bring down to stay within the limits of the system.

But if the Limits to Growth (LTG) team, and many similar teams, had used 
a process with steps A and B, plus C, D, and E, they would have gone 
further. Or they would have said we have only done step A. We have only 
identified the problem. Actually they did say this, but not convincingly 
to many readers, who assumed the model contained the root causes. But 
since it did not, they could not logically be resolved. The result has 
been decades of intuitive solutions that have failed.

To make this point, my process paper manuscript says:

"Limits to Growth states that the project was not trying to solve the 
sustainability problem. It was only trying to identify it and alert the 
world. But there was such a gigantic vacuum for an analysis that readers 
soon assumed the project was the analysis they needed. The second and 
third editions started to fulfill these expectations, by adding chapters 
like “Transitions to a Sustainable System” and “Tools for the Transition 
to Sustainability.” (The third edition, Meadows, 2004) The tools were 
networking, truth-telling, learning and loving. But all this was done 
without actually changing the analysis. The model remained nearly 
completely untouched. What was happening is that, due to lack of a 
formal process that fit the problem, the LTG team was acting 
intuitively. They assumed their model was good enough and recommended 
solution strategies based on that. (This is not to subtract from the 
immense contribution the LTG team made in identifying the problem. The 
first step is usually the hardest.)"

When I model, I allow about 5 times as much time to do step B as step A. 
Better yet, I tell the client or myself this ahead of time, so they can 
expect things to go slow at first. Usually the model at the end of step 
B is barely recognizable compared to the one in step A.

It could be that my work focuses on difficult social problems, and most 
SD modelers work on business management problems, which are much easier, 
so much so they often don't need separate steps A and B.

Sorry if I'm going on a little long here. It's a subtle but important 
point.

Posted by  Jack Harich <register at thwink.org>
posting date  Sun, 16 Mar 2008 16:55:12 -0400