Ventana software support forum

Posted by Jack Harich <jack@thwink.org>

At the suggestion of a member of this list, I was working on a paper for
the SD Review on the System Improvement Process. The first draft is
complete. One area that may be weak or controversial is a definition of
the so called root cause.

I thought it was high time modelers had a formal definition of this
vitally important term. Plus finding the true root cause(s), and not
false ones, seems to me to be the crux of most analyses. Here’s an
extract from the paper:

- - - - - - - Begin Quote - - - - - - - -

The System Improvement Process (SIP) is designed to solve any difficult
social problem. Its four main steps are:

1. Problem Definition – Identify the problem

2. System Understanding (Analysis) – Analyze the problem/system until
key cause and effect relationships are understood. This step is so
important it has 5 substeps.

3. Solution Convergence – Use that knowledge to converge on a solution.

4. Implementation – Implement the solution.

Step 1. Problem Definition – Difficult complex system problems are best
defined starting with this format: Move system A under constraints B to
goal state C by deadline D with confidence level E. A problem is
“solved” when a solution is created that will move the system to goal
state C by deadline D with confidence level E.

Step 2. System Understanding (Analysis) – The goal of this step is to
understand the problem/system so well that its leverage points become
obvious. This will cause two supremely powerful insights about the
problem to emerge. The first is that because the system’s low leverage
points are now so clearly revealed, it becomes perfectly obvious why we
have been failing to solve the problem. The second is that because we
can now see where the high leverage points are, how to solve the problem
becomes a relatively simple matter of determining how to best push on
the correct leverage points. To execute this strategy, problem solvers
should spend approximately 80% of their time in this step.

This step is so important it has its own subprocess, contained in these
five substeps:

A. Find the feedback loops that are currently dominant.

B. Find the root cause of why they are dominant.

C. Find the low leverage points and symptomatic solutions.

D. Find the feedback loops that should be dominant.

E. Find the high leverage points to make them go dominant.


Let’s examine the five substeps:

A. Find the feedback loops that are currently dominant. – These are the
feedback loops it takes to reproduce the symptoms. These loops are the
immediate or proximate cause. This step is relatively easy, because
immediate causes are so obvious.

B. Find the root cause of why they are dominant. – Starting with the
immediate cause loops, you keep asking why until you arrive at the root
cause, which is those portions of the system that most deeply explain
why the system’s emergent behavior produces the problem symptoms.

This step eliminates the common pitfall of stopping when the first
plausible or satisfying cause of the symptoms is found, as in the World3
model. By framing the modeling challenge as finding why the loops in
step A are dominant, we stop thinking in terms of generalities like a
dynamic hypothesis, and more in terms of Kaizen, with a system dynamics
touch. The five whys of Kaizen (Imai, 1986, page 50) are all about
asking WHY until you arrive at the so called root cause.

Unless you have an easy problem this step is difficult. It is the most
important step in the analysis, so don’t shortchange it. Forrester did
not, which is why the urban decay model was so powerfully useful. The
root cause of stagnation was that once the urban area is filled by the
growth phase, “new construction is suppressed by lack of land within the
fixed and fully occupied area.” (Forrester, 1969, page 43) This leads to
urban decline.

A root cause has three identifying characteristics: (1) It is clearly a
major cause of the symptoms (2) It has no deeper cause. (3) It can be
resolved. Sometimes it’s useful to include unchangeable root causes in
your model for greater understanding. These have only the first two
characteristics.

Note how a problem can only be fully solved if its root cause is
resolved. If your model lacks the true root cause, then solving the
problem will depend on intuition and luck, no matter how good the model
is at reproducing the problem or plausibly explaining why it is
occurring, no matter how clever the solution, and no matter how hard the
solution is applied. For simplicity we say “root cause” when actually it
may be singular or plural.

- - - - - - - - End Quote - - - - - - - -

I had two questions: (1) Is this a productive and sufficiently
unambiguous definition of root cause? (2) Is finding the root cause
really the most important step in the average SD analysis for difficult
problems?

Thanks,

Jack
Posted by Jack Harich <jack@thwink.org>
posting date Sun, 02 Mar 2008 14:22:00 -0500
_______________________________________________

Posted by Jack Harich <register@thwink.org>

Fabian Fabian wrote:
> Jack,
> If we refer to Donnella Meadows ""Places to intervene in a System"" ,
> one could assume that for designing powerful solutions/interventions
> one should always dig down until reaching the paradigm level.
Thanks. I studied her paper awhile back, both the original and the later
version. Based on my own definition of high leverage point (HLP) versus
hers, I don't think she made a convincing case that ""one should always
dig down until reaching the paradigm level."" Here's why, using a quote
from elsewhere in the first draft of the paper I'm writing. This comes
right after the previously quoted material:


Alex Leus pointed out the definition at
http://en.wikipedia.org/wiki/Root_cause.

I've worked for so long with my definition and its role in a problem
solving process, that to be honest, I didn't even lookup other
definitions before making the post. So thanks Alex. This helps.

It's good to see ""The basic concept is that solving a problem by
addressing root causes is ultimately more effective than merely
addressing symptoms or direct causes."" - To me this is THE key point.

Also notice ""... the preceding example highlights one difficulty with
root cause analysis: knowing when to stop."" and ""There is little
agreement as to the types of conditions that can reasonably be
considered root causes."" and ""Practitioners of root cause analysis often
define what the phrase ""root cause"" means for a particular setting and
application."" - That's why a system dynamics centric process needs a
formal definition of root cause.

Getting more subtle, Wikipedia says ""An issue closely related to solving
an existing problem is to foster learning that will embed knowledge
(within a person, group, or organization) that may help prevent similar
problems from occurring in the future."" - This brings up the concept
that there are different types of root causes. This is an important
point. There are two types in the Wikipedia entry: The normal root cause
and the root cause of recurrence. The quote from the paper did not cover
this, but the System Improvement Process handles this via three reusable
subproblems, one of which is how to prevent problem recurrence. The
three subproblems are described elsewhere in the paper, as well as at
http://www.thwink.org/sustain/glossary/ ... rocess.htm.

Thus there are three distinctly different root causes to most difficult
social problems. Unless you have found and resolved all three, the
problem is unsolved. Worse yet, if you are looking for all three types
of root causes at the same time without realizing it, which I suspect
most are, then you are rarely going to find all three. Instead, you will
satisfice and stop which you've found only one or two. And even then,
due to the confusion induced by lack of awareness of the need to look
for all three, whatever you have found will probably not even be one of
the three true root causes.

The entry pointed to http://en.wikipedia.org/wiki/Root_cause_analysis.
In here is, sure enough, a ""General process for performing and
documenting a root cause analysis based corrective action."" The steps are:

1. Define the problem.
2. Gather data/evidence.
3. Identify issues that contributed to the problem.
4. Find root causes.
5. Develop solution recommendations.
6. Implement the recommendations.
7. Observe the recommended solutions to ensure effectiveness.

Step 3 corresponds to step 2A of the System Improvement Process (SIP).
Step 4 corresponds to step 2B. Step 5 corresponds to step 3 of SIP,
which is solution convergence. Notice the big intuitive leap from step 4
to 5 above. SIP says whoa, this is too big for most mortals to do
reliably. They don't eat nails for breakfast. They eat Cheerios, or in
my case, granola. Plus there is no concept of leverage points.
That's why SIP has steps 2C, 2D, and 2E.

So the seven step process above is for easy or medium problems. It's
fine. I can see it's what I use for everyday problems, like fixing my
car. But for difficult problems, especially social problems like
conflict, sustainability, obesity epidemics, etc, a much more powerful
process is needed.

