Making Systems Visible: New ways to present SD/ST models

[Jack Harich]

I started to read your paper ‘The need for a standard high yield …’.
At the beginning I stumbled on the phrase: ‘Even with easy to use software like Vensim and I Think’!
I have used Vensim now for 8 years, and I still find it very difficult.

Thanks. I was curious. Is it Vensim you find difficult or is it modeling?

Jack

[Jean-Jacques Lauble]

Hi Jack
I read again the mail I posted on Tuesday, and I must acknowledge that I was a bit rude and I apologize.
The reason is that we probably are not working on the same subjects. Mine are pretty peculiar and down to earth and yours are
more wide ranging.I feel that the field should make some efforts too, to solve more down to earth problems.
About your question on Vensim and modelling?
Vensim has a lot of features and becoming expert at using them fluently takes a lot of time. But the question is too related with the modelling question, because both are closely related.
The first thing to ask is: what is modelling?
I am sure that the definition may vary greatly, even if it seems straightforward.
For me, modelling is building a model, and using it with profit.
For me a model that is not used or that has generated no values using it is just bad.
From a consultant point of view, modelling may signify listening to the client, understanding what he wants, and build a model.
The rest will be the client’s business. I have not this conception of modelling, because I do not sell SD, I use it or try to use it.
Then if you consider the consultant’s view, I think that modelling is easy, because he only has to listen to the client’s view of the problem and translate this into a model. The model’s specifications are dictated by the client’s view, good or bad.
But unfortunately, the difficulties lie in the specifications. It is how well the specifications are chosen that determine the final utility of the model. Modelling alone is not especially difficult, provided that you have the technique and the time necessary.
Defining the specifications involve listening to the client but not necessarily following his specifications, taking into account the capacity of the client and the time he can devote to understanding and practicing using the model, taking into account the amount of work necessary to collect the necessary data and most of all taking into account the client difficulties to apply the eventual policies. This makes defining good specifications much more difficult than just transcribing into a model the client’s problem understanding.
I think that the SD’s current modelling conception is centred on what I called the consultant’s view, building a model without being enough concerned about how it will be used. Building a model without thinking deeply about the specifications, is not difficult and cheap to build and sell, and unfortunately is bound to generate little added value. So about your question, modelling with well defined specifications is not difficult. Modelling when one has to define the specifications that will permit to build a model generating value for the client is very difficult.
I think that once this has been written, the specifications must too take into considerations the capabilities of the software. And from that point of view, using these capabilities to generate some value to the client is not easy.
I hope I have been clear enough.
To resume both are difficult.
Best regards.
Jean-Jacques Laublé

[Les Ormonde]

Jean-Jacques,

I couldn't let your last post go unremarked:

I am afraid that your perception of the consultant's job

Then if you consider the consultant’s view, I think that modelling is easy, because he only has to listen to the client’s view of the problem and translate this into a model.

is somewhat flawed to say the least.

To get under the skin of what is being said in order to create a representation of what is actually happening whilst dealing with mis-perceptions, competing agendas, change resistance etc is not in any sense 'easy'. This is especially true when you are working in an organisation where you don't have the benefit of several years membership and an instinctive understanding of the prevailing shared mental models.

In my experience, client's don't buy models of what they have said, they buy diagnosis of a situation. If a consultant does not create tangible value in providing that diagnosis, then he or she will soon run out of work.

Also taking your point

The model’s specifications are dictated by the client’s view, good or bad.

If a consultant is to deliver value, he has to make sure that he is starting on firm foundations which may well mean having to tell the person that is paying them, they have got it wrong and negotiating a change in approach. Again, this is not a straightforward course to navigate.

