REPLY The Death of System Dynamics? (SD6222)

[System Dynamics Mailing List]

Posted by  matzaball50 at aol.com

 Hi Folks, 
    >Posted by George A Simpson <gsimpso4 at csc.com>
>>My experience supports the points made by Wade Schuette.
>>I get tremendous buy-in from people who have participated in the 
>>development of models, but find difficulty explaining polished models even 
>>to key stakeholders.

I believe George has stated the problem folks have with "accepting" SD models. To put it another way, 
a "finished" model (Is any model ever really "finished"?) is _A_ perception, or a collection of
perceptions(and not the only viable one)of the problem and its various components and interactions 
as held and understood in the minds of the folks who actually developed the model.

Others may not perceive the problem in the same way or with the "same" components and interactions. 
The only answer to this is to involve _ALL_ the people who not only need to develop the model but who 
also might need to use it. Yes, this can become quite cumbersome at times but I don't think that is 
the major stumbling block. I think one _BIG_ issue with models in general is that modeling is done for 
a specific purpose and I believe a a few of the major "purposes" of building models is to try and 
influence others. That is, to sell an idea, or project, or to defend a decision. Another big reason is 
to try and understand the "changes" that might be necessary in structure for an organization to become 
more efficient or profitable and herein lies the big issue. NONE of the above is conducive to be all 
inclusive. If your looking to "influence" people it would certainly be useful to know _HOW_ you might 
be able to influence them, but in including them in the "modeling process" you would have to reveal 
your hand to them as well. The same holds for organizational changes that might be necessary.

I don't think anyone is going to step up and say;"yes my job is superfluous and should be eliminated".

Having a modeler "interpret" a problem DIRECTLY from an individual or a group of individuals and 
developing a useful model for those directly involved is tough and demanding as it is, but when one 
has to not only interpret but "imagine" what someone else MIGHT think or perceive, by modeling what 
you just think others might be perceiving, the task becomes near impossible to do well.

Besides being inclusive and making sure your client understands the limitations inherent in being 
non-inclusive there is not much else you can do.

Model building is supposed to help people understand and solve problems. If you can't do that with a model, 
why bother with it in the first place? 

>Posted by  "John Gunkler" <jgunkler at sprintmail.com>
In reading this post after I just read George's, I think this one puts a nice cap on my thoughts. 

>>... This allows you to show a model one small piece
>>at a time and build its logic in front of the audience.  I find I must take
>>the time to generate discussion about this logic and make sure everyone is
>>on board with each piece before moving on to the next -- or, at least take
>>the time to become aware of any skepticism about any part of the logic so
>>that it can be returned to later and resolved.

John, I think this is probably the key in getting the necessary "buy-in" we all seek.
Of course you can only do this with the folks who have been directly involved in your
effort.

>>"Story telling" not only isolates a sub-model from the rest of the model
>>(which is easy to do in other ways), but it also allows you to show stocks
>>and flows one at a time, in an order you choose, to (for example) build up a
>>single causal loop and then show how it connects to other parts of the
>>model.

I think this brings up another issue that involves "but-in" and that is; 
exactly what are you asking the client(S) to "buy" into? A solution or a method? 
I'm not so sure you need to explain the method (SD) in order to "sell" a solution.

Again, folks want answers to their questions and not much else, and I think too often we tend to drift off
into details about modeling methods that the clients could caress about. If a client walks away muttering 
about having to deal with "rocket scientists" you know you have crossed the line.

I think most people want to know what kinds and types of solutions you can come up with and what are the GENERAL 
kinds of methods that are involved with. I talk about the kinds and types of "data" that is needed and the kinds and 
types of "answers" they might expect. I don't go into the details of the SD methodology because I'm not selling 
the SD methodology. I'm selling my expertise in hopefully helping my clients resolve some issues. In fact, I 
limit my "technical" discussions to generalities involved in computer simulation and that I would be happy 
to go into the details involved, _AFTER_ the project is over. I limit my discussion to answering any questions 
they might have about the VALIDITY of the ENTIRE process and, as I said in my previous post, to the importance 
of the inclusion of all the folks involved in the entire process.

I think your "story telling" is an excellent way of "building" loops and getting the necessary buy-in. But 
I also think it important that we keep our minds open for new ways to effectively communicate our ideas to 
others. The point here is that there is never only one best way. The key of course is tailoring your discussion 
to your audience and THEIR needs.

>>A related method is to aggregate ("black box") major sections of the model
>>in your early discussions.  Even if the people you're working with have had
>>a hand in building the model, I find this is useful (to them and to me!)  I
>>let the audience's curiosity lead me to the decision to open a black box or
>>not later on.  If the audience trusts the black box, there's no immediate
>>need to explain why it works.  I combine black boxes with story telling when
>>the model is complex enough to warrant this.

Yes, this is another way of handling the issue of dealing with "method" vs. "solutions" issue.

>Of course, I'm talking about very specific contexts here -- where your aim
>>is to get high-level understanding and generate enthusiasm for appropriate
>>policy changes (directionally).

Yes, and those "policy changes" will be near impossible to pull off _IF_ the folks who are 
involved in the actual changes are _NOT_ involved in the modeling that helped determine those
very changes

Regards,

Marc 
Posted by  matzaball50 at aol.com
posting date  Thu, 01 Feb 2007 13:07:56 -0500