Thanks again Alex,

Jack
Posted by Jack Harich <register@thwink.org>
posting date Mon, 03 Mar 2008 21:04:20 -0500
_______________________________________________

Posted by Fabian Fabian <f_fabian@yahoo.com>

Jack,

If we refer to Donnella Meadows ""Places to intervene in a System"" , one
could assume that for designing powerful solutions/interventions
one should always dig down until reaching the paradigm level.

Although that would be truth, in real contexts implementation impact
should be perceived in a much shorter time frame. Thus the amount of
""why"" could vary, and be validated by issue owners in order to be useful
for solving the specific issue at hand.

Cheers,

Fabian Szulanski
Instituto Tecnologico de Buenos Aires
Director
System Dynamics Centre

Posted by Fabian Fabian <f_fabian@yahoo.com>
posting date Mon, 3 Mar 2008 05:22:30 -0800 (PST)
_______________________________________________

Posted by Bill Braun <bbraun@hlthsys.com>

Jack Harich asks about the definition of root cause. Broadly stated, it
would be the structure that produces the reference mode up to the
present and, if policies were left as is, would result in the ""feared""
mode in the future.

Bill Braun
Posted by Bill Braun <bbraun@hlthsys.com>
posting date Mon, 03 Mar 2008 21:54:58 -0500
_______________________________________________

Posted by ""Jack Homer"" <jhomer@comcast.net>

I don't see how Jack Harich's emphasis on root causes is helpful.
Trying to find the ""true"" original or root causes in complex social
systems (unlike engineered systems) is a fruitless endeavor, because
when it comes to human behavior among multiple stakeholders there is no
end to the forces at play. The best we can do is to peel the onion of
causation to get a few more layers down. The way we do this is with
models that help us understand why current policy approaches are not
working or may lead to problems in the future, and why certain other
approaches may hold more promise.

Such models need to be able to reproduce the problem and plausibly
explain why it is occurring. I believe Mr. Harich is wrong to minimize
the importance of this step in the process, a step which is more often
than not the key to identifying more effective policy. I have
previously described this process of scientific investigation and
discovery in modeling; see ""Why We Iterate"", SD Review 1996.

Mr. Harich is under the impression that the Urban Dynamics model was
somehow more insightful and penetrating than the World3/World Dynamics
model. I have argued previously that both of these models produced
striking conclusions because of their artful weaving together of key
feedback structures and empirical observations and evidence; see
""Structure, Data, and Compelling Conclusions: Notes from the Field"", SD
Review 1997. Both models used the some process of inquiry, both peeled
the onion equally deep, and both delivered compelling conclusions that
altered the policy debates on urban decline and on global development.
They did not attempt to peel the onion to its center, which is
impossible, but only deep enough to reveal underlying forces--supported
by the evidence at hand--that could help policymakers and the general
public act with greater foresight.

- Jack Homer
Posted by ""Jack Homer"" <jhomer@comcast.net>
posting date Mon, 3 Mar 2008 09:45:27 -0500
_______________________________________________

Posted by Bill Braun <bbraun@hlthsys.com>

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 to
have added that once the model is constructed, the high leverage policy
or policies that (when changed, added, or deleted) produce the desired
(""hoped"") behavior would be indicators of the root cause (that is, the
root cause would be policies that are mal-designed, missing, or present
and problematic).

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"".

Humbly accepting the mantle of Dean of the Thou Shalt Have No Root Cause
school,

Bill Braun
Posted by Bill Braun <bbraun@hlthsys.com>
posting date Wed, 05 Mar 2008 06:15:00 -0500
_______________________________________________

Posted by Jack Harich <jack@thwink.org>

Colin Beveridge wrote:
> Jack
> My answer to your second question (below) might be rather naïve but I
> think that finding a single root cause for a complex problem might not
> always be possible.

Sorry, my mistake. The last sentence in the quoted section was ""For
simplicity we say 'root cause' when actually it may be singular or
plural."" I will modify the manuscript to mention this sooner.

Done. The first paragraph in the section on step 2B now ends with ""For
simplicity we say 'root cause' when actually it is usually plural.""

> A combination of asynchronous influences might contribute to a problem
> and the asynchronicity might disguise the combination of influences to
> the point of invisibility, defeating analysis to identify a single
> root cause. In other words, your analysis might identify strong causal
> candidates but no single cause actually manifests itself for long
> enough, or indeed ever presents itself again.
>
A really good point, that the system is changing and hence so are the
root causes you are trying to resolve. The System Improvement Process
accommodates this by dividing difficult social problems into three
subproblems: overcoming change resistance, achieving proper coupling,
and avoiding excessive model drift. If the last one, model drift, is
solved then your solution is self-managing and self-evolving.

Thanks for pointing this out.

Bill Braun wrote:
> Jack Harich asks about the definition of root cause. Broadly stated,
> it would be the structure that produces the reference mode up to the
> present and, if policies were left as is, would result in the ""feared""
> mode in the future.

Bill,

Ahhh, what an expansive way to put it! How succinct.

""it would be the structure that produces the reference mode..."" - Let's
see if I understand this. It usually takes the entire model to do this.
So the entire model is the root cause?

This seems to be the viewpoint that everything that contributes to a
problem's symptoms is a cause, and that trying to find a so called root
cause is counter productive. I wonder if there is a term for this school
of thought? The Thou Shalt Have No Root Cause school?


Regarding ""the structure that produces the reference mode"" - It's easy
to create a model that can create a problem's symptoms, without
including the root causes and without including time series data.

A simple example would be a model of an organism that, once infected,
gets sick. The model can beautifully handle the infection event, the
illness that follows, and maybe even getting well. The first root cause
of such a model would be the combination of an infection event and
susceptibility to infection. But if you want to go deeper, you could ask
WHY was the organism so susceptible? Was its immune system weak? Was
that in turn caused by bad diet and exposure to pollutants? Etc. So
there is a deeper root cause. Whether it's in the model or not does not
change the reference mode behavior. It will of course change other
scenarios.

As another example, consider World3. It roughly duplicates the
consequences of living unsustainably. But does it explain why there is
so much change resistance to solving the problem? Does it help us to
understand why in 1999 the US Senate voted an amazing 95 to 0 against
the Kyoto Protocol, even though the US had a democratic president and Al
Gore himself was vice president? No.

As far as I can tell, World3 only identified the problem, by modeling
the immediate causes in a convincing manner. These are the well known
IPAT forces. The model was a tremendous contribution. The first step is
usually the hardest. Next we need to dig quite a bit deeper and find out
the underlying causes, the ones that explain the intermediate causes
captured in World3. Only then will we be able to move on to resolving
the underlying causes.

> Posted by ""Jack Homer"" <jhomer@comcast.net>
>
> I don't see how Jack Harich's emphasis on root causes is helpful.
> Trying to find the ""true"" original or root causes in complex social
> systems (unlike engineered systems) is a fruitless endeavor, because
> when it comes to human behavior among multiple stakeholders there is
> no end to the forces at play. The best we can do is to peel the onion
> of causation to get a few more layers down. The way we do this is
> with models that help us understand why current policy approaches are
> not working or may lead to problems in the future, and why certain
> other approaches may hold more promise.
Jack,

Sorry to cause such a ruckus. This is a great, thoughtful message. Such
disagreement shows the field of system dynamics is at last in the early
Model Revolution phase of the Kuhn Cycle. The cycle has five phases:
Normal Science, Model Drift, Model Crisis, Model Revolution, and
Paradigm Change, as described at
http://www.thwink.org/sustain/glossary/KuhnCycle.htm.

