Communicating SD Models to Senior Leaders

[rglitz@angrc.ang.af.mil]

Greetings,

I have a couple questions concerning the "selling" (communicating) of SD
models outside the group that created them.

We had a nice, cross-functional team of people work with a talented
contractor to build a model with accompanying Management Flight Simulators
(MFS) in the ithink(tm) product. The team is very enthusiastic about the
work. Now we (I actually) have to arrange for the introduction of this work
to our topmost level of leadership. My problem is that the leadership that
chartered this work sort of got "blown away" in a recent and continuing
reorganization.

I guess Im looking for a protocol for presenting this kind of work to senior
people who are coming into the field "cold." I can never have them for
enough time to give them an academic training session in SD, modeling, and
systems simulation. We have discussed various ways of going about it: MFS
first to pique interest, followed by stock/flow model, followed by Causal
Loop diagrams... or, start with the causal loop diagram first, followed by
model, followed by MFS. Any ideas....???

Note: Well be presenting in a group decision support/Electronic Meeting
System environment so that each can work the MFS independently and so that we
can dredge opinions/feedback online.

Second thought: Supposing that we can indeed teach systems thinking to our
leadership and incorporate SD models into the decision making process, how do
they explain/justify their decisions to their constituencies?? For example,
how does my general go before a congressional committee or a group of
governorss staffs and present a force structure reduction strategy based on
SD models without attempting to teach Causal loops, stock/flow, MFSs, etc.?
As Dr. Forrester said in a recent post, (Im paraphrasing)... actions that
are beneficial over the whole system and the long term almost always seem
harmful or counterintuitive in the short term. If thats true, Im asking my
leadership to really "stick it out" for severe criticism in order to do the
right thing.

Any experiences that anyone can share will be appreciated. Note: Ive
already ordered the audio tapes from Pegasus Pubs. Inc. on this subject, but
they havent arrived yet.

Thanks in advance

LtCol Robert Glitz
National Guard Bureau
Pentagon, VA
301.981.8694
r=glitz@angrc.ang.af.mil

[JT55@delphi.com]

As I understand it, Robert Glitz asked for some thoughts on preparing a
leadership/
sponsoring group for a team presentation of results from analysis based in
system dynamics. He also asked for some thoughts on how to communicate
conclusions and decisions that resulted from such thinking to a group of people
removed from their decision-making process. The project comprised a difficult
dynamic issue, a cross-functional team application of system dynamics
methodology including a helpful simulation model to crack the nut and a
management flight simulator to help the project team use the model to increase
understanding of cause and effect. He indicates that the project sponsors are
not likely to have a system dynamics background and are unlikely to want a lot
of training. The team is enthusiastic about the methods employed to obtain
their conclusions and recommendations.

Under those conditions, it may be best to focus on the conclusions and
recommendations first. If the project team feels that the outcome of their
work is good, it is less important how the team got there. Said differently,
what the team learned about methodology is less important than the quality of
their thinking and conclusions. The causal loop diagrams, the stock-and-flow
diagrams, the feedback model, and the mfs were tools used to help thinking.
But the tools didnt do the thinking; the tools boosted the output of the team
-- what Jim Hines calls computer-aided reflection. The outcome of the thinking
process is a logical argument. The most compelling presentations might be a
reasonable argument seasoned with a little friendly data (reference modes) and
anecdotes (observations from system participants).

If there is a surprise involved -- counterintuitive outcome -- the model is
invaluable in helping to sharpen the teams presentation. The model is the
tool used for tracing the causes. But once the cause of the counterintuitive
result is spotted in the model, it may be best to set the model aside and make
sure that the causes in the model are causes in the real world. The model then
highlighted the causes for the team. But the team validated their new insight
by believing it to be true in the real world. So, they may be better off
leaving the model out of the conversation.

And, if the team follows this path, the leaders will be armed with a logical
argument to take to their constituents.

There may be a portion of the leaders/sponsors who are interested in the
project team dynamics and tools employed. From my experience, weaving that
session with results delivery can get very complicated. A quick overview
(measured in hours) of the basics of system dynamics would be in order but
separate from the more serious work.

LtCol Glitz also indicates that the group used IThink for its project work.
They may want to consider using Vensim as their system dynamics environment.
Vensim speeds up the analysis of model outcomes in a number of ways. One tool
in Vensim is its powerful Causal Tracing that allows the user to quickly
document and navigate causal loops. I have version 3.0.x of IThink and it
does not offer that tool.

I look forward to reading other responses to LtCol Glitzs inquiry.

Jim Thompson
Gemini Consulting, Inc.
203/676-8152
jt55@delphi.com