The graveyards are filled with people who once thought that consulting was an easy option (but learned through experience that it wasn't).

I would be interested to understand how your perception of consulting was formed but that is perhaps not for this forum.
L.O.

[Jean-Jacques Lauble]

Hi les
I should not have used the word consultant.
In fact anybody building a model whose goal is to solve a real problem acts as a consultant.
This means nearly all models excepted for those that are research oriented.
My perception of what I have said does not come from any consultant job but by the study of all the models
in text books, conference papers, review articles that are too much concentrated on the model alone and not enough on
the added value it can generate. My remark is too related to the idea that there should be a ‘standard high yield process for solving difficult social problems’ that would permit to deliver approximately the same solution to a problem whoever the people modeling it.
I do not agree either with this idea because different people will generate different specifications that can deliver added values even if they are different. These different views may be complementary too. I said too that I noticed in a lot of models, poor practice even at the stage of pure modeling that did not even respect basic academic precepts. I noticed too that the client is very rarely represented as in this forum
where people are more or less SD sellers or more exactly having a consequent part of their revenue related to the SD field.
This introduces a sensible bias to the discussions.
As to my remark I often exaggerate the point, to trigger reactions.
If you do respect the way you describe your work, then you are among the people who use SD properly.
Regards.
Jean-Jacques Laublé

[Kim Warren]

Nice paper Jack - it looks like the key process steps you suggest are:

1. Problem Definition – Identify the problem [I assume this includes drawing the reference-mode of behaviour-over-time that describes the issue]
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.

... and step 2 consists of sub-steps:

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.

... all of which promise to be amenable to empirical confirmation. But is this process not rather close to what folk already do - albeit with step 2.A. relying on management opinion from the 'mental database' and team-debate ?
I would only note that not everything in life is a feedback loop, so do we risk people going "loop-hunting" rather than rigorously diagnosing what is happening and why? If so, step 2.A. could be modified to "Find and confirm the causal relationships between factors giving rise to the reference-mode behaviour, using empirical evidence wherever possible for that confirmation and seeking indirect supporting evidence when such data is not available." ... which causal explanation may well include feedback mechanisms.
I am a bit nervous about this discussion, though - surely the top professionals in our field already cracked this long ago, and I don't want to undermine established use of solid procedures that wiser and more experienced folk than me proved to be rigorous and reliable long ago. Also not to lose sight of the original question, which was about finding better ways to present SD findings.

[Jack Harich]

Thanks Kim,

But is this process not rather close to what folk already do - albeit with step 2.A. relying on management opinion from the 'mental database' and team-debate ?

A thoughtful question, but no.

Step 2A, “Find the feedback loops that are currently dominant,” is usually done reasonably well. LTG’s World3 is a fine example of that. But it did not include step 2B, which may explain why it mainly served only to identify the sustainability problem.

Where analysts usually go astray is step 2B, “Find the root cause of why they are dominant.” The pattern is they stop at the intermediate causes of step 2A and try to resolve those. That’s why in Change Resistance as the Crux I took the trouble to present a tight definition of what a root cause is (p58):

1. It is clearly a (or the) major cause of the symptoms.
2. It has no worthwhile deeper cause. This allows you to stop asking why at some appropriate point in root cause analysis. Otherwise you may find your-self digging to the other side of the planet.
3. It can be resolved. Sometimes it’s useful to emphasize unchangeable root causes in your model for greater understanding and to avoid trying to resolve them without realizing it. These have only the first two characteristics.

The paper quotes one of the most flagrant cases of confusing root causes with intermediate causes I’ve ever seen. In one paragraph, a world expert opines on not one but five “root” causes: (p57)

Popular consensus sees things like the IPAT factors, the human system’s growth loops, economic inequality and poverty, and lack of cooperation and other maladapted values as the root causes of the environmental sustainability problem, when in fact they are intermediate causes. These are also known as proximate causes or apparent causes, where the “apparent cause is usually a coincident occurrence, that, like the trouble symptom itself, is being produced by the feedback loop dynamics of a larger system” (Forrester, 1971, p. 95).

A broad and revealing example of this consensus comes from James Gustave Speth (cofounder of the Natural Resources Defense Council, founder of the World Resources Institute, and administrator of the United Nations Development Programme for six years), who wrote that (Speth, 1992, italics and comments added):

The [five] transitions I will mention briefl y seek to deal with the root causes of environmental problems. . . . The fi rst transition . . . is the need for a demographic transition to population stability [the P in the IPAT equation] . . . The second transition is . . . a transition in technology to a new generation of environmentally benign technologies [the T in the IPAT equation] . . . The third needed transition is an economic transition to a world in which prices refl ect the full environmental costs [a balancing loop to put the brakes on the reinforcing growth loops of the IPAT factors, mostly the A and T, by internalizing externalized costs] . . . The fourth transition is a transition in social equity to a fair sharing of economic and environmental benefits both within and among countries. Over much of the world, the greatest destroyer of the environment is poverty—because the poor have no alternative. . . . None of these transitions is possible without a fifth—an institutional transition to different arrangements among governments, businesses, and peoples. These institutional arrangements are urgently needed to enlist the tremendous potential of the private sector in what must be an unprecedented cooperative effort . . .

These are pseudo root causes, however. Why is it so hard to quickly put the brakes on global population growth by, for example, changing to a worldwide one-child-per family policy for several generations? Why are technologies increasingly harmful to the environment? Why is the system so biased towards externalizing costs? Why isn’t the industrialized world already taking care of those less well off? Why aren’t governments, businesses, and peoples already cooperating? Questions like these demonstrate these are in fact intermediate causes. They are mere starting points for deeper analysis.

That should prove how common it is to not perform step 2B properly. Once that occurs, the remaining steps in 2 become impossible. This leads to poor solution convergence (step 3) and implementation failure (step 4). Step 2B, find the root causes, is where the entire problem solving effort either works or goes astray. Once the true root causes are found, everything else is relatively easy.

Now then, about your suggestion:

I would only note that not everything in life is a feedback loop, so do we risk people going "loop-hunting" rather than rigorously diagnosing what is happening and why?

This is a really good suggestion. For awhile I tried “forces” instead of “feedback loops” in the process definition. But I reverted to “feedback loops” for a reason. “Forces” are pretty vague. That will lead to poor process execution. Furthermore, I tend to agree with “if you don’t understand a social system’s feedback loops, then you don’t understand the system.” and of course “Positive feedback loops are the most powerful processes in the universe.” (Both from Sterman, I believe) So I put “feedback loops” back into the process definition.

But maybe it can be improved. You suggest:

...step 2.A. could be modified to "Find and confirm the causal relationships between factors giving rise to the reference-mode behaviour, using empirical evidence wherever possible for that confirmation and seeking indirect supporting evidence when such data is not available." ... which causal explanation may well include feedback mechanisms.

It could. But this is a little long and is best left in explanatory supporting text. It’s a great elaboration.

I’ve taken great care to use short, memorable sentences to define the System Improvement Process steps in a nutshell. A huge barrier to formal process use is getting it to click in newcomer’s minds. The simpler the better.

I hope the steps have clicked for you and help in some way.

I am a bit nervous about this discussion, though - surely the top professionals in our field already cracked this long ago, and I don't want to undermine established use of solid procedures that wiser and more experienced folk than me proved to be rigorous and reliable long ago.

You are one of the top professionals!

Putting humor aside, if the problem of an immature process was cracked long ago, then there would be no need to ask: “Why is there so little impact of system dynamics in the most important social questions?”

Regarding your:

Also not to lose sight of the original question, which was about finding better ways to present SD findings.

I can think of no better way to present the most important findings than something like this:



Thanks once again for a thoughtful meeting of the minds,

Jack

[Eric Stiens]

Two suggestions:

Perhaps the question shouldn't be, "how do we make complex models easier to present to people?" but rather, "how do we engage more people in the modeling process?". One suggests a more technocratic-vision of building models, producing knowledge, and getting that knowledge in the hands of change makers, who then make the change; the other suggests a vision where the process of understanding a problem and the process of creating change are more intimately tied together and more horizontal in their power arrangement.

That being a bit too idealistic, in the practical world of presenting models, I think that it is largely a problem of having our tools be modeling tools first and foremost and presentation tools only as an afterthought. This may well be a residual effect of having SD dominated by engineering types who tend to, rightfully so, be more concerned with function over form. I would say that modeling powerpoint slides is the wrong way to go in this direction -- however, thinking about design and bringing graphic designers on board and perhaps even building much more specialized "presentation" functionality into software would be a great start. Stella seems to be making some strides in this direction, especially with their tools for web presentations, Vensim not so much.

I agree that the ability to collapse and expand -- or zoom in and out -- of different parts of CLDs would be a huge help, as would the ability to "pull" certain causal loops out of the structure to highlight them, then 'drop' them back into place. I have had some luck doing this manually with "mind mapping" software as well, though it is time consuming

In the meantime, even simple things like making sure one is telling the story while moving back and forth between the structure and behavior. I can't count the number of presentations I have seen - and I haven't even seen that many - where a giant lump of structure was presented, then different scenario test runs were presented without ever showing the specific feedback structures producing the results.

I think all of Kim Warren's points are well taken -- however in very practical terms, I think having more people focused on aesthetics, data visualization, and presentation capabilities involved in developing modeling software would likely lead to some huge strides in this area.

[Linda Sweeney]

This is interesting as to make a model as effective as possible, it is necessary to deal with the presentational aspects which are easy to downplay or which get lost in the excitement of having got the model just right. IThink's story telling mode can help cut through the apparent confusion of a raw model and helps focus on salient points.

L.O.

Thanks Les. I will go back to IThink and check this out.

Linda

[Linda Sweeney]

Hello all,

Thank you all for your many helpful responses to my query about ways to make complex systems visible.

I do think a clarification on my end is in order. In much of my current work, I use ST/SD methods to help organizations TELL THEIR STORY from a systems perspective.

For instance, I'm working now with a childhood obesity research team. Our primary goal is to enable research staff members to move beyond bullet points, so that the story they tell (to fellow researchers, stakeholders, potential funders, the general public) more closely matches the interdependent, dynamic, complex reality of, in this case, a 10-year, community-based participatory research (CBPR) effort focused on childhood obesity. It is complicated, yes, but a terrific opportunity to combine complex systems theory + systems mapping + story telling.

I will be happy to share whatever I can as result of this work, most likely in late June.

My best to all,
Linda
Posted 1 hour ago | Delete comment

[Thomas Fiddaman]

Jack, I like your prescriptions. But reading your table, I notice that all 3 solution sets are not ready for implementation. That would seem to suggest yet another layer of meta-root causes (hopefully it doesn't imply that our messes are irresolvable). But moving farther toward top-level paradigms or evolutionary causes means that we move further from the concrete issue to be addressed (oil resources or ocean acidification or whatnot) and admits ever more competing hypotheses. How do we operate at all levels at once?