In the Model Revolution phase, new ideas of how to most productively
tackle a field's central problems compete against each other. As
consensus on which of these will work develops, a new problem solving
model emerges. For SD this model contains things like how to model most
effectively, what principles to use where, notational standards,
completed model standards as discussed recently, etc. A mature model
allows the field to solve problems the previous one could not.

My humble offerings are an attempt to help build a new model for SD, one
that is good enough to solve difficult social problems. I'm sure my work
is chock full of errors and weakness. But because I'm an outsider and
new to the field, such efforts have the potential to offer fresh and
possibly more productive lines of attack.

Thanks. It is true that ""when it comes to human behavior among multiple
stakeholders there is no end to the forces at play."" But it does not
follow that this prevents us from finding the underlying causes of a
problem that, when resolved, will solve the problem.

You say ""Trying to find the 'true' original or root causes in complex
social systems (unlike engineered systems) is a fruitless endeavor...""
This says that finding root causes is easier in engineered systems. I
agree. But that does not prevent us from finding them in non-engineered
systems. It only makes it harder.

Is a corporation an engineered system? I think not. They are big pieces
of putty shaped by the intuitive whims of many managers, over time in an
evolutionary manner. But we routinely apply SD to corporate problems
with great success. We do this by finding the hidden underlying causes
and resolving them.


> Such models need to be able to reproduce the problem and plausibly
> explain why it is occurring. I believe Mr. Harich is wrong to
> minimize the importance of this step in the process, a step which is
> more often than not the key to identifying more effective policy. I
> have previously described this process of scientific investigation and
> discovery in modeling; see ""Why We Iterate"", SD Review 1996.
>
I think we are in agreement here. SIP step 2A (see below) reproduces the
problem, by modeling the dominant feedback loops that cause the
symptoms. Step 2B then explains why they are dominant by finding the
root causes. Thus steps 2A and 2B are the same as ""reproduce the problem
and plausibly explain why it is occurring."" I wrote that 2A is
relatively easy and 2B is hard. Together, 2A and 2B are hard, so there
seems to be no difference in our viewpoints. I've only decomposed mine
differently from the way modelers usually approach their task.

The key difference may be that I'm deliberately using stronger, more
precise language than ""plausibly explain."" I prefer ""find the root
cause"" because that emphasizes we must dig deep to solve big hairy
problems. This also allows a finer grained process, as the steps below
show.

I do think finding the immediate causes is easy, compared to finding the
root causes. That's what makes difficult problems difficult.

For reference, step 2 of the System Improvement Process (SIP) analyzes
the problem/system until the key cause and effect relationships are
understood. Step 2 has these five substeps:

A. Find the feedback loops that are currently dominant.
B. Find the root cause of why they are dominant.
C. Find the low leverage points and symptomatic solutions.
D. Find the feedback loops that should be dominant.
E. Find the high leverage points to make them go dominant.

I had not read your ""Why We Iterate"" article before. A good read. I
learned a lot. Marvelous cases. The Lessons section was meaty and I will
refer to them in a new project I'm starting this week. Thanks!



> Mr. Harich is under the impression that the Urban Dynamics model was
> somehow more insightful and penetrating than the World3/World Dynamics
> model. I have argued previously that both of these models produced
> striking conclusions because of their artful weaving together of key
> feedback structures and empirical observations and evidence; see
> ""Structure, Data, and Compelling Conclusions: Notes from the Field"",
> SD Review 1997. Both models used the some process of inquiry, both
> peeled the onion equally deep, and both delivered compelling
> conclusions that altered the policy debates on urban decline and on
> global development.
Regarding ""both peeled the onion equally deep"" - I think there was a
major difference. There are several proofs:

(1) One is that the conclusions of the urban decay model allowed urban
managers to adopt policies that were immediately effective, although the
problem has not been completely solved. This has not happened on the
environmental sustainability problem. 36 years after publication of LTG,
the world is nowhere near solving the problem. No policies have been
introduced that were immediately effective. Many have been slightly
effective. This indicates that problem solvers have been addressing
intermediate causes, rather than root causes. This causes them to push
on low leverage points (LLPs) instead of HLPs.

(2) Another proof is from the analytical viewpoint of the System
Improvement Process. Examination of the urban decay model shows it
performed all five steps of SIP step 2. Looking at World3, I only see
step 2A performed. Others may see this quite differently, but when I
examine the model, I ask where are the root causes? What in the model
explains WHY the dominant social agents are so addicted to perpetual
growth? What in the model explains WHY the preferred, intuitive solution
to the problem has largely been to lower impact per unit of consumption
and continue to raise the limits? That this only postpones the day of
reckoning and makes collapse bigger when it finally comes shows this is
an erroneous solution. But WHY has it been followed? There is no hint of
this in the model. And so on. Thus when problem solvers attempt to use
World3 to solve the problem, they have no deep root causes to resolve.
They have nothing to steer by, and are as lost as a ship at see without
a compass.... (Whoops, getting carried away.)

(3) If we search for the root causes of the sustainability problem using
SIP, it's possible to come to radically different conclusions than
World3 did. (But of course the authors caution their goal was not a deep
analysis, but to alert the world to the presence and magnitude of the
problem.) I've been working on this problem full time since 2001. If you
read the Dueling Loops of the Political Powerplace paper at
http://www.thwink.org/sustain/articles/ ... _Paper.htm, you
will see an example of what happens when you keep asking WHY longer than
the rest of the herd. You keep throwing away false root causes until you
come to ones that fully satisfy the process. On page 9 of the full
length version the paper says:

""We now have enough pieces of the puzzle to draw an important
conclusion: The dueling loops, their cyclic nature, the inherent
advantage of the race to the bottom, the presence of the New Dominant
Life Form, and its successful exploitation of the race to the bottom are
the structural root cause of most of the stiff, prolonged resistance to
adopting a solution to the environmental sustainability problem.
Civilization is presently stuck in the dominant race to the bottom part
of the cycle. Our challenge is to cause this cycle to end as soon as
possible, and then to prevent it from ever starting again. If we can do
that civilization will not only enter the Age of Transition to
Sustainability. It will also enter an entirely new mode: a permanent
race to the top among politicians, along with all that has to offer, but
has never been achieved.""

