Scriptapedia: A Handbook of Scripts for Developing Structured
Group Model Building Sessions’
Peter S. Hovmand, PhD
Washington University in St. Louis
phovmand@wustl.edu
George P Richardson, PhD
University at Albany
gpr@albany.edu
Etiénne Rouwette, PhD
Radboud University Nijmegen
E.Rouwette@fm.ru.nl
David F. Andersen, PhD
University at Albany
david.andersen@albany.edu
Annaliese Calhoun, MSW
Washington University in St. Louis
ACalhoun@wustl.edu
Krista Rux, MSW
Washington University in St. Louis
krux@ edu
Timothy Hower, MS
Washington University in St. Louis
thower@wustl.edu
Abstract
This paper describes a handbook of scripts—Scriptapedia—for developing
structured group model building sessions. Andersen and Richardson (1997) have
identified the importance of standardized protocols or “scripts” in group model
building (GMB). GMB scripts have historically existed as undocumented
structured small group exercises. Scriptapedia represents an effort to improve the
practice of GMB as well the research into GMB effectiveness. We describe
elements of scripts, case applications of Scriptapedia, and discuss uses, misuses,
and misunderstandings of scripts. The handbook is included as an appendix to the
paper.
Keywords: group model building, scripts
1. Introduction
Over the past fifteen years, since the development of icon-oriented software such as i-Think,
Vensim, and Powersim, Group Model Building (GMB) has emerged as one of several ways to
construct policy-oriented system dynamics models working directly with client groups. We
think of group model building as a form of group decision support that involves a group of
' This work was partially supported by the Centers for Disease Control and Prevention through the Brown School
Violence and Injury Prevention Center (1R49CE001510). Projects using Scriptapedia were supported by National
Institutes of Health, Office of Behavioral and Social Science Research (HHSN 276200900017C) as part of the
Comparative Modeling (CompMod) Network for childhood obesity; Foundation for Ecological Security (FES) in
India; St. Louis Federal Reserve Bank, and the Social System Design Lab at the Brown School of Social Work,
Washington University in St. Louis.
Scriptapedia 2
stakeholders working with a modeling team to solve a focused problem within a complex
system. The classic components of group model building include key aspects of the model-
building and refinement process in public view of the client group, developing and testing
scenarios and strategic options with the client group, and facilitated discussion and analysis of
results emanating from the system dynamics model. These group processes make extensive use
of facilitation discussions and analysis with a diversified team of group facilitators and modelers
typically present in the room.
Attempts to carefully define how to work with groups as part of the model building process have
been a key component of the overall GMB effort for a long time. Stenberg (1980) described
approaches for working with policy reference groups before GMB came to be defined as a
formal activity and Roberts (1977) stressed the importance of interactions with client teams as a
means to achieving effective implementation of model results. Richmond (1997) has described a
Strategic Forum as a kind of small group whose purpose is to define and analyze a dynamic and
complex problem around a formal system dynamics modeling effort. Vennix (1996) presented a
classic statement of the Group Model Building method for system dynamics models. Soon
thereafter a special issue of the System Dynamics Review edited by Vennix et al. (1997) gave an
overview of the then state-of-the art of GMB. Eden and Ackermann (1998) have described
formal procedures for using software tools such as Decision Explorer and Group Explorer to
structure group processes around formal model-building activities and Howick et al. (2006) have
documented procedures and scripts for formally integrating strategic scenarios into system
dynamics models while working in formal GMB sessions with client groups. More recently,
Andersen et al. (2007) presented a more comprehensive review of current research in GMB
using system dynamics.
1.1. Themes in GMB
A number of consistent themes have characterized recent work on GMB. Several of these themes
are described in more detail below:
Teamwork in GMB. Richardson and Andersen (1995) first defined their approach to using
teams to support GMB. That early work concentrated on more clearly defining the various
roles that must interact to create a smoothly functioning group modeling team. Five distinct
roles (not necessarily connected to five distinct persons in the room) include (1) the facilitator/
elicitor who leads the group discussion and keeps a constant eye on the group process in the
room, (2) the modeler/ reflector, the person or team in the room constantly paying attention to
how the formal simulation model is emerging from the group discussion, often providing critical
model-based comments and insights to the client group, (3) a process coach who is responsible
for the creation of the overall script for the day and for designing changes to this script “on the
fly” (often the role of the process coach is mostly performed before the GMB session begins and
then handled by a person in one of the other roles during the meeting), (4) the recorder who
makes a real time record of all the discussions and decisions being made by the group, and (5)
the gatekeeper, a member of the client team who serves as a bridge between the modeling team
and the client team, often serving as a voice and support for the meeting owner, the primary
sponsor of the overall activity within the client group.
Scriptapedia 3
Scripts as a Basic Unit of Behavior for Designing GMB interventions. A second theme,
basing GMB practice on pre-defined sets of scripted behavior, was first described by Andersen
and Richardson (1997). The basic idea motivating scripts as an organizing framework for GMB
activities was a need to be organized about interactions with a client team to make best use of
group time and to assure that the overall process moved forward in an organized fashion,
ultimately culminating in useful products and insights for the client team. The group agenda for
the full duration of the planned meetings was to be divided into small segments of ten or fifteen
minutes each with detailed plans for what the group would be doing within each such scripted
time block. Typically the meeting would start with open-ended, problem-finding activities such
as stakeholder mapping or group articulation of their “hopes and fears” for the overall project, or
the formal introduction of simulation tools via the use of small “concept models”
(Ghaffarzadegen, Lyneis, and Richardson 2011; Richardson 2006).
Subsequent scripted activities included exercises designed to draw out reference modes by
drawing graphs of variables over time or various approaches to eliciting system structure from
the client group. Scripts for a second or third meeting of the group would include ways to
review progress made at previous meetings as well as scripts designed to facilitate the client
group’s experimentation with a formal simulation model to discover policy conclusions
constrained within the model’s structure. Zagonel (Zagonel and Rohrbaugh 2008; Zagonel et al.
2004) provided a detailed analysis of the genesis and practice of GMB activities within this
school of work and Luna-Reyes et al. (2006) published a soup-to nuts description of how
teamwork and scripted facilitation actually played out in a specific intervention focused on
providing homeless shelters in New York State.
While the idea of using a script as a basic behavioral unit constituting GMB interventions had
strong intuitive appeal, this same idea left open a number of conceptual and practical issues (that
this current work on the Scriptapedia is designed to help remedy). Similar efforts, such as the
work by Vreede, Briggs, and Kolfschoten (2006) to define “thinklets” as a basic unit of behavior
of facilitated group meetings, defined a different boundary for the basic unit, for example paying
more detailed attention to specific and contingent behaviors by the facilitator under different
kinds of group response. Should scripts include only behaviors in public view of the group or
should they also include activities undertaken by the modeling team more in private? Should
scripts be thought of as best practices with prescriptive power or more as descriptions of
behavior waiting to be improved upon by subsequent practice? These and other questions are
gaining greater precision in this project aimed at defining an online catalogue of scripts.
“ScriptsMap” as a Tool for Sequencing Individual Scripts into a GMB Plan. Another
question left open by defining scripts as a basic unit of analysis is the many relationships
between a single script and a whole intervention. Should some scripts be done first, while others
wait until later? Are some scripts properly seen as prerequisites for others? In general, what
guidance, if any, exists for practitioners who wish to assemble a series of scripts into a whole
intervention plan that makes sense. Ackermann et al. (2010) proposed a “Scripts Map” as a tool
for addressing just these questions. As a basic definition they proposed that “the ScriptsMap
itself is a framework for effectively combining particular sequences of scripted activities,
products, and deliverables into a formal network to enable facilitators to construct appropriate
combinations for workshops.” Their initial work laid out a map that combines scripts from
traditional GMB practice with Eden and Ackermann’s (1998) approach to strategy development
Scriptapedia 4
working directly with client groups. Eden et al. (2009) further elaborated on a number of
practical and more theoretical dilemmas associated with attempts to integrate group modeling
projects using diverse analytic methods while Andersen et al. (2006) proposed pedagogical
approaches to teaching such a blended approach to group-oriented problem solving.
Evaluation of GMB. In the last decade, evaluation of group model building has progressed
beyond the systematic review of case studies described by Rouwette, Vennix and Van Mullekom
(2002) in several ways. Rouwette et al. used the separation of context, mechanism and outcome
elements common to evaluation research for describing differences between case studies. The
first development in the last decade has been to group cases according to different contexts:
public policy (Cockerill et al. 2009), Enterprise Resource Planning implementation (Rouwette
and Vennix 2009), criminal justice (Rouwette 2011), environmental modeling (Beall and Ford
2010). The second development has been to use controlled settings to assess the impact of the
modeling process (Dwyer and Stave 2008; McCardle-Keurentjes et al. 2009; McCardle-
Keurentjes, Rouwette, and Vennix 2008; Hoppenbrouwers, Weigand, and Rouwette 2011).
Process Diagrams. An emerging theme is an attempt to visually represent the temporal sequence
of group model building sessions. For example, Zock (2004) uses Luhmann’s systemic theory of
social systems to develop a standard intervention architecture for system dynamics based
interventions. And, Straus (2002) uses process maps to design effective collaborations involving
multiple stakeholder groups that has been used in the design of GMB sessions.
1.2. Using Scripts to Improve Practice
Modeling sessions are shaped by the interaction between a group of participants and a facilitation
team. The facilitator has a crucial role in the interaction process, as he or she introduces key
steps in the process to participants, provides guidance with regard to methods and techniques,
summarizes intermediate results and proposes when to move on to another activity. This
dependence on the facilitator is recognized in group model building as well as other forms of
facilitated modeling (Franco and Montibeller 2010). A fundamental reason for introducing
scripts is the fact that much of facilitation remains an art rather than a science (Andersen,
Richardson, and Vennix 1997). Some practitioners go so far as to suggest that increased
transparency is one of the key challenges for the field of facilitated modeling (Eden and
Ackermann 2006; Westcombe, Franco, and Shaw 2006; Checkland 2006). Scripts are one
approach to elicit facilitator expertise and organize it into explicit and manageable chunks. These
explicit descriptions can then be communicated, discussed and reused. This allows us to
document and archive methods and techniques used by different facilitators and across different
modeling disciplines. We feel scripts have an advantage over existing modeling guidelines in
handbooks, which rarely discuss the practical choices a facilitator faces over the course of an
intervention and in a particular session. This is problematic as the ‘method in use’ can be very
different from the ‘espoused method’ which is featured in textbooks (Eden and Radford 1990).
Dependence on the facilitator combined with a lack of concrete guidelines for facilitation, make
life especially hard on novices that are trying to learn how to use group model building or other
facilitated modeling approaches. Documenting scripts may increase the spread of group model
building practice and its applicability for audiences that cannot enter into an apprenticeship with
an experience modeler. Keys (2006) looks into differences between novice and expert users of
Scriptapedia 5
facilitated modeling and the support needed to move from one stage to the other. A central
element of such support is identifying the core tasks that experts carry out in a problem
structuring exercise and codifying these in some way. Codifying experiences in the form of
scripts allows a greater spread of modeling practice and encourages its use in large impact
problems.
Finally, because scripts offer a standard approach to codifying experience, they allow us to
compare facilitator approaches and increase our knowledge on what works best in particular
circumstances. Scripts may be adapted to fit local circumstances and community contexts. As
scripts explicitly include inputs and outputs, they make it easier to identify how to move from
one phase in the session to the next. It becomes possible to design a session on the basis of a
string of scripts. An added advantage of the standard terminology in which scripts are captured,
is that non-experts such as the gatekeeper and other clients are in a better position to understand
what a session will look and feel like. This allows the facilitator to draw on the client’s expertise
in designing a session.
1.3. Learning and Reflection: Research into Modeling Effectiveness
In addition to practical advantages, explicitly capturing the modeling process in the form of
scripts also offers advantages to research as well. Franco and Rouwette (2011) note that although
the modeling session is central to facilitated modeling practice, as this is where the model is
constructed and the benefits of directly involving participants are most evident, there is
surprisingly little research on what actually happens in modeling sessions. Most research on
modeling effectiveness takes the form of single cases studies, but these typically do not penetrate
to the level of separate sessions. This is regrettable as small differences in the intervention
process may lead to large differences in outcomes (Jarboe 1996). Scripts offer a way to open up
the “black box” of modeling interventions, as they provide facilitators with a shared language to
describe the intervention process which is detailed enough to capture essentials. Before we can
explain differences in modeling effectiveness between cases we need to be able to adequately
describe the context and process of our real-world applications (Rouwette, Vennix, and Van
Mullekom 2002). In some cases a seemingly identical modeling process leads to different
outcomes. Only by describing the process in adequate detail can we rule out that a subtle
variation in the intervention caused the difference in outcomes. In doing so we increase our
knowledge on the fidelity and robustness of modeling methods and techniques: the degree to
which their effect is independent from contextual differences. A central tenet of science is the
ability to replicate results. In the case of a complicated intervention such as group model
building, any increase in insight as to which elements of the process are more and less important
for creating results, is welcome.
2. Scriptapedia
Scriptapedia originated as idea for documenting and sharing GMB scripts based on Andersen
and Richardson (1997). The original concept was for an online tool similar to Wikipedia and
other forms of digital commons with the functionality to develop and share GMB scripts in a
collaborative environment. After evaluating different approaches, an initial prototype for
Scriptapedia was developed based on Joomla, an open source content management system.
While the initial results were found to be promising, technical limitations in Joomla led us to
Scriptapedia 6
explore other platforms for Scriptapedia including Plone and Drupal. Again, each showed
promise in some areas, but required a more significant and sustained design and development
effort.
Meanwhile, the need to have a centralized collection of scripts led us to create a handbook that
would be maintained and published online. This approach offered a number of advantages in the
short to medium-term. First, the team felt that having Scriptapedia available as an online
resource as soon as possible was important to stimulate the distribution, sharing, and creation of
scripts. Second, it was already becoming evident from several projects that individuals new to
system dynamics and GMB could readily engage with and create scripts using the template
provided in Scriptapedia. Thus, we decided to pursue the creation of Scriptapedia as an online
handbook that could easily be updated and distributed as an intermediate solution to launching
Scriptapedia. In the following sections, we describe the script template, and provide an overview
of the organization of the handbook included as a supplement to this paper.
1.4. | Elements of Group Model Building Scripts
The cornerstone of standardizing and disseminating GMB practice is the script template.
Comprised of 19 separate fields, the script template creates a method for thinking about and
documenting the nuts and bolts of GMB (see Figure 1). The script template has gone through
multiple iterations to improve clarity and functionality. The goal was to create a template that
would be easy to understand and use across different cultures and levels of group model building
expertise.
Name of Script. The name of the script should clearly indicate the script’s content. Frequently
scripts are named after the output they produce or the type of activity they describe. For example,
the “Hopes and Fears” script outlines how to conduct the “hopes and fears” exercise. As the
number of scripts increases, proper naming will become more important.
Description. This field provides a brief synopsis of the activity and what the script is meant to
accomplish. It serves as an abstract for the script.
Script Status. Since script creation is often a collaborative and iterative process, this field
recognizes the different stages of script development as determined by the Scriptapedia editorial
board. Best Practice scripts have been used multiple times and in multiple settings and are
generally considered effective. Promising Practice scripts have been used in multiple settings,
but have not been replicated enough or found sufficient utility within the field to be considered
best practice scripts. Under Development scripts indicate initial ideas for a GMB activity or a
script that is currently being developed by the authors.
Context. The context field specifies where in the GMB process this particular script fits. Since
GMB projects are comprised of multiple scripts, the context explains whether the script should
be used at the very beginning, after a particular script, to wrap a project up, etc.
Scriptapedia 7
Figure 1 Script Template
Description | 1-2 sentence brief overview
Script Status | Choose one and delete the bullets below that do not apply:
+ Best practice: this script has been used many times and in different settings and has consistently produced the
intended outputs.
+ Promising practice: this script has been used a few times with good results, but needs additional refinement
and testing
+ Under development: this script still needs to be refined and tested
Context When should this script be used?
Purpose(s) _| Define the purpose of the script (delete those that do not apply):
+ Framing the problem
Initiating mapping
Eliciting variables
Deciding the reference modes for the study
Eliciting feedback loops
Eliciting stocks
Primary Identify the primary nature of the group task (delete the bullets below that do not apply, and note that a group task
nature of should only have one primary purpose):
group task + Divergent: activity designed to produced an array of different ideas and interpretations
+ Convergent: activity designed to clustering and categorizing ideas and interpretations.
+ Evaluative: activity designed to rank and choose between options and idea.
+ Presentation: activity designed to educate or update participants.
Time Preparation time:
Time required to complete steps in script:
Follow up time:
Materials List the materials needed to successfully complete the script (e.g. markers, overhead projector, flip chart):
needed to .
complete é
script
Inputs from _ | List the inputs from other scripts needed for this scrip (e.g. behavior over time graphs, concept model) or indicate
other scripts | “none” if this is a starter script:
Outputs List specific products such as behavior over time graphs and system, and how these products will be used in the
from this context of the whole project. Distinguish deliverables from products, where deliverables are physical outputs such
script as a electronic file or hardcopy of a system map, and products are interim outputs from a script that are of primary
interest to the modeler.
Team roles _| List the team roles and minimum level of expertise required to complete the script (e.g. Facilitator - expert in SD):
required and | +
expertise .
needed
Who is in List of people who should be in the room (@.g., “gatekeeper, ‘modeler’, “clients”) during the exercise:
the room? .
Steps List the detailed “how-to” sequence of actions in the script and who does them:
1.
2.
3
Evaluation _ | Describe the criteria for knowing whether or not the script is successful, that is, how would someone who had not
criteria seen this script used before know whether or not they did the script correctly?
Author(s) Identify the authors of the script. It is important to note that a script is a unit of behavior, and the documentation of
that behavior is separate. The author of the script is the person or collective that created the behavior, and this
should be acknowledged by identifying the individual or collective as the author. If the author of a script is not
known, simply write unknown’. For individuals or collectives with an email address, provide email contact
information. Also include the date (if known) that the script was created.
History & Describe the history and basis for creating this script including both the motivation (@.g., a specific need that arose
Basis for during a project) and prior work that the script is based (e.g., other scripts, journal articles, traditions within an
Script organization or community).
Revisions | Provide a list of revision changes and who made them. The description of the script itself should be the most
recent version of the script and reflect the best use of this activity.
References | List any publications or references to additional documentation using this script and cited in the history of the
script. For example, if this script is based on another script that was described in a journal, then mention this under
the “History” field with an author/year citation, and provide the full reference here in the references field.
Scriptapedia 8
Purpose. A script’s purpose distills its main goal into a few words. Multiple scripts may have the
same purpose, essentially describing different ways to accomplish or build towards the same
goal. The purpose frequently depends on the script’s context. A script may have more than one
purpose; however, if the script has too many purposes, this could be an indication that it needs to
be divided into separate scripts. Examples of possible script purposes are: framing the problem;
initiating mapping; eliciting variables; and, deciding the reference modes for the study.
Primary Nature of Group Task. This field comes from research on group tasks. Depending on
the context and purpose of a script, the modeling team will engage participants in a different type
of group task. Divergent activities produce an array of different ideas and interpretations (e.g.,
Behavior Over Time Graph Script). Convergent activities guide participants through clustering
and categorizing ideas and interpretations. In evaluative activities, participants rank and choose
between options and ideas. Lastly, there are times when the modeling team must explain system
dynamics concepts or update the group on products and deliverables; such activities fall into the
presentation category. Although a script may include different types of group tasks, it should be
defined as a small group exercise that has only one primary group task. A group exercise that has
a significant emphasis on both convergent and divergent activities, for example, is likely actually
involve two separate scripts, one that describes the convergent activity and another that describes
the divergent activity.
Time. This field describes how long the script should take to complete. The field is divided into
preparation time, execution time, and follow-up time.
Materials Needed to Complete Script. This list of supplies should be comprehensive and
include everything that the facilitators or participants would need to complete the script. It is
important to be precise about materials if this is important. For example, light colored markers
are hard to read on standard office paper on a wall, so it is important to clearly indicate that dark
tipped colored markers are needed (if this is important). Likewise, blue “painter’s tape” is often
used because it does not damage the walls of rooms. The important point here is to be specific.
Inputs from other Scripts. Scripts are meant to build upon each other so that the end goal of the
GMB project can be attained. Thus, inputs represent the products or outputs of previously
executed scripts or “offline” work by facilitators and modelers that are needed before the current
script can be implemented. It should be noted that some scripts may not require any inputs,
particularly if it is very early in the GMB process. Scripts that do not require inputs and can be
used to initiate a project are often called starter scripts.
Outputs from this Script. Scripts produce outputs. An output may be of interest solely to the
modeler or it may be something that is shared with the entire group. In addition to listing the
script’s outputs, this field should also include a description of how each output is relevant to the
overall project and how it will be used in the future. Outputs that are of interest to the client
group are called deliverables, while outputs that are of primary interest to the modeler are
products.
Scriptapedia 9
Team Roles Required and Expertise Needed. When filling in this field, authors should refer to
the definitions of GMB roles included in Scriptapedia. The system dynamic expertise required
for each role can vary depending on the difficulty of the activities within the script.
Who is in the Room. This field also specifies which participants need to be present (e.g., is it the
entire group or a subset of stakeholders?).
Steps. This field describes in detail each step of the activity and specifies who is doing what. For
example, “Facilitator sets up task by asking participants to write short descriptions of resources
available within the system.” Steps should be thorough so that anyone can follow them without
needing additional explanation. If it is important to use specific language during the facilitation it
should be included in the steps.
Evaluation Criteria. This field should outline indicators of a successful script implementation.
That is, how would someone using this script for the first time know if they have done the script
correctly? The evaluation criteria are often linked to the intended outputs and can also include
behavioral changes in participants or the attainment of certain learning objectives.
Author(s). Authors are the individuals who created the script, not the person filling in the script
template. This field gives credit to those individuals who came up with the ideas and activities
captured in the script. Authors can be individual or collectives, but should be identified with a
name, contact information, and date, “Jane Smith, smith@university.edu March 2, 2010”. In
some cases, a script may have been created and used for some time before it is finally
documented in Scriptapedia; in such cases, the date should reflect when the script was first
created, not when it was entered into the template. Scripts that are in common use or without a
known author have this field entered as author “unknown”.
History & Basis for Script. GMB practitioners often draw upon previous scripts, articles, other
types of small group exercises, etc. when developing a new script. This field should capture this
development process, providing a name and date citation for influential resources (complete
citations should be entered in the References field below). As a script is revised or adapted, it is
important to retain the entire history of origin, not just the previous version. For example, if the
authors were motivated to create the script based on a community ritual, this should be clearly
stated within the field.
Revisions. This field is used to keep track of the iterative process of script writing. It should
describe any major differences between the current script and the original script, as well as the
date the current revisions were made. If significant enough changes have been made between the
original and the current version, then it may qualify as an entirely new script.
References. This field gives the full citation for any publications or resources referenced in the
script, particularly in the history field. For example, if a script is based on another script that was
described in a journal, then mention this history field with an author and year citation, and then
provide the full reference in this field.
Scriptapedia 10
1.5. Handbook of Scripts
Scriptapedia is a digital commons, and its creation has evolved into multiple phases.
Scriptapedia consists of a collection of scripts organized by their status (best practice, promising
practice, and under development). It includes a glossary of terms, resources in system dynamics,
a description of the different roles on a group model building team, the script template, and
examples of session agendas using the scripts. Table | above provides an overview of the table
of contents, and the most recent version of the handbook is included as a supplement to this
paper.
Table 1: Scriptapedia table of contents
Scripts
Best practices
Promising practices
Under development
Appendix A: Glossary
Appendix B: Additional Readings in System Dynamics
Appendix C: System Dynamics Modeling Software and Online Resources
Appendix D: Roles in Group Model Building
Appendix E: Script Template
3. Case Examples
To illustrate the use of Scriptapedia and scripts, we provide four case examples. Each example
highlights a different aspect of how scripts were used.
Case 1: Documenting Scripts. An expert in GMB used the script template for Scriptapedia to
document a number of scripts routinely used in facilitating GMB sessions. The script template
provided a means to organize the information in a structured form, and allowed others unfamiliar
with the specific exercises to replicate several of the exercises with different groups.
Case 2: Tailoring GMB Sessions. A GMB team used scripts to develop a GMB process tailored
to each stakeholder group in a multiple session GMB project. Stakeholder groups included three
sets of residents from low-income communities, professionals in the banking industry, and
representatives from the alternative financial institutes. The facilitation team for these sessions
was relatively inexperienced in GMB and concerned about the appropriate fit between GMB and
the community participants. The core modeling team designing the GMB sessions decided to use
existing scripts from Scriptapedia, but tailor them to the specific audiences in each session. The
tailoring of scripts was primarily in the use and definition of specific terms and probing
questions that facilitators might ask during a GMB session. To accomplish this, each script was
projected onto a screen using a data projector with the core modeling team reading and editing
the script as a team. The result was a set of GMB scripts that the entire team understood and
addressed reservations about the cultural appropriateness of GMB to sessions.
Scriptapedia ll
Case 3: Training Professionals in GMB. Scripts were used in several projects, training
workshops and courses on GMB to introduce participants to the concept of GMB and GMB
scripts. The script template was distributed to all participating in these sessions. By having a
template and seeing how a structured small group exercise was structured in Scriptapedia,
participants were quickly able to learn how to create or adapt/tailor GMB scripts to the specific
local situation and language.
Case 4: Documented a GMB Exercise. An investigator led an unstructured GMB process. The
investigator then used scripts as a way to describe what had transpired in the group after the the
session has been completed.
4. Discussion
In this paper, we have introduced Scriptapedia and scripts as a way to improve GMB practice,
and reflection and learning. Through the two-and-half years of work in developing Scriptapedia,
we have also encountered some issues related to the idea of using scripts and documenting.
These fall into two broad categories: (1) uses, misuses, and misunderstandings of scripts, and (2)
potential limitations.
1.6. Uses, Misuses, and Misunderstandings of Scripts
Scriptapedia presupposes certain benefits of scripts and how they can improve GMB practice
and learning. Some of the intended uses include using scripts to create and use a behavioral
protocol for small group exercises; comparing the protocol to what actually happened as a way to
assess fidelity; teaching GMB using scripts; and, documenting what happened in a small group
process that has already occurred.
However, the benefits from these intended uses of scripts are not without some controversy. One
potential problem comes from facilitators following a script mechanistically, that is, without the
right attitude (Vennix 1999). Scripts are not a substitute for the nonspecific factors involved with
facilitating a group process. Failure to recognize this, attend to the nonspecific factors, and
having the right attitude toward a group is a misuse of scripts.
Some may also object to the use of scripts as being too rigid, too reductionist or mechanistic, or
taking the art out of GMB facilitation. The basic objection here is that a complex social
interaction such as GMB cannot be distilled into linear sequence of instructions in any
reasonable way without excluding the significant amount of professional judgment required to
effectively do GMB.
There are two responses to this that parallel a similar discussion in evidence-based practice in
medicine, public health, social work, psychology, and management. The first is that reducing the
amount of discretion a facilitation team has in GMB is precisely the point of scripts. Discretion
and professional judgment cut both ways—when given freedom to make decisions in complex
systems we often make as many if not more incorrect decisions than correct decisions. Hence,
the number of successes that may be attributed to facilitator discretion is often outweighed by an
equal or greater number of failures. Scripts reduce the discretion and hence increase the
likelihood that a GMB session can be more effectively facilitated. Consider, for example, other
Scriptapedia 12
areas where human performance has improved by limiting the amount of discretion individuals
have in a complex situation such as the use of checklists for pilots and hospital procedures.
The second response to the concern that scripts take the art out of GMB is that there is still a lot
of room for professional judgment and improvisation. In particular, groups are complex systems
with unpredictable dynamics representing both opportunities and hazards for effective
facilitation. GMB also involves many nonspecific factors for sessions to be effective, including
the rapport between the GMB facilitation team and clients, facilitator characteristics, and clients”
perception of the facilitators as experts in GMB and system dynamics. In this, the art of GMB is
still present in structured group model building session. Importantly, scripts actually make it
easier to delineate where professional judgment is required and applied. For example,
improvisation or going off script only make sense if one has script to follow.
1.7. Potential Issues and Limitations
Innovation versus System Dynamics “Lite”. One of the main arguments for developing
Scriptapedia is that by making scripts more accessible, more people will use and contribute
scripts to Scriptapedia. However, there has been a long standing concern in the field of system
dynamics about increasing access without developing deeper knowledge of system dynamics
leading to situation where system dynamics “lite” is being promoted. Scriptapedia has been
explicitly developed for system dynamics group model building, but using scripts from
Scriptapedia does not mean that one is doing system dynamics. Scriptapedia is a tool that can
have many uses beyond its intended use.
Empowerment versus False Confidence. Another area of concern is whether scripts are
empowering or simply give teams a sense of false confidence in their methods. For example,
scripts can make it easier for facilitators try a new role on a facilitation team or lead an exercise
they have not done before, which would then create additional opportunities for learning and
development of facilitation skills. However, there is also an inherent limitation to what can be
conveyed in a script, and the success of a script could well depend on implicit knowledge of the
facilitation team. Thus there is the potential that scripts can also contribute to a sense of false
confidence and impede learning.
Learning versus Reinforcing Attribution Errors. Scripts provide way to explicitly identify the
espoused theory of a group model building intervention and compare the espoused theory against
the theory in use. As such, scripts can help practitioners engage in double-loop learning (Schén
1983). At the same time, limitations in how well a script documents the small group exercise and
knowledge and skills on the facilitation team required to successfully lead the exercise may
ultimately reinforce attribution errors instead of learning. Preventing this will require a
combination of explicit documentation and empirical research.
Digitizing Commons versus Appropriation. Scriptapedia is a collection of scripts for common
use by documenting structured small group exercises. While small group exercises can be
developed by writing a script, many other scripts will essentially be online representations of
exercises that have existing and been used for many years. The origin of the exercises
documented in Scriptapedia may have a known creator or author, a routine practice or ritual
within a specific culture, or not have a known author. A growing concern in digital commons has
Scriptapedia 13
been that efforts to digitize previously undocumented practices amount to a form of knowledge
or cultural appropriation. Of particular concern are situations where a script based in indigenous
knowledge and practices may have economic value in another context. As an open source
commons, anyone could use the scripts for their own commercial gain, but the indigenous
community that had practiced the ritual on which the script was based would not receive an
economic benefit.
Improving Practice versus Regulation, or Who Decides What is “best practice”? The effort
to improve practice through standardizing scripts in Scriptapedia and categorizing some scripts
as best practice can also raise a concern about group model building becoming a regulated
practice. Of particular concern is the question of who decides what best practice is and on what
basis. If the criteria for determining best practice are not widely accepted, then disincentives for
contributing and using Scriptapedia may limit participation and the benefits of having a digital
commons for GMB scripts. To address this, it will be important to establish a governance
structure based in the System Dynamics Society to establish the criteria for best practices and
apply these criteria to scripts in Scriptapedia. As Scriptapedia develops, however, an evidence
base should emerge about which scripts work best under what types of conditions.
5. Future Directions
Looking forward, the future development of Scriptapedia as an effective and well-supported tool
in support of GMB efforts will require attention to a number of specific areas as discussed
below.
Editorial Control of Content. We envision that in the early stages of populating the
Scriptapedia some degree of editorial control, beyond what can be reasonably expected of a more
automated content management system will be needed. As first round authors of content, the
authors of this paper will seek to constitute themselves into some sort of an informal editorial
board working both to encourage the creation of new content as well as work out new ways to
train others in how best to use Scriptapedia. A problem for the longer term will be to locate a
more permanent institutional host for this activity. For example, the System Dynamics Society
could exert long-range control for this project much as it currently does for the System Dynamics
bibliography, or the project could become archived and managed under the supervision of Wiley-
Blackwell, the publishers of the System Dynamics Review. In addition to providing some control
of content, such an institutional sponsor would help to insure that the project survives the
transition from the first generation of authors/editors into a more sustainable format. These
editorial matters, critical to the long-term success of this project, remain to be worked out.
Online Content Collaboration and Management System. Scriptapedia represents more than a
collection of scripts and GMB definitions. Scriptapedia is also meant to be an online content
collaboration and management system. While site design, hosting, and maintenance issues must
be worked out before the site can launch, the following describes the vision for the full
Scriptapedia site. At its core will be a digital version of the script template and a library of all
documented scripts. After creating user accounts, authors will be able to write and collaborate on
scripts from anywhere in the world. Documented scripts will be searchable by authors and other
key fields. Message boards will allow registered users to comment and ask questions about
scripts, best practice, or new developments in GMB. In addition, the site will contain a glossary
Scriptapedia 14
of GMB terms and a description of GMB roles, thereby creating a shared language for the GMB
process. As more scripts are documented, sample agendas for GMB sessions or projects will also
be posted to Scriptapedia. In this way, GMB practitioners can share how they have pieced
together different scripts into a cohesive process. As the online version of Scriptapedia develops,
accessibility and ease of use will be of upmost importance. Since collaboration and learning are
key goals of Scriptapedia, the site platform must be appropriate for experts and novices in system
dynamics and GMB from across the globe.
Workshop and Training. Scriptapedia allows for the dissemination of scripts by creating a
space where they are documented, managed, and accessed. It also provides continuity and
repetition within the field with the use of a generic script template to create new scripts and a
place where existing scripts may be kept and referenced. It seems appropriate to conduct
trainings or workshops on the use of scripts to increase their use and ensure script creation and
use is done appropriately. Developing Scriptapedia and conducting training people in the use of
scripts will help spread GMB and expand the successful application of system dynamics. We see
this as one of the ways that Scriptapedia ultimately contributes to the field of system dynamics.
References
Ackermann, Fran, David F. Andersen, Colin Eden, and George P. Richardson. 2010. ScriptsMap:
A tool for designing multi-method policy-making workshops. Omega 39:427-434.
Andersen, D.F., GP Richardson, and J.A.M. Vennix. 1997. Group model building: adding more
science to the craft. System Dynamics Review 13 (2):187 — 203.
Andersen, David F., John M. Bryson, George P. Richardson, F. Ackermann, Colin Eden, and
Charles Finn, B. 2006. Integrating modes of systems thinking into strategic planning
education and practice: the thinking persons’ institute approach. Journal of Public Affairs
Education:265-293.
Andersen, David F., and George P. Richardson. 1997. Scripts for group model building. System
Dynamics Review 13 (2):107-129.
Andersen, David F., Jac A. M. Vennix, George P. Richardson, and Etiénne Rouwette. 2007.
Group model building: problem structuring, policy simulation and decision support.
Journal of the Operational Research Society 58 (5):691-694.
Beall, AM, and A Ford. 2010. Reports from the field: assessing the art and science of
participatory environmental modeling The International Journal of Information Systems
and Social Change | (2):72-89.
Checkland, PB. 2006. Reply to Eden and Ackermann: Any future for problem structuring
methods? Journal of the Operational Research Society 57 (7):769-771.
Cockerill, K., L. Daniel, L. Malezynski, and V. Tidwell. 2009. A fresh look at a policy sciences
methodology: collaborative modeling for more effective policy. Policy Sciences 42:211—
225.
Dwyer, M., and K. Stave. 2008. Group model building wins: the results of a comparative
analysis. In System Dynamics Conference, edited by B. Dangerfield. Athens.
Eden, C, and F Ackermann. 2006. Where next for problem structuring methods. Journal of the
Operational Research Society 57 (7):766-768.
Eden, C, and J. Radford. 1990. Tackling strategic problems: the role of group decision support
London: Sage.
Scriptapedia 15
Eden, C., F. Ackermann, J. M. Bryson, W. Scott Richardson, David Andersen, and C. B. Finn.
2009. Integrating modes of policy analysis and strategic management practice: requisite
elements and dilemmas. Journal of the Operational Research Society 60:2-13.
Eden, Colin, and Fran Ackermann. 1998. Making Strategy: The Journey of Strategic
Management. London: SAGE.
Franco, L.A., and G. Montibeller. 2010. Facilitated modelling in operational research. European
Journal of Operational Research 205 (3):489-500.
Franco, L.A., and E.A.J.A Rouwette. 2011. Decision development in facilitated modelling
workshops. European Journal of Operational Research 212:164-178.
Ghaffarzadegen, N., James M. Lyneis, and George P. Richardson. 2011. How small system
dynamics models can help the public policy process. System Dynamics Review 27 (1):22-
44.
Hoppenbrouwers, S.J.B.A., H. Weigand, and E.A.J.A Rouwette. 2011. Exploring dialogue
games for collaborative modeling. In E-collaboration technologies and organizational
performance: current and future trends, edited by N. Kock. Hershey: IGI Global.
Howick, S., Fran Ackermann, and David F. Andersen. 2006. Linking event thinking with
structural thinking: methods to improve client value in projects. System Dynamics Review
22 (2):113-140.
Jarboe, S. 1996. Procedures for enhancing group decision making. In Communication and group
decision making (2nd edition), edited by R. Y. Hirokawa and M. S. Poole. London: Sage
Publications.
Keys, P. 2006. On becoming expert in the use of problem structuring methods. Journal of the
Operational Research Society 57:822-829.
McCardle-Keurentjes, M, E.A.J.A. Rouwette, J.A.M. Vennix, and E. Jacobs. 2009. Is Group
Model Building worthwhile? Considering the effectiveness of GMB. In International
System Dynamics Conference. Athens, Greece.
McCardle-Keurentjes, M.H.F., E.A.J.A. Rouwette, and J.A.M. Vennix. 2008. Effectiveness of
group model building in discovering hidden profiles in strategic decision-making. In
System Dynamics Conference, edited by B. C. Dangerfield. Athens.
Poole, M.S., and G. DeSanctis. 1992. Microlevel structuration in computer-supported group
decision making. Human Communication Research 19 (1):5-49.
Richardson, George P. 2006. Concept models. In Proceedings of the 24th International
Confernece of the System Dynamics Society.
Richardson, George P., and David F. Andersen. 1995. Teamwork in group model building.
System Dynamics Review 11 (2):113-137.
Richmond, Barry. 1997. The strategic forum: aligning objective, strategy, and process. System
Dynamics Review 13 (2):131-148.
Roberts, Edward B. 1977. Strategies for effective implementation of complex corporate models.
Interfaces 8 (1):26-33.
Rouwette, E.A.J.A. 2011. Facilitated modelling in strategy development: measuring the impact
on communication, consensus and commitment. Journal of the Operational Research
Society 62:879-887.
Rouwette, E.A.J.A.. and J.A.M. Vennix. 2009. Improving operations management by
synthesizing participant knowledge and system data. In Strategisches und operatives
Produktionsmanagement: Empirie und Simulation, edited by J. Strohhecker and A.
GréBler. Wiesbaden: Gabler.
Scriptapedia 16
Rouwette, E.A.J.A., JAM. Vennix, and T. Van Mullekom. 2002. Group model building
effectiveness. A review of assessment studies. System Dynamics Review 18 (1):5-45.
Schén, Donald A. 1983. The reflective practitioner: How professionals think in action. New
York, NY: Basic Books.
Stenberg, L. . 1980. A modeling procedure for public policy. In Elements of the System
Dynamics Method, edited by J. Randers. Cambridge, MA: MIT Press.
Straus, David. 2002. How to make collaboration work. San Francisco, CA: Berrett-Koehler
Publishers, Inc.
Vennix, J. 1996. Group model building. New York: John Wiley & Sons.
Repeated Author. 1999. Group model-building: Trackling messy problems. System Dynamics
Review 15 (4):379-401.
Vennix, Jac A. M., David F. Andersen, and George P. Richardson. 1997. Forward: group model
building, art, and science. System Dynamics Review 13 (2):103-106.
Vreede, GJDe, R. O. Briggs, and G. L. Kolfschoten. 2006. Thinklets: a pattern language for
facilitated practioner-guided collaboration processes. /nternational Journal of Computer
Applications in Technology 25:140-154.
Westcombe, M., L.A. Franco, and D. Shaw. 2006. Where next for PSMs - A grassroots
revolution? Journal of the Operational Research Society 57 (7):776-778.
Zagonel, AA, and J. Rohrbaugh. 2008. Using group model building to inform public policy
making and implementation. In Complex Decision Making, edited by H. Qudart-Ullah, J.
M. Spector and P. I. Davidsen: Springer-Verlag.
Zagonel, AA, J. Rohrbaugh, George P. Richardson, and David F. Andersen. 2004. Using
simulation models to address "what if" questoins about welfare reform. Journal of Policy
Analysis and Management 22 (4):890-901.
Zock, A. 2004. A critical review of the use of System Dynamics for organizational consultation
projects. Paper read at International System Dynamics Conference, at Oxford, UK.
Scriptapedia 3.05
Acknowledgements
Scriptapedia is a collaborative effort to make group model building in system dynamics more transparent, accessible,
and shared around the world. A number of individuals have been integrally involved in developing and leading this effort
(in alphabetical order): David F. Andersen (University at Albany New York), Annaliese Calhoun (Washington University in
St. Louis), Peter S. Hovmand (Washington University in St. Louis), Timothy Hower (Washington University in St. Louis),
Etigénne Rouwette (Radboud University Nijmegen), Eric Steins (Kirwan Institute for the Study of Race and Ethnicity),
George P. Richardson (University at Albany New York), and Krista Rux (Washington University in St. Louis).
Funding for Scriptapedia was partially provided by the Centers for Disease Control and Prevention through the Brown
School Violence and Injury Prevention Center (1R49CE001510), National Institutes of Health (HHSN 276200900017C);
and, the Social System Design Lab at the Brown School of Social Work, Washington University in St. Louis.
Citing Scriptapedia
Content from Scriptapedia should be appropriately cited when used in publications and derivative works. The suggested
format for citing Scriptapedia is:
Hovmand, Peter S., Etiénne A. J. A. Rouwette, David F. Andersen, George. P. Richardson, Annaliese Calhoun,
Krista Rux, and Timothy Hower. 2011. Scriptapedia 3.04. Place Published.
http://www.systemdynamics.org/other_resources.htm/scriptapedia (accessed <date accessed>).
License
Content in Scriptapedia is licenses under the Creative Commons Attribution-ShareALike 3.0 Unported License. Anyone is
free to share (copy, distribute, and transmit the work) and remix (adapt the work) under the following conditions: (1)
users must attribute the work in a manner specified by the author of the content , but not so in a way that suggests that
they endorse or are using adaptation, and (2) if a user alters, transforms, or build upon another author or authors’
works, users can distribute the resulting working only under the same or similar license as this one. With this
understanding, any of the above conditions can be waived if the user gets permission from the copyright holder. If any
or all of the elements of the work is already in public domain under applicable law, that status is in no way affected by
the license. In no way are any of the following rights affected by the license: (1) users fair dealing or fair use rights, or
other applicable copyright exceptions and limitations; (2) author’s moral rights, and (3) rights other persons may have
either in the work itself or in how the work is used, such as publicity or privacy rights. For any reuse or distribution, the
user reusing or distributing Scriptapedia and its contents must make clear to others the license terms of this work. The
best way to do this is by copying this page or linking to the Creative Commons Attribution-ShareALike 3.0 Unported
License website.
Table of Contents
Best Practices
Hopes and Fears .....
Graphs over Time....
Concept Model...
Ratio Exercise
Initial Policy Option:
Promising Practices...
Creating a Shared Vision of Modeling Project
GMB Process Mapping
Debriefing
Under Development...
Places to Intervene...
Community Snapshot...
Appendix A: Glossary...
Appendix B: Additional Readings in System Dynamics
Appendix C: System Dynamics Modeling Software and Online Resources ....
Appendix D: Roles in Group Model Building
Appendix E: Script Template.
eYecyeerasaceg Hopes and Fears Script
Best Practices
Hopes and Fears
Description: Process elicits hopes and fears around group model building
Context: At the beginning of a group model building project.
Primary nature of Divergent
group task:
Prep time: none
Time: Time during session: 30 minutes
Follow-up time: none
* Two different colors of office paper (8.5 x 11) with enough for multiple sheets for each
Materials: participant
* Thick markers
* Blue "painters" masking tape
Inputs: None
Outputs from this
script:
List of participants hopes and fears
Roles:
Community facilitator with good group facilitation skills and knowledge of the local language
and topic.
People in the room:
All participants and members of the core modeling team
Steps:
1. Participants are given several sheets of paper in each color. The community facilitator
explains that they will be writing their hopes and fears for the project, and then sharing
them with the group.
2. The community facilitator states which color represents hopes and which represents
fears.
3. In a round-robin fashion, each participant then reads one fear and one hope. The
community facilitator takes each hope and fear that the participant has read and posts it on
the wall. After each participant has had a chance to share once, the community facilitator
goes around the room until everyone has shared all of their hopes and fears.
4. The community facilitator then tries to identify some of the themes of the hopes and
fears. Recorders write down the hopes and fears.
Evaluation criteria:
Participants have shared both their hopes and fears for the upcoming project; participants
understand the overall themes of the hopes and fears.
Authors: George P. Richardson and David F. Andersen
History: None
Revisions: None
Andersen, D. F., & Richardson, G. P. (1997). Scripts for group model building. System
Dynamics Review, 13(2), 107-129.
References:
Luna-Reyes, L. F., Martinez-Moyano, I. J., Pardo, T. A., Cresswell, A. M., Andersen, D. F., &
Richardson, G. P. (2006). Anatomy of a group model-building intervention: Building dynamic
theory from case study research. System Dynamics Review, 22(4), 291-320.
tevegeadecey Graphs over Time Script
Graphs over Time
Description: Participants produce sketches of key variables over time, which are clustered by the modeling team
Purpose of Framing the problem, initiating mapping, eliciting variables, and input to deciding the reference
script: modes for the study
Primary Divergent
nature of
group task:
Prep time: 10 minutes
Time: Time during session: 45-60 minutes
Follow-up time: N/A
* Camera or other method to capture the graphs
* Stacks of 8.5x11 white paper with axis drawn on them
Materials: * Large blank wall (8'x10')
° Fat markers
* Glue sticks, blue tack, or tape
Inputs: None
Outputs from | Candidate variables for the dynamic model or the map
this script:
* Modeler facilitator to work with the group with some experience with SD
* Modeler listening to what is being graphed and the way people are talking about the graphs who
Roles: must also be able to conceptualize early seeds of system structure.
* Wall builder to cluster graphs and talk about themes with little or no experience in SD
* Runner (optional) to brings the graphs from the community facilitator if the group is large
* Recorder to document the session and photograph the clustered graphs
People in the
room:
All members of the core modeling team and participants
Steps:
1. Based on group size, decide whether to break participants into subgroups. In smaller groups
N<10, allow individuals to work and present independently. In larger groups N >10, divide
participants into groups of roughly N/10. Ask the subgroups to sit together.
2. Modeling team hands out sheets of white paper to each participant
3. Facilitator gives example of how to draw a graph over time. Carefully labeling X axis with
“Time”, start and end times, and now with a vertical dashed line. Label Y axis with variable
name. Sketch the behavior.
4. Facilitator then asks participants to draw one variable over time per piece of paper. Give
participants the option of including hoped for behavior, expected behavior, and feared
behavior on the same graph.
5. Facilitator and wall-builder walk around and help participants with the task if they need it.
(Allow 15 minutes or until the group runs out of steam)
6. Reconvene as large group.
a) If N<10, facilitator takes one graph at a time from each participant, holds it up in front of
entire group and asks him/her to talk about it. Ask for participants to share the “best stuff”
first. Clarify timescale, variable names, etc.
b) if N>10, instruct subgroups to share their graphs with each other and choose the ones
they think are most important. Facilitator then goes to each subgroup and holds the first
graph they have selected up in front of entire group. Subgroup spokesperson talks about
graph. Ask subgroups to share the “best stuff” first. Clarify timescale, variable names, etc.
7. Facilitator then hands the graph to the person building the wall.
8. Facilitator repeats steps 6 and 7 with each participant or subgroup, taking one graph ata
tevegeadecey Graphs over Time Script
time until all graphs are shown or time has run out. Finish by asking if any participant has
something else that really ought to be shown.
9. During steps 7-8, each graph is posted on the wall. Wall builder tries to cluster the graphs
meaningfully on the fly, based on themes and variables.
10. Facilitator asks wall builder to explain the clusters of graphs on the wall. Wall builder tries to
summarize dynamics that help to characterize the problem that emerges from the
participants’ graphs.
11. Facilitator enables the participants to talk about the clusters and the characterization of the
problem they imply.
12. Consider labeling the clusters based on themes or related variables
13. Potential for modeler to close by highlighting the beginnings of feedback thinking in the
dynamic problem.
* Interesting, self-sustaining group discussion after clusters described by the wall builder
* Meaningful clusters are possible to see
* Graphs tend to converge to a clear dynamic problem
Evaluation
eriterion * Some key dynamic variables emerge from reflecting on the graphs and clusters
* Modeling team can begin to see key stocks and perhaps important feedback loops
* Members of the group appear to have better understandings of the issues of interest to
other members
Authors: George Richardson ( gpr@albany.edu), David Andersen ( david.andersen@albany.edu)
History: n/a
Revisions: n/a
References: Andersen, D. F., & Richardson, G. P. (1997). Scripts for group model building. System
Dynamics Review, 13(2), 107-129.
tevegeadeceg Concept Model Script
Concept Model
Description: Using a Concept Model with a group
Context: Before initiating modeling
Primary Presentation
nature of
group task:
Prep time: Concept Model is insightful and tricky
Time: Time during session:25-30 minutes
Follow-up time: none
: * White board and markers (to draw model in stages)
Materials: . . . .
* Computer and projector (to project simulation model)
Inputs: None
Outputs from
¢ Familiarity with stock and flow and causal icons
* Understanding that maps can be quantified and simulated
* Understanding that models can be created for the groups’ problem(s)
this script: 7 : 7
*¢ Understanding that the model is owned by the group and can be repeatedly modified and
improved
Roles: * Very experienced modeler to design the Concept Model
* Experienced helper to show and run the formal model is useful
People in the
room:
All participants who will be involved in the group model building process
1. First version of concept model drawn by hand on white board (show tub with faucet and drain to
explain stock & flow icons)
2. First (identical) quantified version projected from computer; note it’s identical. Simulate and
trace the behavior.
3. On white board add one or more elements to the first version to get an amended Concept
Model (second version). Project second version from computer; simulate; trace behavior over
ptebs: time. Behavior should be different to get “Behavior is a consequence of structure.”
4. Repeat step 3 one more time.
5. Summarize lessons: icons we will use, maps can be quantified and simulated, behavior can be
generated endogenously, changing structure changes behavior, maps and models can be
repeatedly refined, we can own the model the group creates.
Evaluation Participants are talkative, wanting to tell the modeler how the model is wrong and can be improved.
criteria:
Authors: George Richardson, 9 Sept 2010
History: First used in foster care workshops in early 1990s and used repeatedly by Richardson and Andersen
for every group model building intervention since. Not widely used (or understood) by others.
Revisions: Clarity of purposes
Richardson & Andersen, “Teamwork in Group Model Building,” SDR 11,2 (1995)
References:
Richardson, “Concept Models,” International System Dynamics Conference, Nijmegen, July 2006
Pleemeadeceg Ratio Exercise Script
Ratio Exercise
This is one of several scripts that are used to help map feedback structure after key stock variables
cr sca have been identified.
PUrnOsercT ° eu) be use to Initiating mapping in special cases, but major purpose is
omnes * — Eliciting feedback loops (especially minor loops) and
* — Eliciting variables within the chain of causality in the minor loops
Primary Convergent
nature of
group task:
Prep time: Most of the preparation time is spend in going over the candidate stock variables
carefully to find pairs of variables that have ratios (or differences that can be named and make
sense.
Time: Time during session: Once key stock variables have been identified, it takes only a few minutes (10
minutes) to put the stock variables up on a white board for mapping.
Follow-up time: required by the recorder (to capture the feedback loops in a photograph or Vensim
diagram or by the modeler reflector who may want to incorporate some of the elicited feedback
loops into “cleaned up” views of model structure, approximately 30 minutes.
* Large erasable white surface (cling sheet wall or white board
* White board markers
Materials: * Recorder will want to capture image in Vensim sketch or with a camera
* Modeler reflector may redraw some of the mapped feedback loops on blank overhead slides
using a water-soluble or dry-erase marking pen
inputs This script cannot be completed until the group has defined pairs of stock variables whose ratio or
difference make sense to the group (e.g., class size, case load, vacancy rate, occupancy rate, etc.)
Outputs from
Using this script it is very possible to get a group to naturally generate feedback loops. The script
lead easily and naturally into feedback thinking and the concurrent articulation and mapping of
nis sche: feedback effects.
* Once this script gets going, a facilitator with modest experience in SD will in most likelihood be
able to lead the group in mapping feedback effects (perhaps more skill is required in recognizing
the stock variables and getting the exercise set up.
Roles: * The modeling team gets lots of good material easily from this script. Modeler skill is need in the
“modeler feedback” follow up where the feedback loops elicited by the group are integrated
into more complicated “cleaned up” feedback diagrams
* The recorder needs to be able to operate a camera or sketch the geometry of feedback loops
using software such as Vensim
People in the
room:
* The entire modeling and facilitation team is either participating in or watching the development
of the feedback loops. This is a gratifying script to use because it so often reliably and quickly
populated the public diagram with a dense network of feedback loops
* The entire client team typically participates in this exercise. This is, we typically use this as a
whole group exercise.
Steps:
1. This script typically develops offline when the modeling team realizes that a strong and clear
set of stocks and flows exist to undergird this system and that aging chains of usually service
loads (students, patients, clients) can be linked to some resource of stocks (teachers, nurses,
caseworkers) so that the pairing of related stocks makes sense. Sometimes the modeling
team realizes this quite early on (sometimes they have a strong hunch before the session
even begins).
2. Someone, usually the modeler picks out which pair of stocks to work with first. Then the
facilitator asks the group to name the ratio or difference (caseload, class size, etc.). The
facilitator adds the ratio or difference variable using the exact name that the group has
Pleemeadeceg Ratio Exercise Script
suggested (different groups use differing terminology for a similar concept and some groups
use differences and some use ratios--occupancy rate versus number of vacancies—so it is
important to use their terms.
3. The facilitator maps the ratio (or difference variable) with the incoming arrows marked with
“+” or “-““as is causally appropriate.
4. The facilitator asks the question, “what would happen if this ratio were to go to zero or get
unusually small” or “what would happen if this ratio were to become very large—how would
the system react?”
5. The group then starts to tell feedback stories about how the system reacts when this key
ratio (or difference) gets out of what. When loops are completed, the facilitator can trace
them out for the group adding appropriate “+” or “-“, telling the stories of the loops. These
loops are almost always balancing loops.
Steps 2 to 5 are repeated with another set of ratios
* This script will usually fill a white board with lots of feedback loops very quickly
* Participants will “get the hang” of what feedback loops are, how they work, and will start to look
Evaluation for them.
criteria: * Avery good map will have feedback paths that connect to other important stocks in the system
(other than simple first order loops). These insights that pass through other stocks are especially
important.
Authors: Initial draft by David F. Andersen (David.andersen@albany) on July 1, 2010. Reviewed by George P.
Richardson (gpr@albany.edu)
This script was first developed and used by Richardson and Andersen in the 1990s. It is a real “work
History: horse” script, yielding lots of feedback in a reliable fashion. In 2010, this script was listed by
Richardson and Andersen in their ScriptsMap.
Revisions: None
eegeadecey Initial Policy Options Script
Initial Policy Options
Eliciting a list of realistic policy experiments the group would like to see investigated and analyzed
Description: with modeling and simulation
* Framing the problem
Purpose of * Eliciting variables (implicitly, by implication)
script:
Primary nature
* Divergent: activity designed to produced an array of different ideas and interpretations
of group task:
Preparation time: at most 5 minutes (assembling paper and markers)
Time: Time required to complete steps in script: 30 to 60 minutes
Follow up time:
* Markers
° 8.5x11 A4
Materials: % (or ) paper . .
* Glue sticks (blue tack, masking tape) for posting on wall
* Wall for posting!
* none
Inputs:
Outputs from
this script:
* List of specific candidate policy options to be used to:
- Help define the problem(s)
- Help set the model boundary
- Help set realistic expectations for the direction and outcomes of the meetings
- Helps modelers build a model that suits the group’s needs
Roles:
* Facilitator
* Helper to cluster the policy options on the wall and describe the resulting clusters
People in the
room:
* All participants in the group model building effort
1. Facilitator sets up task by asking participants to write short phrases naming policies that
participants would like to see discussed, modeled and simulated in the course of the work.
2. One policy per page.
3. Could be policies tried in the past or currently, or policies being talked about for the future, or
realistic but wild ideas.
4. Participants work in pairs perhaps, to build confidence and share thinking while still keeping the
divergent nature of the group task
Steps: - , ‘ iia . .
5. Facilitator collects policy pages one at a time (receiving one page per pair and going on to the
next pair to assure complete involvement). Asks pair to talk about their proposed policy option.
6. Helper posts the policy pages on the Wall, clustering them on the fly according to emerging
themes
7. Repeat steps 5 & 6 until done, or time runs out.
8. Facilitator asks Helper to describe the clusters, justify the choice of clusters, and talk about
“what he sees” in the whole effort.
Evaluation * The length of the list.
eegeadecey Initial Policy Options Script
criteria:
* The realism of the list - Does the group see the list as appropriate?
* The workability of the list - Does the modeling team see the list as helpful for the model
building?
Authors:
To my knowledge, never written up or ascribed to anyone in particular. A widespread script.
History:
Used by Andersen & Richardson, individually and as a team, for years. Could be said to stem from
Nat Mass’s 1980 observation on a draft of the Richardson-Pugh text (expressed to Richardson) that
defining problems dynamically is only part of the story, that many times consultants and modelers
have only lists of policy options to use to begin the modeling process.
Revisions:
There are probably some, but the script is so simple that revisions would have been few and
probably hard to identify. Clustering could have been a revision early on.
References:
None that | know of.
Promising Practices [kegiem
Promising Practices
Creating a Shared Vision of Modeling Project
Description:
Creating a shared vision of the modeling project
Script Status:
* Best practice: this script has been used many times and in different settings and has
consistently produced the intended outputs.
* Promising practice: this script has been used a few times with good results, but needs
additional refinement and testing
Primary * Convergent: activity designed to clustering and categorizing ideas and interpretations.
nature of
group task:
Preparation time: 30-60 minutes
Time: Time required to complete steps in script: 60 minutes
Follow up time: none
Materials: * Overhead projector, laptop, and electricity
* Camera
Inputs: * Draft modeling project description
Outputs from | © Revised modeling project description
this script:
¢ Facilitator is leading the review and discussion of the modeling project
Roles: ¢ Recorder is typing changes to the modeling project description
* Gatekeeper who is advocating for the organization/community’s interest in the model and
value of model to the organization/community
People in the
room:
* Everyone
1. Recorder presents the draft modeling project description
2. Facilitator leads a discussion of the description and editing changes to the modeling project
description to better reflect the focus of the modeling project
Steps: 3. Facilitator helps the group evolve consensus for each section with changes made and the
recorder tracks changes in the modeling project description.
4. Repeat steps 2 and 3 for each section of the modeling project description, moving onto the next
section only after consensus has been reached.
¢ People are participating in the discussion, contributing, and indicate understanding of the
Evaluation terms of the modeling exercise, motivation, and purpose
criteria: * Clarity of document
¢ Consensus on modeling project description
Authors: Foundation for Ecological Security and Social System Design Lab, November 9, 2010
History: Created during the Rajasthan Commons Modeling Project
Revisions: None
References: None
[ Promising Practices [eMMis Process Mapping Script 10
GMB Process Mapping
Description: Developing a process map for a group model building project
Durveecrot * To plan and develop a shared understanding of the overall group model building process
ie * To identify the number of sessions, how many people and who will be involved in each session
* To identify the inputs and outputs for sessions
Primary nature
* Convergent: activity designed to aggregate and merge ideas and interpretations.
of group task:
Preparation time: 10 min
Time: Time required to complete steps in script: 45 min
Follow up time: 10 min
* Microsoft Visio
Materials: * Blank or draft process map with basic phases of project
* Data projector
Inputs: * None
Outputs from * GMB process map
this script: * Descriptions of modeling team and participants for each session
¢ Facilitator familiar with group model building who can introduce scripts, share sample
agendas, and different roles in GMB
¢ Facilitator with expertise in group model building familiar with process maps and using Visio
Roles: to draw process maps
Recorder who is tracking categories of participants and facilitators during the discussion,
and then confirming this list with participants at the end
Recorder who is taking process notes on the planning session
People in the
room:
Core modeling team
Steps:
5. Introduce blank process map
6. Explain the criteria for selecting stakeholder tracks.
The criteria for identifying a stakeholder group or track for a group model building session are
primarily based on who you want to have in the room developing a particular model. You might
want to think about what kind of conversation or dialogue you want to elicit from participants or
who you want to be able to attribute the model to. For example, is it important to elicit
divergent views on a subject where people might have different experiences? Is it important to
be able to say that the model was drawn by consumers or some other stakeholder group?
Note: A common issue in identifying stakeholders is that groups will tend to generate long lists
of people involved in the system or focus on recruitment strategies for getting them involved.
These tend to be counter-productive starting places because it is often not clear what is being
asked of individuals being recruited.
7. Begin by introducing the core modeling team as the first stakeholder track and different phases
of modeling.
8. Then try to identify one stakeholder track and begin to identify some sessions. As the sessions
are discussed, identify who is in the session in terms of facilitators and participants.
9. Continue to add and change sessions during the discussion with periodic checks to confirm the
[ Promising Practices [eMMis Process Mapping Script at
state of the process map.
10. Each session with the same agenda should have the same numerical prefix and be distinguished
with a letter suffix (e.g., 6A, 6B, etc. would all indicate multiple sessions using the same agenda;
7, 8, 9, etc. would indicate multiple sessions with different agendas).
11. Identify inputs or outputs that might be needed in the session.
12. Near the end of the session, the recorder keeping track of descriptions of facilitators and
participants starts a review by going through each numbered session. As the recorder lists the
participants and facilitation team for the session, the facilitator highlights that particular
session.
There is general agreement and buy-in on the overall plan for group model building among the
core modeling team
The core modeling team has a clear idea of how many sessions are involved, when they will
Evaluation
criteria: happen, and who will be involved
. * There is an initial sense of who will facilitate the group model building sessions and needs to be
involved in the training
* The core modeling team has sufficient information to develop an IRB application
r f2) .edu, ,
Authors: Peter Hovmand (phovmand@wustl.edu, June 24, 2010)
This approach is based on David Straus’s (2002) approach to designing collaborations and group
process. The motivation for both using process maps and making the process explicit comes from the
History: tendency to underestimate the amount of planning required to design even relatively short group
model building workshops.
Revisions: None
David Straus (2002). How to make collaborations work: powerful ways to build consensus, solve
References:
problems, and make decisions. San Francisco, CA: Berrtt-Koehler Publishers, Inc.
Poromising Practices [ eae
12
Debriefing
Description | This script is used to organize the team’s debriefing session after a GMB session.
Context Immediately after a GMB session.
Purpose(s) ¢ Provide an opportunity for team members to share initial impressions of the GMB session
¢ Provide emotional support team members
¢ Help the team learn how to improve GMB practice.
Nature of ¢ Evaluative: activity designed to evaluate and choose between options and ideas
group task
Time Preparation time: None
Time required to complete steps in script: 30-60 minutes, depending on complexity of session
being reviewed
Follow up time: None
Materials * Chairs in a circle
needed to
complete
script
Inputs from
¢ Final, detailed version of the Script from GMB session being debriefed
other scripts
Outputs ¢ Completed Evaluation instrument(s)
from this * Completed Debriefer Worksheet
script * List of actions necessary to implement improvements
Modeling * Debriefer skilled at facilitating group process, culturally sensitive, and only observing the
team roles modeling exercise
required
and
expertise
needed
Who is inthe | « All Modeling Team members who participated in session under review
room?
Steps 1. Assemble the participants, announce the start of the debriefing session.
2. Debriefer reviews the process the team will use to conduct the review.
3. Begin with a check-in to see how people are doing. This is important regardless of whether
the session went well or badly.
4. Ask the following questions:
* How are you feeling about how this GMB session went?
* Overall, did we accomplish what the session was designed to do?
* What went well during this session?
* Were there any rough parts for you?
* What did you learn from this session?
* How could the session have been improved?
Evaluation 1. Stronger, more cohesive team after the debrief
criteria 2. List of ways to improve the process.
J Promising Practices [Pesaran Script 13
Author(s) Amanda Lavallee (amaylavallee@hotmail.com), Timothy Hower (thower@wustl.edu), and Peter
Hovmand (phovmand@wustl.edu), April 6, 2010
History & Original Script based on current practice and author's work.
Basis for
Script
Revisions
Revised March 28, 2011 by Peter Hovmand to simplify the questions
References
Clireltal-autesutsaia Places to Intervene Script 14
Under Development
Places to Intervene
Description: | Identify potential intervention points
Script (Choose one and delete the bullets below that do not apply)
Status: ¢ Best practice: this script has been used many times and in different settings and has
consistently produced the intended outputs.
* Promising practice: this script has been used a few times with good results, but needs
additional refinement and testing
* Under development: this script still needs to be refined and tested
Purpose of sivas 2 , ,
artiste ¢ Eliciting potential intervention points
Primary ¢ Convergent: activity designed to produce an array of different ideas and interpretations
nature of
group task:
Preparation time:
Time: Time required to complete steps in script:
Follow up time:
¢ Thick markers
Materials: ¢ Large sheets of paper, enough for each of the main
Taputs! * Causal loop diagram or stock-and-flow diagram with sufficient confidence/buy-in from
participants to be useful
Outputs ¢ Prioritized list of interventions
from this
script:
* Modeler facilitator
Roles: ¢ Community facilitator
People inthe | * Everyone
room:
1. Modeler facilitator introduces the different places to intervene in a system using Meadows
Steps: 1999 article and illustrates each type of intervention using the previously developed model,
. which could either be a stock and flow diagram or causal loop diagram.
Evaluation (How do you know that the script has been successful? E.g. behavioral changes of participants,
criteria: learning goals achieved)
Authors: Peter Hovmand (phovmand@wustl.edu), February 2011
(This can include previous scripts, articles, other types of small group exercises, etc. The history
History: should provide a name and date citation, and retain the entire history of the script, not just the
previous version. )
Revisions: (Briefly describe what changes have been made between this version and earlier versions)
References: Meadows, D. (1999). Leverage points: places to intervene in a system. Hartland, VT: The
Sustainability Institute.
Ulareltal-aute) sasaig COMmunity Snapshot Script
15
Community Snapshot
Description | Participants identify their role within the model
Context After a causal loop diagram or stock-and-flow diagram has been presented
Purpose(s) * Conclude session with time for participants to share their thoughts or their roles within
the system
* Create discussion around the model and the participant’s role
* Create collaboration among participants
¢ Identify next steps
Nature of Convergent: activity designed to aggregate and merge ideas and interpretations.
group task
Time Preparation time: 5 min
Time required to complete steps in script: 30 min
Follow up time: N/A
Materials * White board/flip chart
needed to ¢ Markers
complete * Camera
script
Inputs from
¢ Behavior over time graphs
other scripts * Causal loop diagram
Outputs ¢ Potential roles for participants
from this * Development of collaborations/connections
script
Modeling ¢ Facilitator/elicitor to work with the group- some experience with SD
team roles ¢ Modeler/reflector listening to what is being said based on the model, able to
required conceptualize discussion of “community snapshot”- expert in SD
and * Recorder/photographer to document session- no experience needed
expertise ¢ Note taker to document discussion around model and their role - some experience with
note taking from previous sessions
needed 8 P
Who is in the * Modeler
room? ¢ Facilitator
¢ Note-taker
* Participants
¢ Core Modeling Team
Steps 1. Refer back to Causal Loop Diagram
Discuss the general relationships within the model
Discuss individual roles participants have in the model
Describe this as a “community snapshot”
Where do you see your work represented in the diagram?
Based on this diagram, do you see any new strategies that you would want to
incorporate into your work?
SS US ans
Ulareltal-aute) sasaig COMmunity Snapshot Script 16
7. How is your work connected to others? In the room? Not in the room?
Does this capture connections that are new or suprising?
9. Does the diagram suggest possible collaborations that you may have thought of
previously but never implemented? Possible collaborations that you haven’t thought
of previously?
10. What can we take away from this?
~
Evaluation Identification of individual roles in the community/model, discussion of the relationships and
criteria linkages within the model, identification of potential areas for collaboration, clarification of
next steps
Author(s) Krista Rux (krux@wustl.edu) August 3, 2010
History &
Basis for
Script
Revisions none
References none
Balancing loop
Behavior over time graph
System boundary
Detail complexity
Dynamic complexity
Endogenous variables
Exogenous variables
Feedback loop
Flow or rates
Group model building
Material boundary
Mental models
Reference modes
Reinforcing loop
Stocks or levels
System dynamics
17
Appendix A: Glossary
A feedback loop that counteracts a change and moves the system toward some goal (also
known as negative feedback loop)
Graph of one or more system variables over time showing the behavior of a system over
time
Conceptual boundary distinguishing endogenous from exogenous variables in a feedback
system
Number of components in a system
Number of dynamic behavior patterns that a system can produce (e.g., oscillations,
overshoot and collapse, etc.)
Variables in a model that are influenced by other variables in a model
Variables in the model that are strictly causes of other variables and not influenced by
other variables in a model
A causal chain that “feeds back” on itself.
Movements of conserved quantities from one stock to another stock
Process of developing a causal loop diagram or simulation model with participants in the
system in a group format
Defines exchanges of conserved quantities (e.g., people, resources) with the environment,
and often denoted with a cloud symbol attached to a flow or rate
Mental representations of the real system used to solve problems and guide action
Description of the dynamic problem and usually described through a behavior over time
graph
A feedback loop that reinforces or amplifies a change (also known as positive feedback
loop)
Accumulations of flows or rates, define the state of a system
A method for understanding systems and change using the concepts of feedback loops,
stocks and flows, and computer simulation
Appendix 18
Appendix B: Additional Readings in System Dynamics
Ford, A. (1999). Modeling the environment: An introduction to system dynamics modeling of environmental
systems. Washington, DC: Island Press.
Forrester, J. W. (1961). Industrial dynamics. Waltham: Pegasus Communications, Inc.
Forrester, J. W. (1969). Urban dynamics. Cambridge, MA: MIT Press.
Forrester, J. W. (1971). Principles of systems. Waltham: Pegasus Communications, Inc.
Levin, G., & Roberts, E. B. (1976). The dynamics of human service delivery. Cambridge, MA: Ballinger Publishing
Company.
Meadows, D. H. (1980). The unavoidable a priori. In J. Randers (Ed.), Elements of the system dynamics method
(pp. 23-57). Cambridge, MA: Productivity Press.
Meadows, D. H. (1991). Global citizen. Washington, DC: Island Press.
Meadows, D. (1999). Leverage points: places to intervene in a system. Hartland, VT: The Sustainability Institute.
Saeed, K. 1998. Towards Sustainable Development, 2nd Edition: Essays on System Analysis of National Policy.
Aldershot, England: Ashgate Publishing Company. (available at
http://www.wpi.edu/Academics/Depts/SSPS/People/Saeed/Book/)
Senge, P. (1990). The fifth discipline. New York, NY: Curency Doubleday.
Sterman, J. D. (2000). Business dynamics: Systems thinking and modeling for a complex world: \rwin McGraw-
Hill.
Vennix, J. (1996). Group model building. New York: John Wiley & Sons.
Vennix, J. (1999). Group model-building: Tackling messy problems. System Dynamics Review, 15(4), 379-401.
Warren, K. (2002). Competitive strategy dynamics. West Sussex, UK: John Wiley & Sons, Ltd.
Warren, K. (2004). Improving strategic management with the fundamental principles of system dynamics.
System Dynamics Review, 21(4), 329-350.
Appendix C: System Dynamics Modeling Software and Online Resources
Vensim software (Personal Learning Edition available at no cost) http://www.vensim.com/
IThink/STELLA
http://www. iseesystems.com/
Strategy Dynamics
http://www.strategydynamics.com/
Social System Design Lab
http://www.gwbweb.wustl.edu/research/systemdynamics/
System Dynamics Society (includes links to conference proceedings) http://www.systemdynamics.org/
System Dynamics and Systems Thinking in K-12 Education
http://www.clexchange.org/
MIT Roadmaps
http://web.mit.edu/sdg/www/roadmaps.html
Centers Disease Control Syndemics Network
http://www.cdc.gov/syndemics/index.htm
19
Appendix 20
Appendix D: Roles in Group Model Building
Community Facilitator: Primary responsibility for facilitating the group model building sessions. This is a person who is
familiar with the local or substantive knowledge of the problem being modeled and knows the local language
and community norms in cross-cultural situations. The substantive expert/facilitator should have strong group
facilitation skills, some exposure and training in system dynamics, and have sufficient knowledge of the topic or
community to anticipate and mediate conflicts that might arise within the group model building session. This
person extends their social capital to help the community accept and work with the modeler facilitator.
Data Manager: Primary responsibility for making sure that the information collected during the exercises including
diagrams, group model building scripts, agenda, pictures, notes, electronic versions of diagrams, etc. are
collected, appropriated archived and made available.
Debriefer: Primary responsibility for facilitating the discussion after a group model building session. This is a rotating role
among the core modeling team. The debriefer follows a semi-structured format asking for people’s initial
reactions, identifying areas of strength, and identifying areas of improvement for subsequent sessions. The
debriefer essentially allows members of the core modeling team to debrief and reflect on group model building
sessions in a systematic way for a limited period of time. The debriefer should not be someone who experienced
a particularly challenging situation during the group model building.
Gate Keeper: Primary responsibility for making sure that the modeling project is meeting the needs of the client
organization or community to the modeling team and communicating the modeling process and results to the
client organization or community.
Modeler Facilitator: Primary responsibility for system dynamics modeling and group model building process. This is a
person who is trained in systems thinking/system dynamics model with expertise teaching and leading groups in
the use of systems/thinking/system dynamics. The person should also have experience facilitating groups and
leading group model building sessions. If the goal of the project is to develop a simulation model, it is expected
that the modeler/facilitator also be an expert modeler and able to anticipate and address the variety issues that
can arise in data and modeling.
Modeler: Primary responsibility for building the system dynamics causal maps, models, and simulations with expertise in
system dynamics modeling and software (Vensim, IThink/Stella, etc.), formulating and entering equations,
testing and analyzing the model, and running simulations for answer policy questions.
Participants: Primary responsibility for contributing substantive and local expertise to the modeling sessions and effort.
The participant plays a key role throughout the sessions in helping to develop problem definitions; identify
variables of interests, major stocks and flows, defining; suggesting potential data sources for the model; and,
generating policies for intervening in the system.
Process Coach: Primary responsibility for observing the group process with attention to how participants are
experiencing the session. This role requires someone who is able to reflect on the group process and accurately
identify what is happening for participants based on observing their behavior and language. The process coach
also plays an evaluation role and helps provide accurate feedback to the core modeling team about how the
Appendix 21
sessions are going. The process coach should be noticing when group dynamics begin to interfere with the
process and identify potential solutions.
Recorder: Primary responsibility for taking detailed notes during the modeling session. This person listens carefully to
participants and writes downs the words, definitions, and terminology they use to describe causal relationships,
variables, and structures, as well as comments and questions asked. After the session, the recorder takes part in
consolidating notes and materials from the modeling session to ensure that the model produced captures the
full richness of the participants’ thoughts and conversations. The recorder should have sufficient training in
system dynamics to identify causal structures and stock-flow distinctions, strong note taking skills, and ability to
integrate their notes from the modeling session into the final model.
Reflector: Primary responsibility for helping the group reflect on what they have done so far and recognize the
issues/insights that have been developed during the modeling. This role requires someone who is familiar and
comfortable with the language of system dynamics (e.g. can point out reference modes, stocks and flows that
were mentioned, etc.) and has strong listening skills, especially in accurately paraphrasing participants’
comments in their own words. The lead recorder is the person who ensures that all materials produced during
the session are archived and made available to members of the team. The lead recorder also types up notes that
summarize each modeling session and takes part in training other recorders on the team.
Time Keeper: Primary responsibility for managing the time of the group model building session, keeping the group on
schedule by starting and ending on time and taking breaks, and ensuring that the overall structure of the session
is predictable. When there is a need to adjust the schedule, it is the time keeper’s responsibility to become
aware of the issues and help negotiate a solution to end on time. It is overall very important to start and end on
time as much as possible.
Meeting Convener: Primary responsibility for starting the session, introducing participants to the exercise, making sure
that participants understand the purpose of the exercise within the context of their organization or community,
and introducing the facilitators.
Meeting Closer: Primary responsibility for bringing the session to close,
22
Appendix E: Script Template
Description: (1-2 sentence brief overview)
(Delete the bullets below that do not apply)
¢ Framing the problem
¢ Initiating mapping
Purpose ¢ Eliciting variables
2 * Deciding the reference modes for the study
script: “cae
¢ Eliciting feedback loops
¢ Eliciting stocks
ra
(Select the primary nature of the group task)
Primary * Divergent: activity designed to produce an array of different ideas and interpretations
nature of ¢ Convergent: activity designed to clustering and categorizing ideas and interpretations.
group task: ¢ Evaluative: activity designed to rank and choose between options and ideas
¢ Presentation: activity designed to present information
Preparation time:
Time: Time required to complete steps in script:
Follow up time:
* (e.g. markers, overhead projector, flip chart)
Materials: :
.
* (e.g. behavior over time graphs, concept model, or “none” if this is a starter script)
Inputs: .
Outputs from
this script:
¢ List specific products such as BOTG, system maps, etc and how these products will be used in
the context of the whole project. Deliverables are on physical products
¢ Interim outputs or products of primary interest to modeler
* Deliverables of interest to group
Roles:
¢ (e.g. Facilitator /elicitor- expert in SD)
People in the
room:
* (list of people who should be in the room, e.g., “gatekeeper”, “modeler”, “clients”)
2. (Detailed how-to’s explaining sequence of actions and who does them)
3.
Steps: 4.
5.
Evaluation (How do you know that the script has been successful? E.g. behavioral changes of participants,
criteria: learning goals achieved)
Authors: (First and last name of persons who wrote or created the script, e.g., “Jane Smith
(smith@gmail.com) March 2, 2010”)
History: (This can include previous scripts, articles, other types of small group exercises, etc. The history
23
should provide a name and date citation, and retain the entire history of the script, not just the
previous version. )
Revisions: (Briefly describe what changes have been made between this version and earlier versions)
(List any publications or references to additional documentation using this script and cited in the
history of the script. For example, if this script is based on another script that was described in peer
References:
reviewed research, then mention this under the “History” section with an author/year citation, and
provide the full reference here in the references section.)