This is not a simplistic root cause. Several dozen readers have told me
it makes complete sense and explains so much. No one has found a flaw in
it. But even if there is a flaw (I'm sure there are at least some) the
analysis should illustrate that it is possible to go much deeper than
the LTG analysis went, by finding the true root causes, and then the
LLPs and the HLPs.



> They did not attempt to peel the onion to its center, which is
> impossible, but only deep enough to reveal underlying
> forces--supported by the evidence at hand--that could help
> policymakers and the general public act with greater foresight.
That's why we need a tight definition of root cause - so modelers will
know when to stop and avoid going too far or not far enough.

My definition of root cause is ""those portions of the system that most
deeply explain why the system’s emergent behavior produces the problem
symptoms"" and ""A root cause has three identifying characteristics: (1)
It is clearly a major cause of the symptoms (2) It has no deeper cause.
(3) It can be resolved.""

Step 2B is done when you have achieved the goal of finding the root
cause, as defined. There's no cookbook procedure to guarantee you will
get there. But the clarity of the goal makes it much more likely you
will arrive. (Perhaps we need to add more characteristics, so we can
have a more reliable checklist.)

In a short paper there's little room to discuss the intricacies of
finding the root causes. This takes a lot of iteration through steps 2
and 3, and eventually step 4. It's these iterations that allow you to
test whether you have found root causes that can be resolved within the
constraints of the problem definition. If they can't, then it's back to
step 2. I'm a believer in the power of intelligent iteration, just like
the fellow who wrote ""Why We Iterate.""

I will modify the manuscript to mention the importance of iteration....
There, done. I've added this paragraph: ""It takes a lot of iteration to
find the root causes. The steps (especially 2E and experimentation in 3)
that follow 2B allow you to test whether you have found a satisfactory
set of root causes and to iteratively refine them until they are correct
enough to solve the problem.""


Jack, I really hope this helps. All I'm trying to do is help our field
zoom its way out of infancy, and on into its mature years. After all,
there are a lot of fascinating, challenging problems just sitting out
there, waiting for analysis and solution. Some have been waiting for a
long, long time. A few, if they are not solved soon, have consequences
that are too horrific to grasp....

Muchos gracias,

Jack
Posted by Jack Harich <jack@thwink.org>
posting date Tue, 04 Mar 2008 21:58:13 -0500
_______________________________________________

Posted by ""Kim Warren"" <Kim@strategydynamics.com>

This may be a slightly different take on the question, and I don't know
about its theoretical validity, but some principles from an SD depiction
of how things work seems to produce the following line of reasoning - at
least in the business situations I work in.

Working back from the performance outcome we are concerned with [growing
sales, improving profits, fixing service quality etc. ] a logical
disassembly of the arithmetical relationships involved produces a causal
chain structure that ends with one of three types of factor:
1 - one or more stocks [customers, capacity, staff]
2 - one or more decision-items [price, marketing, salaries]
3 - one or more exogenous factors beyond the influence of either
management or the system itself [demographic changes, competitors'
prices ...]
At any instant in time, then, these three categories seem to cover all
'root causes' [not sure how this fits with the way the term is generally
defined]

If these three items remain unchanged, then performance remains exactly
the same. The only way for performance to change under constant
decisions and exogenous factors is for stock levels to change [win
customers, lose staff ...], and the only way for that to happen is for
flow-rates to be non-zero. So the causal investigation asks what drives
flow-rates. Adopting the same principles above, an arithmetic
investigation of what causes what behind each flow rate seems to arrive
at exactly the same three items:
1 - one or more *existing* stock levels [current staff drive service
quality, which drives customer loss rate]
2 - one or more decision items [price drives customer loss rate] ..
though some flow-rates are themselves simply decisions, e.g. adding
capacity
3 - one or more exogenous factors [demographics affect changes in
customer numbers, competitors' price drives customer losses]

This logic also seems to answer the question 'where to stop' - we stop
when we get to a stock, a decision-item or a factor that is outside the
control of management or of the system itself. This does break the
'close-the-loop' philosophy - but we know how to depict decisions
emerging from policies influenced by system performance, and many
exogenous factors are genuinely 'out there' for all practical purposes -
nothing I can do about demographic change, and little I can do to alter
competitors' prices.

Kim Warren
Posted by ""Kim Warren"" <Kim@strategydynamics.com>
posting date Wed, 5 Mar 2008 07:20:53 -0000
_______________________________________________

Posted by ""nickols@att.net"" <nickols@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).

I think there is too much testimony to the efficacy of a quest for root
cause to dismiss it out of hand but I also believe that it is a concept
(and a technique) that is far from universally applicable.

Regards,

Fred Nickols
Posted by ""nickols@att.net"" <nickols@att.net>
posting date Tue, 04 Mar 2008 15:15:50 +0000
_______________________________________________

Posted by ""Colin Beveridge"" <colin@colin.beveridge.name>

Jack

My answer to your second question (below) might be rather naïve but I think
that finding a single root cause for a complex problem might not always be
possible.

A combination of asynchronous influences might contribute to a problem and
the asynchronicity might disguise the combination of influences to the point
of invisibility, defeating analysis to identify a single root cause. In
other words, your analysis might identify strong causal candidates but no
single cause actually manifests itself for long enough, or indeed ever
presents itself again.

Regards
ColinB
Posted by ""Colin Beveridge"" <colin@colin.beveridge.name>
posting date Tue, 4 Mar 2008 13:47:14 -0000
_______________________________________________

Posted by Jack Harich <jack@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/ ... gyMaps.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@att.net"" <nickols@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/ ... _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@thwink.org>
posting date Wed, 05 Mar 2008 09:51:37 -0500
_______________________________________________

Posted by ""Ulrey, Michael L"" <michael.l.ulrey@boeing.com>

This thread is of particular interest to me because ""root cause"" is a term
which is very popular in the fields of system engineering in general, and
reliability and safety engineering in particular. (And among other things,
I work in system safety engineering at Boeing.)

Within the the reliability and safety organizations of the aerospace industry,
there is a long tradition of processes and methods for identifying root causes
and either eliminating them or mitigating against their operational
consequences if elimination is not possible. Of course, other industries also
have similar practices, most notably the nuclear and chemical industries. This
kind of approach works well for systems or processes which have a certain (low)
level of complexity. However, for much more complex socio-technical systems
(such as air traffic management), such an approach may come up short. Ever
since the Uberlingen tragedy (see
http://www.dcs.gla.ac.uk/~johnson/Euroc ... Report.PDF
or a variety of other discussions on the Internet), the safety community is
starting to realize that, as one prominent accident expert said, ""the root
cause is simply the last contributing factor that was found before the
resources ran out"".

In short, there is a movement away from traditional static, linear models such
as the domino model or the Swiss cheese model. See the first link below for
the revised thinking on the Swiss cheese model as a result of the Uberlingen
accident. Instead, more complex systemic models are needed that reveal how
accidents can arise naturally from the internal dynamics of the system, not
necessarily from outside causes, or even from internal failures, as is
traditionally supposed. This idea is well-expressed in the second link below,
in which the ""functional resonance accident model"" (FRAM) is described.


http://www.eurocontrol.int/eec/gallery/ ... Arial).pdf

http://www.eurocontrol.int/eec/gallery/ ... 006_13.pdf


Finally, I would offer up the recent book by Hollnagel, Woods, and Leveson, called
""Resilience Engineering"", which contains a series of essays on these topics. The
view is that some systems that affect our lives and safety must be designed to be
resilient, that is, able to recover from inevitable surprising upsets, rather than
attempting to make them totally free of defects, which is practically impossible.
I think this is an area that may be unknown to many SD theorists, and provides a
rich area for research. In fact, one of the authors, Nancy Leveson of MIT, has used
SD to model the NASA organizational structure and processes to try and understand
the Challenger and Columbia shuttle accidents.

http://books.google.com/books?id=S8VbgW ... -thumbnail

On a personal note, I have recently learned how to model in Vensim, and have already
produced a simple model having to do with air traffic management, and how to increase
capacity while preserving an appropriate level of safety. I am hoping to continue with
this work, having proposed a research project within my organization at Boeing. I
think SD can make a real contribution in this important arena.

Mike


Dr. Michael L. Ulrey
Associate Technical Fellow
Air Traffic Management
The Boeing Co.
Posted by ""Ulrey, Michael L"" <michael.l.ulrey@boeing.com>
posting date Wed, 5 Mar 2008 10:01:35 -0800
_______________________________________________

Posted by ""Kim Warren"" <Kim@strategydynamics.com>

Sorry jack - My reply was not as clear as it could have been ... and
maybe I'm not as clear about 'root-cause analysis [RCA]' as I should be
either ...

I am assuming we are trying to understand the deep, underlying reasons
why something is not happening as we wish it to - a problem is
persisting or some performance we want is not improving as we would
like. I am also assuming that since we are an SD interest-group, the
indicator of concern is changing over time, rather than just being a
static question.

The causal tracing I tried to summarise before follows as rigorous an
arithmetical logic as possible, e.g. ""profit = revenue minus costs"",
""delivery performance = on-time-deliveries/month divided by
total-deliveries/month"" and so on. After repeating this question of what
causes each of these next elements, and continuing a few times, you seem
always to get back to one or more stocks, one or more decisions, and one
or more exogenous factors. For an airline example I've worked on:
- ""revenue/year = passenger-journeys/year * fare-per-journey"" [fare
being a decision]
- ""passenger-journeys/year = customers * journeys/year-per-customer""
[customers being the stock of people who routinely use the airline, and
dominate its sales]
- ... and our ""journeys/year per customer"" depends on our fare [a
decision] vs. rivals' fares [an exogenous factor]

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 not very
insightful or useful, because we want a *dynamic* answer rather than a
static one - i.e. why are revenues not growing as fast as we want?
Only a part of this is likely to be explained by changes to
journeys/year-per-customer. A larger part will reflect changes to the
stock of customers, and this can only be changed by flow-rates - if no
customers are won or lost, then customer numbers remain the same and,
ceteris paribus, revenue will not change. This means that to continue
the quest for root-causes we have to explain what causes the rate of
customer wins and losses. ... and if we keep asking what-causes-what
behind those flow-rates, it seems we get back to the same three
categories of items, e.g.:
- ""customers won per year = some function of the potential customers on
the routes we serve"" - [a current stock level]
- ""customers lost per year = some function of load factor, reflecting
customers and aircraft "" - [another stock-level]
- ... and some function of our price [a decision] and or rivals' prices
[an exogenous factor].
If this is still not clear, here's a book chapter that explains in more
detail - www.strategydynamics.com/c4. It doesn't constitute any grand
'theory', nor is it any different than how SD has always depicted
situations. But the principles do seem to hit the main criteria needed
to solve dynamic problems, being as far as I can see general, useful and
true.
As I say, RCA is not my field, but what I see on Wiki seems *very* close
to what we do with SD, and implies that root-causes will ultimately be
found in the three classes of factor above - stock-levels, decisions, an
exogenous factors. 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? [unless there are resource-shortages or exogenous factors that
just make good outcomes impossible, no matter how well we make
decisions!]

Kim
Posted by ""Kim Warren"" <Kim@strategydynamics.com>
posting date Wed, 5 Mar 2008 17:50:45 -0000
_______________________________________________

Posted by ""Jack Homer"" <jhomer@comcast.net>

Now that Jack Harich has clarified that he's looking for ""the key
elements of the model [or, better, the real world or the problematic
system] that cause it to behave the way it does"", I think we have an
answer for him from SD and need look no further. We call ""root cause""
the dynamic hypothesis. And, we call ""good solution"" (the other concept
Jack talks about) a high leverage point. Note that a high leverage
point can refer to turning an existing lever or, alternatively,
intervening in a way that creates an entirely new feedback loop. The
presence of the word ""hypothesis"" in dynamic hypothesis reflects my
earlier comment that we can never really peel to the heart of the onion
as one might do in an engineered system, but rather can only go down a
few layers to where we can see some underlying delay and feedback
structures that may help to explain the source and persistence of a
problem.

- Jack Homer
Posted by ""Jack Homer"" <jhomer@comcast.net>
posting date Thu, 6 Mar 2008 08:52:05 -0500
_______________________________________________

Posted by Ralf Lippold <ralf_lippold@web.de>

Hi Jack,
hi discussion participants,

I have been really struck by the interest this first posting initiated
amongst the system dynamics community.

Thanks a lot for starting it:-))

As I moderate a group on the questions around ""Lean Thinking""
(http://www.xing.net/lean) the posted question is one of the key
""mysteries"" in understanding disfunctional processes. From my personal
experience I have added some thoughts on the initial quote:

> The System Improvement Process (SIP) is designed to solve any difficult
> social problem. Its four main steps are:
>
> 1. Problem Definition – Identify the problem
>
> 2. System Understanding (Analysis) – Analyze the problem/system until
> key cause

This can't be more than the ""key cause"" that can be understood by the
people involved when questioned the ""5-Whys"" in a very deep manner. The
questions should be asked until the 5th question or a phase where there
emerges no additional seeable reason.

So you avoid at least the ""quick fix"" that leads into the ""Fixes that
Fail"" archetype and even more trouble than you could image.

> and effect relationships are understood.

The cause and effect will be probably never be fully understood as
systems are complex and as you change one parameter in there all the
others change (if not immediately than over time).

> This step is so
> important it has 5 substeps.
>
> 3. Solution Convergence – Use that knowledge to converge on a solution.
>
> 4. Implementation – Implement the solution.

Try to use the ""solution"" in a small, to be overlooked part of the
system so possible negative impact on the overall system is put to a
minimum (especially in car production or manufacturing processes instant
changes in the system will bring real disturbance into it).

> ....
> I had two questions: (1) Is this a productive and sufficiently
> unambiguous definition of root cause?

Not quite from my point of view as too complicated especially on the
shopfloor or at places where the ""real"" work is done.

> (2) Is finding the root cause
> really the most important step in the average SD analysis for difficult
> problems?

The searching for the root cause will emerge -eventually- in deeper
understanding what is going on in the system and how the different parts
are connected. This will lead to a shared vision and understanding -
this is the real benefit of the method.

This are my instant thoughts on the issue (that is more complex as we
all probably think)

Cheers,

Ralf
Posted by Ralf Lippold <ralf_lippold@web.de>
posting date Fri, 7 Mar 2008 00:31:05 -0500
_______________________________________________

Posted by <BalaporiaZ@schneider.com>

Good conversation and interesting perspectives, as always. Two thoughts to
add. Not sure yet how / if they come together.

Thought 1
=========
I admire the quest for a definition of root cause. But I think it is less
about better definition and more about good judgement. I would suggest
that ""root cause(s)"" is more of a concept than a goal. For example, I
don't take the ""ask why 5 times"" too literally. I don't think there is a
scientific basis for the number 5 (is there?), but it is still a good
practical upper bound.

Thought 2
=========
The main thing I got from my excellent but very compact SD education is
that the root cause of almost all our problems is the lack of a good shared
mental model. The most important model of the real world problem isn't the
abstraction that is captured in equations. It's the abstraction that sits
between our ears. So regardless of how good the analysis is, if it doesn't
change my behavior then I become the root cause of the problem. People
don't act in accordance with the output of simulation models, they act in
accordance with their beliefs. I think that is as root cause as it gets.
This is not new to anyone on this list but it seemed like a fundamental
point that had not been raised.

Cheers.

Zahir Balaporia
Director, Decision Engineering
Schneider National, Inc.
Posted by BalaporiaZ@schneider.com
posting date Fri, 7 Mar 2008 14:13:58 -0600
_______________________________________________

Posted by Ralf Lippold <ralf_lippold@web.de>

Hi everybody,

Zahir has made an excellent point in questioning whether ""5-Whys"" lead
to a goal. Isn't that rather a VISION that we have to set in comparision
to CURRENT REALITY?

This makes a totally different point as we have to get an understanding
what the VISION is (shared vision) in order to strive for it. Just
making the goal, meaning to solve the problem in the first hand doesn't
account for an sustainable VISION. As mentioned in the ""Fifth
Discipline"" by Peter Senge together with four other fields (personal
mastery, mental models, systems thinking and team learning).

All five are necessary to move to the state of a learning organization
(actually the SD community) seeing that they unsurface around
communities -slowly- makes me think that

> Posted by BalaporiaZ@schneider.com
> The main thing I got from my excellent but very compact SD education is
> that the root cause of almost all our problems is the lack of a good
> shared mental model.

As soon as these mental models are brought into the open people involved
get a chance to challenge them and their own assumptions actually and
learn from there further on.

> The most important model of the real world problem isn't the
> abstraction that is captured in equations.

Actually that's more of a ""pure"" engineerical point on the world. As the
interconnections between humans are not just driven by numbers, goals
and rewards that makes intervening into a living system such as a human
driven organization or society so much more difficult and sometimes
foggy in terms of future outcome of the actions.

> It's the abstraction that sits
> between our ears. So regardless of how good the analysis is, if it
> doesn't
> change my behavior then I become the root cause of the problem. People
> don't act in accordance with the output of simulation models, they act in
> accordance with their beliefs.

..and the direct reactions that can be seen by them on a rather short
time horizon.

> I think that is as root cause as it gets.
> This is not new to anyone on this list but it seemed like a fundamental
> point that had not been raised.
>

As the discussion grows over time it gets more and more connection with
other interesing questions that arise by that and connecting to other
fields of interest / daily work / daily life.

It is great to see that the SD community is a living body that changes
over time -and whatever direction is taken is the right one for the time
being. There had been other starting points for similar discussions in
the past they didn't seem to florish. For some ideas the time has to
come and people have to put earlier questions/discussions into account
and connect them to their own experiences.

Always remember you -almost- never can change a system as you wish
(remember whether you could really change the behavior of your kids,
spouse, friends or peers by just making them do what you wanted or
thought would be best. Did it really work? NO - probably not over a
longer time).

Best regards

Ralf
Posted by Ralf Lippold <ralf_lippold@web.de>
posting date Sat, 8 Mar 2008 12:20:07 -0500
_______________________________________________

Posted by Bill Braun <bbraun@hlthsys.com>

Ralf Lippold talks about surfacing mental models and opening them to
challenge in the context of building shared vision.

I've recently been facilitating conversations at work where the process
is centered on the future people want. I've found that while the future
anyone wants is shaped by their mental models of the past/present,
speaking of a desired future skips over, in large part, the
problematizing of the past/present. As such, the challenging that takes
place emerges around the ""even better future"" that one person sees as a
function of building on someone else's picture of their desired future.

The result is a strong shared vision, it resonates with passion, and
people make public promises to bring the future into the present.

For more on this see designedlearning.com.

Bill Braun
Posted by Bill Braun <bbraun@hlthsys.com>
posting date Sun, 09 Mar 2008 09:47:05 -0400
_______________________________________________

Posted by Jack Harich <register@thwink.org>


SDMAIL Ulrey, Michael L wrote:
> This thread is of particular interest to me because ""root cause"" is a
> term which is very popular in the fields of system engineering in
> general, and reliability and safety engineering in particular. (And
> among other things, I work in system safety engineering at Boeing.)

Thanks for sharing this. I wonder why those solving problems with system
dynamics (as represented by replies on this list) tend to not find
thinking in terms of root causes productive. Do you have any theories on
this? I'm starting to get a little stumped.


> Of course, other industries also have similar practices, most notably
> the nuclear and chemical industries. This kind of approach works well
> for systems or processes which have a certain (low) level of
> complexity. However, for much more complex socio-technical systems
> (such as air traffic management), such an approach may come up short.
> Ever since the Uberlingen tragedy (see
> http://www.dcs.gla.ac.uk/~johnson/Euroc ... Report.PDF
> or a variety of other discussions on the Internet), the safety
> community is starting to realize that, as one prominent accident
> expert said, ""the root cause is simply the last contributing factor
> that was found before the resources ran out"".

This would be the last event that directly caused the undesired system
behavior. This clearly is not a root cause, so what is the ""prominent
accident expert"" trying to say here? That there is no one root cause? If
so, I agree. There are usually multiple root causes for difficult problems.

""However, for much more complex socio-technical systems (such as air
traffic management), such an approach may come up short."" - Without
saying why, this says that root cause analysis doesn't work for ""more
complex socio-technical systems""? I wonder why? Does anyone have an
opinion on this?

Maybe it's that root cause analysis, as popularly defined, doesn't work.
But that should not prevent us from developing another approach that can
successfully and routinely find root causes in difficult social problems.



> In short, there is a movement away from traditional static, linear
> models such as the domino model or the Swiss cheese model. See the
> first link below for the revised thinking on the Swiss cheese model as
> a result of the Uberlingen accident. Instead, more complex systemic
> models are needed that reveal how accidents can arise naturally from
> the internal dynamics of the system, not necessarily from outside
> causes, or even from internal failures, as is traditionally supposed.
> This idea is ell-expressed in the second link below, in which the
> ""functional resonance accident model"" (FRAM) is described.
>
Great links. Thanks! Very interesting. I think that in some cases
functional resonance can explain a social problem. An example would be
the outbreak of war. But at the same time, there are deep underlying
causes that, if resolved, would make it very unlikely for wars to occur.
These are what I refer to as root causes.

In the case of the European community, one such root cause was lack of
shared reasons to cooperate. This was resolved by creating the European
Union. Indeed, this was the main reason the EU was formed: to avoid more
wars in Europe. If we continue to see no more wars between countries in
the EU, then this must be because they intentionally resolved the root
cause of insufficient motivation to cooperate, and/or that additional
root causes somehow resolved themselves. I lean towards the former as
the explanation. But not living in the EU I am not abreast of many EU
issues, and so could easily be missing something.

> Finally, I would offer up the recent book by Hollnagel, Woods, and
> Leveson, called ""Resilience Engineering"", which contains a series of
> essays on these topics. The view is that some systems that affect our
> lives and safety must be designed to be resilient, that is, able to
> recover from inevitable surprising upsets, rather than attempting to
> make them totally free of defects, which is practically impossible. I
> think this is an area that may be unknown to many SD theorists, and
> provides a rich area for research. In fact, one of the authors, Nancy
> Leveson of MIT, has used SD to model the NASA organizational structure
> and processes to try and understand the Challenger and Columbia
> shuttle accidents.
>
>
Nice, especially since I just read Feyman's ""What do you care what other
people think?"" last week. The second half of the book was his take on
the Challenger disaster, and his role in deciphering the deeper causes.

""some systems... must be designed to be resilient"" - Yes. This includes
social systems.
> On a personal note, I have recently learned how to model in Vensim,
> and have already produced a simple model having to do with air traffic
> management, and how to increase capacity while preserving an
> appropriate level of safety. I am hoping to continue with this work,
> having proposed a research project within my organization at Boeing. I
> think SD can make a real contribution in this important arena.
>
It probably can. Good luck with it.

SDMAIL Jack Homer wrote:
> Posted by ""Jack Homer"" <jhomer@comcast.net>
>
> Now that Jack Harich has clarified that he's looking for ""the key
> elements of the model [or, better, the real world or the problematic
> system] that cause it to behave the way it does"", I think we have an
> answer for him from SD and need look no further. We call ""root cause""
> the dynamic hypothesis.
Hi Jack. Great discussion!
Page 86 of Sterman says ""Formulate a dynamic hypothesis that explains
the dynamics as endogenous consequences of the feedback structure."" This
implies that the definition of ""dynamic hypothesis"" is ""the feedback
structure"" of the model. This seems to mean the entire model.

Or Bill Braun, in an earlier message, suggested that ""Jack Harich asks
about the definition of root cause. Broadly stated, it would be the
structure that produces the reference mode up to the present and, if
policies were left as is, would result in the 'feared' mode in the future.""

This is the point at which my viewpoint diverges from the mainstream. I
view the root cause(s) of a problem as specific points or areas in a
model. Others seem to view it as the entire model, since it takes the
entire model to reproduce the reference mode. So I'm confused. What to
you is the root cause?


> And, we call ""good solution"" (the other concept Jack talks about) a
> high leverage point. Note that a high leverage point can refer to
> turning an existing lever or, alternatively, intervening in a way that
> creates an entirely new feedback loop.
Sorry if I haven't explained myself clearly. To me a high leverage point
(HLP) is usually a specific node in a model. Changing its value
represents the pressure of a solution. So the HLP is WHERE you apply
pressure. HOW you apply it is the solution. There are many ways to push
on a HLP, so there are many possible solutions. For example, the long
original version of the Dueling Loops paper lists six solution elements.
Each pushes on the HLP in a different way. The exact mix of how each
solution element is applied is the total solution.

The other case is the one you mention: creating a new feedback loop(s).
But even a new loop serves to push on existing nodes. Otherwise there is
no way to attach it to the system. This is why I tend to think in terms
of HLPs as being specific nodes.

As far as I can tell, it's much harder to find the HLPs on a difficult
problem than it is to determine how to push on them. Once the HLPs are
found, figuring out how to push on them is relatively easy. A similar
argument holds for root causes versus solutions. Once you find the true
root cause, how to resolve it is often strategically obvious. For
example, I did a presentation Friday of last week in which a slide said:

1. Identify the patient: The environmental movement

2. Describe the symptoms: Unable to solve the sustainability problem

3. Perform a diagnosis: Use of the wrong tools on difficult problems,
due to use of Classic Activism. This causes pushing on low leverage
points. (the root cause)

4. Determine the treatment: Use of the right tools on difficult
problems, due to use of Analytical Activism. This will allow pushing on
high leverage points. (the solution)

Notice how easily the solution follows from the root cause. If the root
cause is the WRONG tools, then the solution must be the RIGHT tools.

I hope this explains the notion that HLPs and solutions are two
different things. The fact they are allows problem solvers to decompose
one big step into two smaller steps, each of which is much easier to
solve. This is what process maturity is all about: more efficient
problem decomposition.

> The presence of the word ""hypothesis"" in dynamic hypothesis reflects
> my earlier comment that we can never really peel to the heart of the
> onion as one might do in an engineered system, but rather can only go
> down a few layers to where we can see some underlying delay and
> feedback structures that may help to explain the source and
> persistence of a problem.

""we can never really peel to the heart of the onion"" - Yes. But that is
merely the present state of the soft sciences. As they mature, we will
come to see the structure of social systems as clearly as we can see the
structure of physical systems today. SD is one tool that allows us to do
this. But we need more. I'm arguing that a more mature process is one of
them. Such a process will have powerful productive steps, like finding
the root cause.

Also, as you say we don't need to completely peel the onion. We only
need to understand the system enough to solve the problem. That's what
the System Understanding step of the System Improvement Process is all
about.

> Posted by Ralf Lippold <ralf_lippold@web.de
>> The System Improvement Process (SIP) is designed to solve any
>> difficult social problem. Its four main steps are:
>>
>> 1. Problem Definition – Identify the problem
>>
>> 2. System Understanding (Analysis) – Analyze the problem/system until
>> key cause
>>
>
> This can't be more than the ""key cause"" that can be understood by the
> people involved when questioned the ""5-Whys"" in a very deep manner.
> The questions should be asked until the 5th question or a phase where
> there emerges no additional seeable reason.
>
Actually the System Improvement Process (SIP) goes quite a bit deeper
than the 5 whys. The five substeps of step 2 of SIP allow analysts to
find five different classes of causes. Recall the five substeps are:

A. Find the feedback loops that are currently dominant.
B. Find the root cause of why they are dominant.
C. Find the low leverage points and symptomatic solutions.
D. Find the feedback loops that should be dominant.
E. Find the high leverage points to make them go dominant.

Thinking abstractly, the first cause of the symptoms is the loops that
are currently dominant. The cause of that is the root cause. The cause
of solution failure to date is pushing on the LLPs with symptomatic
solutions. The cause that would resolve the root cause is the loops that
should go dominant. The cause that would do this is the HLPs.

I hope this helps you see there is a far more penetrating way to
understand the key cause and effects of a difficult problem than the
five whys.

> So you avoid at least the ""quick fix"" that leads into the ""Fixes that
> Fail"" archetype and even more trouble than you could image.
>
Yes, a very good point.

Thanks,

Jack
Posted by Jack Harich <register@thwink.org>
posting date Tue, 11 Mar 2008 23:30:32 -0400
_______________________________________________

Posted by ""Jack Homer"" <jhomer@comcast.net>

Jack Harich writes:
> Page 86 of Sterman says ""Formulate a dynamic hypothesis that explains
> the dynamics as endogenous consequences of the feedback structure.""
> This implies that the definition of ""dynamic hypothesis"" is ""the
> feedback structure"" of the model. This seems to mean the entire model.

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. The latter is pretty easily done in most models,
with all of the tools of model analysis we have at our disposal. The
former, however, is not so easily done, and comes down to the process of
posing a dynamic hypothesis, testing it out in a computer model, and
then revising the dynamic hypothesis until it can do a good job of
reproducing the real situation and for what appear to be the right
reasons, and resulting in plausible behavior when extended into the
future, and even when tested under extreme conditions.

> The other case is the one you mention: creating a new feedback
> loop(s). But even a new loop serves to push on existing nodes.
> Otherwise there is no way to attach it to the system. This is why I
> tend to think in terms of HLPs as being specific nodes.

There is a big difference, both in a model and in real life, between
creating a new feedback loop and manipulating an existing lever.
Creating a new feedback loop means designing and implementing a whole
new way of doing things, which takes a lot more work and creativity than
tweaking what's already there or already well understood.

- Jack Homer
Posted by ""Jack Homer"" <jhomer@comcast.net>
posting date Wed, 12 Mar 2008 09:36:04 -0400
_______________________________________________

Posted by Jack Harich <register@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@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@thwink.org>
posting date Sun, 16 Mar 2008 16:55:12 -0400
_______________________________________________

Posted by ""John Gunkler"" <jgunkler@sprintmail.com>

Root cause analysis is a foundation of the process improvement methodologies
(such as Six Sigma) in business.

I am not speaking authoritatively here, but it seems to me that what happens
in real life is that we stop looking for a root cause when ...
(1) We have found (at least) the fifth one [there's a method called the ""5
Why's"" that suggests you ask ""Why?"" at least five times, iteratively, before
accepting the answer.]
(2) We suspect that delving any deeper will not be productive; and
(3) We have arrived at something we can change that we're confident will
eliminate the problem(s) we're investigating.

Obviously, these are ""principles of practice"" not theoretical absolutes.
Perhaps they apply, in some form, to SD modeling as well(?)

[Parenthetically, I feel obligated to say that the one thing that makes me
most uncomfortable about the Six Sigma mindset is the assumption that there
is one root cause, and that changing one thing will solve a problem (without
unintended side effects.) The good news is that the Six Sigma community is
rapidly discovering System Dynamics and there is a chance that feedback loop
thinking will prevail in the future.]

I can't help but be reminded of the charming story told about William James,
the philosopher and psychologist. He gave lectures on science to lay
groups. In some of them he talked about the force of gravity and how it
held the solar system together. After one such lecture, a very self-assured
woman came up to him and said, ""That was very interesting, Mr. James, but I
happen to know that the earth rests on the back of a giant tortoise.""

Since she spoke so seriously, James answered politely, ""But madam, upon what
does the giant tortoise rest?""

She just as confidently replied, ""Why, upon the back of another giant
tortoise.""

James began, ""But madam ..."" at which point she interrupted him with, ""Give
it up, Mr. James, it's tortoises all the way down!""

John Gunkler
Posted by ""John Gunkler"" <jgunkler@sprintmail.com>
posting date Sun, 16 Mar 2008 20:34:06 -0400
_______________________________________________

Posted by <George.McConnell@selex-comms.com>

Just to throw another source into the ring, you may be interested to read

http://www.systems-thinking.org/rca/rootca.htm

regards

George
Posted by George.McConnell@selex-comms.com
posting date Mon, 17 Mar 2008 14:37:49 +0000
_______________________________________________

Posted by ""nickols@att.net"" <nickols@att.net>

Scenario #2 at the link provided by George

http://www.systems-thinking.org/rca/rootca.htm

is indeed somewhat humorous - in an ironic sort of way - however, I'll
wager that aficionados of root cause analysis (RCA) would indicate that
the plant manager needed to go at least one or two steps further and
determine why he was pressing everyone to be so cost conscious. Was it
perhaps that his bonus hinged on cost savings (in which case he was shooting
himself in the foot) or was he simply responding to pressure from someone
else much as the others were responding to pressure originating with him.

--
Fred Nickols
Posted by ""nickols@att.net"" <nickols@att.net>
posting date Tue, 18 Mar 2008 15:00:57 +0000
_______________________________________________

Posted by Jack Harich <register@thwink.org>

SDMAIL John Gunkler wrote:
> Posted by ""John Gunkler"" <jgunkler@sprintmail.com>
>
> Root cause analysis is a foundation of the process improvement
> methodologies (such as Six Sigma) in business.
>
> I am not speaking authoritatively here, but it seems to me that what
> happens in real life is that we stop looking for a root cause when ...
> (1) We have found (at least) the fifth one [there's a method called
> the ""5 Why's"" that suggests you ask ""Why?"" at least five times,
> iteratively, before accepting the answer.]
> (2) We suspect that delving any deeper will not be productive; and
> (3) We have arrived at something we can change that we're confident
> will eliminate the problem(s) we're investigating.
>
> Obviously, these are ""principles of practice"" not theoretical
> absolutes. Perhaps they apply, in some form, to SD modeling as well(?)
>
Interesting how close these are to my earlier proposition:

""A root cause has three identifying characteristics:
(1) It is clearly a major cause of the symptoms
(2) It has no deeper cause.
(3) It can be resolved.
Sometimes it’s useful to include unchangeable root causes in your model
for greater understanding. These have only the first two characteristics.""

Point 3 is a perfect match. Your point two is an improvement on mine.
I've been troubled by the lack of cost benefit as you continue to look
deeper and broader for root causes. Changing mine to ""It has no
productive deeper cause"" would seem to fix this. Thanks!

Our versions of point one differ. Yours essentially says you have dug
deep and have what might be a root cause. Mine doesn't imply digging
deep at all, and merely says ""it"" is a major contributor in the causal
chain. My point two is the reason point one need not say how deep.

But I don't think we're there yet with a standard, applyable definition
of root cause for SD. This is because the field still clings to phrases
like ""dynamic hypothesis"" of what is causing the problem instead of root
cause and feels that if a model can reproduce the symptoms, then it must
contain the root cause.

I wonder if the preference for dynamic hypothesis over root cause
reflects the fact that SD is used primarily for business system
optimization. Episodic problems trigger an SD analysis. While the
problem does have a root cause(s), decision makers prefer to see the
broad behavior of the business modeled, so they can evaluate a broad set
of scenarios. This mindset would lead to preference for no particular
root cause, but rather a general feeling for the many causes that lead
to many behaviors.

> [Parenthetically, I feel obligated to say that the one thing that
> makes me most uncomfortable about the Six Sigma mindset is the
> assumption that there is one root cause, and that changing one thing
> will solve a problem (without unintended side effects.) The good news
> is that the Six Sigma community is rapidly discovering System Dynamics
> and there is a chance that feedback loop thinking will prevail in the
> future.]
>
Hmmm, I don't see Six Sigma assuming one root cause. Maybe a simple
introduction made it seem that way.

For example, a fishbone diagram shows many causes. See
http://en.wikipedia.org/wiki/Ishikawa_diagram

The Six Sigma Handbook, by Pyzdek, 2003, page 63 says ""These results
are, in a sense, 'effects' caused by things taking place in the process.
.. At some level we reach a 'root cause' or most basic reason behind an
effect. Black and Green Belts learn numerous tools and techniques to
help them identify these root causes. In Six Sigma work, results are
known as Ys and root causes are known as Xs. ... Y = f(X1, X2)"" Note the
plural in the second and third use of the term ""root cause"" and that Y
can have multiple root causes, in the form of X1, X2, X3, etc.

BTW, nice story about the chain of tortoises.

Owen Ambur wrote:
> Jack, you may also wish to check out Dietrich Dorner's book entitled
> ""The Logic of Failure."" He says we ""court disaster in predictable
> ways."" My paper on his book is available at
> http://mysite.verizon.net/ambur/failure.htm
Thanks. I read it in October 2001. Fantastic read. A super sleuth. This
book was one of the reasons I developed an interest in being able to
model problems.

I found the list of decision maker bad habits on page 18 to be very
educational:

- Acted without prior analysis of the situation
- Failed to anticipate the side effects and long term repercussions
- Assumed that the absence of immediately obvious negative effects meant
that correct measures had been taken
- Let overinvolvement in ""projects"" blind them to emerging needs and
changes in the situation
- Were prone to cynical reactions

This applies to so many difficult dynamic problems.
> Posted by George.McConnell@selex-comms.com
>
> Just to throw another source into the ring, you may be interested to read
> http://www.systems-thinking.org/rca/rootca.htm
>
> regards - George

A good introductory read. I liked ""Research has repeatedly proven that
unwanted situations within organizations are about 95% related to
process problems and only 5% related to personnel problems.""

I wonder if a thousand years from now, historians will write ""Research
has repeatedly proven that unwanted situations within problem solving
paradigms are about 95% related to process problems and only 5% related
to personnel problems.""

""The Plant Manger was horrified when he realized that he was the reason
there was oil on the plant floor. Bingo!"" - Nice to see twists like
this, to make the point and delight the reader.

""Once the root cause is determined then it has to be determined whether
it costs more to remove the root cause or simply continue to treat the
symptoms."" - This deals with the cost benefit trade off on resolving
different underlying causes. The piece is a little off, because there is
more to choose from than treating the symptoms and removing the root
cause. There are all the intermediate causes between those two ends of
the causal chain.

""Seeking the 'Root Cause' is an endless exercise because no matter how
deep you go there's always at least one more cause you can look for."" -
This would depend on how you have defined root cause. By including ""(3)
It can be resolved"" in my definition this trap can be avoided. You stop
when you approach causes like water freezes at 0 degrees Celsius because
that cannot be resolved. Models are full of causal chain ends that are
natural constants and are unchangeable.

Clicking on the link to http://www.bill-wilson.net/root-cause-analysis,
what do we find about root cause analysis? ""It can be employed in almost
any situation where there is a gap between actual and desired
performance."" Isn't this pretty much any problem that system dynamics is
applied to?

Thanks, George
Posted by Jack Harich <register@thwink.org>
posting date Tue, 18 Mar 2008 20:07:59 -0400
_______________________________________________