Community Based System Dynamics

Peter S.
Hovmand
Community
Based
System
Dynamics
Community Based System Dynamics
Peter S. Hovmand
Community Based System

Dynamics
Peter S. Hovmand
George Warren Brown School of Social Work
Washington University
St. Louis, MO, USA
ISBN 978-1-4614-8762-3 ISBN 978-1-4614-8763-0 (eBook)

DOI 10.1007/978-1-4614-8763-0
Springer New York Heidelberg Dordrecht London
Library of Congress Control Number: 2013949143
© Springer Science+Business Media New York 2014

This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of
the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation,
broadcasting, reproduction on microfilms or in any other physical way, and transmission or information
storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology
now known or hereafter developed. Exempted from this legal reservation are brief excerpts in connection
with reviews or scholarly analysis or material supplied specifically for the purpose of being entered and
executed on a computer system, for exclusive use by the purchaser of the work. Duplication of this
publication or parts thereof is permitted only under the provisions of the Copyright Law of the Publisher’s
location, in its current version, and permission for use must always be obtained from Springer.
Permissions for use may be obtained through RightsLink at the Copyright Clearance Center. Violations
are liable to prosecution under the respective Copyright Law.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication
does not imply, even in the absence of a specific statement, that such names are exempt from the relevant
protective laws and regulations and therefore free for general use.
While the advice and information in this book are believed to be true and accurate at the date of
publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for
any errors or omissions that may be made. The publisher makes no warranty, express or implied, with
respect to the material contained herein.
Printed on acid-free paper
Springer is part of Springer Science+Business Media (www.springer.com)

Preface
This book is about describing community-based system dynamics (CBSD), an

approach to doing system dynamics in community settings that has evolved over the
last several years from the work we are doing in the Brown School Social System
Design Lab at Washington University in St. Louis. As interest in these methods has
grown around the world, there has been an increasing demand for resources that
people interested in CBSD can draw on as they move forward in their own initia-
tives in communities.
Among the organizations and communities I have worked over the last 4 years in
developing CBSD, three organizations deserve special mention, for they and the
people they work with have taken risks and informed the methods: the Foundation
for Ecology and Security (FES) in India led by Jagdeesh Rao, West End Mount
Carmel Full Gospel Baptist Church in the West End neighborhood in St.
Louis led by Bishop George White Jr., and the work in Ritenour High School in St.
Louis led by principal Tony Robinson and assistant superintendent Mary Scheetz.
FES works with more than 4,200 villages spread across 7 states of India and is
involved in restoring over half a million acres of common land and in advocating
for better policy and programmatic action for the restoration and conservation of the
commons in the country. For their work, FES was the first recipient of the Elinor
Ostrom International Award on Collective Governance of the Commons for the year
2013. My colleague, collaborator, and dear friend Gautam Yadama introduced me
to Jagdeesh Rao in 2008 as he passed through St. Louis on a visit. Peter Senge’s
book, The Fifth Discipline, had made a deep impression and impacted how FES
operates in seeing people and natural resources as a system, and Jagdeesh was keen
to see how FES could use the methods of system dynamics.
Our first pilot of this approach was in August 2009 and based in a small village
of about 60 households in Boyapalle, Andhra Pradesh, a 3-h drive east from
Bangalore. Gautam and I had already conducted a workshop in the prior year intro-
ducing system dynamics to FES staff and a group of local farmers they were already
working with. Now, the goal was to see if FES could use the tools to engage a new
community that they did not have a preexisting relationship with.
v
vi Preface
Since then, Gautam and I have conducted many workshops in India in collaborations
with colleagues from FES, the Tata Institute of Social Sciences, Indian Institute for
Technology in Bombay, and PRAYAS based in Pune. The ongoing work with the
Andhra Pradesh cell led by Venkat Dyda is now the home of our annual System
Dynamics Institute in India where students from the Brown School, staff from FES,
and students and faculty from Indian institutions work in transdisciplinary teams to
build system dynamics models with communities on watershed development. These
institutes have been a major driver of innovation for the Social System Design Lab,
our community-based work, and teaching of graduate courses in St. Louis at the
Brown School. Jagdeesh Rao has through many evening conversations never failed
to challenge me to push the approach and description further and was the first to
really call out that what we were trying to do was more than just system dynamics
given the emphasis in our work on advancing social justice.
The West End Mount Carmel Full Gospel Baptist Church FGB serves an urban
neighborhood in St. Louis of about 9,500 residents and larger community and is
located just northeast of Washington University in St. Louis where the Social
System Design Lab is now located. The work in the West End has been a three-way
collaboration between the Bishop George White, the Social System Design Lab,
and Laura Brennan and her team at Transtria, LLC, also based in St. Louis. The
Special Community Workgroup (SCW), the name of the core modeling team that
has been meeting regularly since September 2010, leads this work.
I first met George White through an introduction by Terry Weiss. George and
Terry tell a story about how they had been eating dinner in a local restaurant and
noticing the prevalence of obesity. Terry had heard a talk that Laura had given in
St. Louis on social determinants and health and approached her afterwards to see
what could be done.
Laura and I are part of the original National Collaborative on Childhood Obesity
Research (NCCOR) Envision Comparative Modeling (CompMod) network in a
project that is sponsored by the National Institutes of Health (NIH) Office of
Behavioral Social Science Research (HHSN276201200027C). Patty Mabry, a
champion for advancing systems science to advance population health, is the Senior
Advisor and Acting Deputy Director of OBSSR and codirector of Envision (with
Regina Bures, Eunice Kennedy Shriver National Institute on Child Health and
Human Development, NICHD). Patty has also been the codirector of the Institutes
on Systems Science and Health with Bobby Milstein. Patty introduced Laura and
me and encouraged us to submit a bid for a project to develop a system dynamics
model on childhood obesity. Along the way, Patty meeting with colleagues in the
Envision network provided a way to understand the value of what we were doing,
where the gaps were, and in what directions to push the social innovations further
and connected this work globally in collaboration with Steve Allender and Boyd
Swinburn at the World Health Organization Collaborating Centre for Obesity
Prevention at Deakin University in Victoria, Australia.
While the SCW that has guided this work over the last several years ebbed and
flowed in membership, several members deserve special mention for the role they
have played over the years. Jenny Manuel has been with the group from the beginning
Preface vii
and attended nearly every meeting. She likes to ask questions and a champion of the
community and developing principles for collaboration. Marie Coleman, who passed
away last year, did not let us hide behind the equations and pushed us to improve the
model in ways we would have otherwise missed. Artis Porter participated in a ses-
sion, joined the SCW and several weeks later stood in front of the room as a commu-
nity facilitator opening up the session. Sylvester Idleburg brought his knowledge of
the community and gangs into the model along with an enthusiasm and outlook on life
that inspires us all. Leonard Scruggs, retired from Boeing, knows about using models,
design, and getting on with things. And of course, George White, who has not only
opened up his church and community but also quickly picked up the idea of models,
feedback, and system dynamics and brought them into the community through his
Sunday sermons, writing, and presentations including a session at the 2011 Institute
on Systems Science and Health in Pittsburg.
Ritenour High School is a large urban high school in St. Louis with approximately
2,000 students in a school district that has over the last 5 years been committed to the
vision of spreading systems thinking throughout the entire school district, from kin-
dergarten through high school. Paul Newton, a system dynamics colleague at Boeing
in Seattle, introduced me to Mary Scheetz in the fall of 2008. Mary Scheetz is well
known within the field of systems thinking in schools having been introduced to sys-
tem dynamics through Gordon Brown—Jay Forrester’s teacher and mentor at MIT—
in the mid-1980s. Mary has been a passionate leader and promoter of systems thinking
in schools through her work in Tucson, the Waters Foundation, and eventually
Ritenour School District (RSD) as an assistant superintendent.
When the Social System Design Lab was founded in 2009, one of the underlying
principles was a commitment to education in system dynamics/systems thinking
across the lifespan including K-12 education and an explicit relationship with RSD.
This principle was inherently practical for the Social System Design Lab. With
scarce resources, we could invest 4 years in training a doctoral student and then see
them graduate, or we could invest 4 years in training high school students and see
them go to college, some of whom might stay in the St. Louis area and become part
of our resource pool for doing system dynamics research.
I first met Tony Robinson, principal of Ritenour High School, in the spring of
2010 during the first year of the Social System Design Lab, when Mary and Tony
brought 15 students from the Safe School Ambassador’s program to visit the lab and
participant in a 3-h demonstration of group model building. Timothy Hower, Krista
Chalise, and I led the students through a sequence of group model building scripts.
The causal loop diagram contained variables about getting in fights, boyfriend–
girlfriend drama, teen pregnancy, tension, and school participation.
Mary tells the story of a student being in awe of the causal loop diagram of the
situation they just described, the power of that student coming up to the whiteboard
to take the marker and edit the diagram, and the impact that had on the students and
their learning of system dynamics. That was a pivotal moment when we realized we
could unobtrusively teach system dynamics using group model building. Several
weeks later in a second session at Ritenour High School, Krista asked them what
kinds of conversations they had been having about the model.
viii Preface
Cassandra explained how she had intervened with a friend, retelling us how she
has had laid out a long casual sequence of what would happen if her friend did what
she was contemplating. It did not matter whether or not the model was “right” in an
objective sense; all that mattered was that she was able to use the diagram to reason
longer than her friend to stop the behavior. At the Systems Thinking in Schools
Institute in St. Louis several months later, Ayden, one of Tony’s students, led a
group of adults through the exercises we had used in the first workshop. We joked
that if we had known they would be doing that, we would have given them the
scripts, a practice that we have since adopted.
Over the years, we did more workshops including a one-day group model build-
ing workshop led by Ayden and Lorena, another of Tony’s students. Some of the
students have now graduated and gone to college in the St. Louis area, while some
of our very best students in the Social System Design Lab have decided to go into
K-12 education. Innovations that students from RHS have codeveloped are spread-
ing to other parts of St. Louis, the USA, and Canada, and the rest of the world
including India, China, Mesoamerica, and Australia.
I have learned and changed much in the course of this work and developing
CBSD and see the communities and their members as my teachers. They have taken
risks and invested in a process that did not have a name when we started. In an effort
to help sustain the work in these communities, my portion of the proceeds from this
book will be divided between FES, the West End Mount Carmel Full Gospel Baptist
Church, and Ritenour School District. Even small changes embedded in feedback
loops that accumulate can have powerful effects.
This book is for anyone interested in helping to make communities a better place
and advance social justice using system dynamics and group model building. My
hope is that the social innovation continues to improve the methods and the lives of
the people in communities around the world, giving people a new way to view situ-
ations, empower them to use the methods in their own way, and draw on the rigor
that system dynamics has to offer in thinking about feedback systems from an
endogenous perspective.
St. Louis, MO, USA Peter S. Hovmand

Acknowledgements
Work that is community based is embedded in relationships, and many have

contributed in small ways and large ideas that reflected in this book. I always enjoy
reading the acknowledgements in books because they help me understand the rela-
tionships and context. They tell me a lot about who the person is and how the ideas
emerged.
The methods described here were developed through a variety of research proj-
ects funded by Centers for Disease Control and Prevention through the Brown
School Violence and Injury Prevention Center (1R49CE001510); Center for New
Institutional Social Sciences (CNISS); National Institutes of Health, Office of
Behavioral Social Science Research (HHSN276201200027C); International Center
for Advanced Renewable Energy and Sustainability (I-CARES); St. Louis Federal
Reserve Bank; Robert Wood Johnson Foundation; National Cancer Institute (NCI
U54CA155496); National Science Foundation (SES-0724577); and the Substance
Abuse Mental Health Services Administration Mental Health Transformation State
Incentive Grant (SM57474-01).
This work would not have been possible without leaders such as Jagdeesh Rao,
Bishop George White, and Mary Scheetz or terrific colleagues at Washington
University in St. Louis. A special thanks goes out to my collaborators on projects
who saw the potential and believed in the approach, including Gautam Yadama,
Monica Matthews (now at St. Louis University), Melissa Jonson-Reid, Doug Luke,
Matt Kreuter, Enola Proctor, Ross Brownson, Sarah Gehlert, Michael Sheridan,
David Gillespie, Molly Tovar, Eddie Lawlor, and Shanti Khinduka in the Brown
School; Jody O’Sullivan and Pratim Biswas in engineering; and Graham Colditz
and Ken Carson in the School of Medicine.
Nor would any of this have been possible without the patience and thoughtful
comments of Laura Brennan at Transtria, LLC, both as a scholar and a leader of an
organization. I also count myself fortunate to have the opportunity to work with
innovators such as Kurt Stange and Jim Deering who have unobtrusively taught me
the most about developing effective transdisciplinary teams.
ix
x Acknowledgements
This work is situated within a rich discussion on system dynamics, group model
building, and using these tools to better society that would not exist without gener-
ous and patient colleagues in the System Dynamics Society, including David Lane,
David Ford, Laura Black, Ralph Levine, David Lounsbury, Elke Huseman, Etiënne
Rouwette Roberta Spencer, Nate Osgood, Kristen Hasmiller, Patty Mabry, Bobby
Milstein, Jack Homer, Brad Morrison, Bob Eberlein, John Morecroft, Peter Warrian,
Jim Thompson, John Sterman, Krystyna Stave, Hazhir Rahmandad, David Matchar,
and many others who have helped me understand system dynamics and the context
of what I am trying to do better, and, of course, Jay W. Forrester, the founder the
field of system dynamics, and George Richardson, David Andersen, and Jac Vennix
for their pioneering work in group model building.
Among these, I owe a special thanks to people who helped me clarify key points
at the last stages of the book including Laura Black, George Richardson, David
Andersen, Jack Homer, Gautam Yadama, and Nishesh Chalise. Their suggestions
and clarifications were of great help.
The perspective I work from owes a debt to some great teachers over the years:
Maurice Aberdeen who created a view of electrical engineering that was much
broader than electrical circuits; Pam Gorkin who inspired an interest in mathematics;
Richard Flemming who introduced me to Wittgenstein and philosophy of language
and mathematics; Mary Devereaux who introduced me to collaborative performance
art and choreography of Einstein on the Beach, which shaped my approach to cho-
reographing group model building workshops; and Teresa Amott and John Kendrick
who introduced me to radical scholarship in sociology and economics; Diane
Levande who provided the space and encouragement to pursue what must at the time
have seemed ambitious goals to say the least; and Ralph Levine who introduced me
to system dynamics at the urging of David Lounsbury. I own a great debt to my
teachers in philosophy—Marilyn Frye, Cressida Heyes, and Bill Lawson—who
talked and reviewed many versions of the philosophical arguments in their courses
that underpin much of this work. Though I don’t claim to be advancing philosophy
here, I do think that this is a good result in putting these ideas into practice.
Of particular note are a few people who opened up intellectual avenues that I
would otherwise likely have missed. My understanding of mental models comes
from a conversation thread that started with Cressida Heyes asking a pointed ques-
tion and talking with David Ford and Jay Forrester at the Atlanta conference.
My views of categories, power, the use of language, and in particular speech acts
and ways to counter them were influenced in conversations with Marilyn Frye and
a community of practice in male violence prevention in Michigan that included
Holly Rosen, Chris Sullivan, David Garvin, and Mike Jackson. Holly Rosen, David
Garvin, and Mike Jackson in particular deserve a special note. Holly is an inspira-
tion to many and encouraged and supported me as a supervisor who created a space
for me to develop and implement a very successful male violence prevention work-
shop based on a system dynamics simulation model. David Garvin and Mike
Jackson taught me what I know today about facilitating groups, privilege, and
accountability. This led me to a deeper understanding of Wittgenstein’s notion of
language games and Austin’s notion of doing things with words.
Acknowledgements xi
The relevance of this to system dynamics only became apparent during a

lunchtime conversation with Barry Richmond at the Bergen conference. Sitting next
to Barry over a delicious lunch, I started sharing this view that was still at a formative
stage as a doctoral student and struck by the questions that Barry was asking and the
copious notes he was taking. Until that moment, I did not realize that all of this
might have some relevance within system dynamics.
Bill Lawson’s work in ethics and political philosophy, Carl Taylor’s work on
gangs in Detroit, and Ralph Levine’s work on urban dynamics in Michigan com-
munity that increasingly relied on prisons as the major employer brought together a
different set of sensibilities around the urban model, while work with Susan
Grettenberger on HIV/AIDS services and the role of churches provided a founda-
tion for future applications of system dynamics in social work. Lori Post introduced
me to demography and prevention in public health and created opportunities for
violence prevention research including small grant from the Centers for Disease
Control and Prevention to develop a prototype Community Assessment Tool, a
Web-based interactive learning environment for community violence prevention
before these tools were widely available.
Among my colleagues in the System Dynamics Society, some have been curious
and open to collaborations and helped me learn the craft of building models and
supported me over the years. Without them, I do not know if I would have stayed in
system dynamics. I now consider them all friends and colleagues. I met Paul Newton
at the Quebec conference, and at the time, I couldn’t understand how or why some-
one might be so interested in what I was doing. He has persisted in being an inspira-
tion as a person and system dynamicists promoting the field. At the Bergen
conference where I first presented my work as a doctoral student on batterer inter-
vention programs as part of a coordinated community response, Laura Black came
up to me after my first plenary and encouraged me to continue this work. It may
have been a simple act, but that made all the difference after long week of conversa-
tions about male violence. Anyone who has done outreach to change attitudes on
male violence will know what I am talking about.
David Ford is an amazing collaborator and mentor, and my belief in the impor-
tance of people being open to the training of students at other institutions is a direct
consequence of his generosity. David Lane and Elke Huseman have been advocates
and sources of encouragement and created an intellectual space in their own work
on system dynamics and social theory. Conversations with Peter Warrian in St. Gallen
and St. Louis on placed-based innovation gave me language and a framework to
understand social innovation and what we were trying to do in the Social System
Design Lab.
Jeanine Arrighi, Diane McFarland, Joe Yancey, Janeen McGee, Jim Braun, and
Greg Echele have all been champions over the years for applying system dynamics
and group model building in their organizations.
None of this would have been possible without the staff and students of the
Social System Design Lab who took a risk in being involved with a start-up. I am
forever in debt to Timothy Hower, my coconspirator in the founding the lab, Krista
Chalise who is an inspiration in her enthusiasm, Erin Leaver Schmidt who was there
xii Acknowledgements
from before the beginning, and Lauren Gulbas who advanced the methods as an
anthropologist. Barbara Levin and David Gillespie were integral in the first years of
the lab as part of our NSF study. They continued to push on with honest feedback,
hard work, and innovation. They have created the lab culture we enjoy today, and
they include Annalise Calhoun, Nishesh Chalise, Jill Kuhlburg, Dan Conner, Eric
Steins, Colleen Kinneen, Amy Schneider, Margaret Hower, Andrew Frangos, and
Alison Kraus, who now help lead the lab as program managers. More recently,
Nasim Sabounchi and Nancy Mueller have joined the lab and continue the trend of
developing fresh ideas. Together, Alison, Nasim, and Nancy have brought a new
level of enthusiasm, organization, and performance to the lab that has made it pos-
sible for me to complete this book with so much going on.
Morgan Ryan, my editor at Springer, provided the support and encouragement
that I needed to finish.
Among doctoral students, several have contributed directly to this work through
their questions and research, including Nishesh Chalise who has been with me
through every twist and turn in methodology over the last 4 years and provided
invaluable feedback on methods for model formulation, Jill Kuhlburg who has
worked with Gautam and me at the SD Winter Institutes in India and helped bring
the ideas back to St. Louis, Jill who has helped work out the basics of team based
modeling as it evolved in our SD Winter Institutes, and Amanda Lavallee at the
University of Saskatchewan who has been an integral part of our collaboration with
the Buder Center for American Indian Studies at the Brown School through her own
work with Métis communities in Canada.
I owe a special note of appreciation to my friends and family, who have been
with me from the start when the ideas were in wild disarray and patiently supported
me and struggled to understand and helped clarify what I was trying to do. Melissa
White and Stephen Jefferson have been there always. My parents and brother Lars
always believed even when the twists and turns took some leaps of faith. And most
of all, Charlene and Eyvind’s support and encouragement to complete this book and
being there on the journey made it happen: Charlene bore with me from the begin-
ning, and my son Eyvind, who picked up the language system dynamics at an early
age of 5 and corrected me, “You know [dad], you think it’s the models that are
important, but it’s what you do with them that matters.”
Contents
1 Introduction to Community-Based System Dynamics .......................... 1

Why Community-Based System Dynamics? .............................................. 1
Mental Models ........................................................................................ 1
Causal Maps and Formal Models ........................................................... 2
Group Model Building ............................................................................ 5
Defining Community .................................................................................. 7
Complex Problems ...................................................................................... 8
Participation ................................................................................................ 10
Community Based....................................................................................... 11
Conclusion .................................................................................................. 14
References ................................................................................................... 15
2 Group Model Building and Community-Based System
Dynamics Process ...................................................................................... 17
Group Model Building ................................................................................ 17
Approaches to Group Model Building........................................................ 18
Teamwork.................................................................................................... 20
Boundary Objects........................................................................................ 22
Scripts ......................................................................................................... 23
Participants .................................................................................................. 25
Three Stages of a CBSD Project ................................................................. 26
Problem Scoping and Identification ........................................................ 26
Core Modeling Team Planning and Capacity Building .......................... 27
Group Model Building Workshops ......................................................... 28
Evaluation, Reporting, and Next Steps ....................................................... 28
Conclusion .................................................................................................. 29
References ................................................................................................... 29
3 Engaging Communities ............................................................................ 31
Engaging Communities ............................................................................... 31
Initial Community Participants, Gatekeepers,
and Organizations During Engagement .................................................. 33
xiii
xiv Contents
The First Audition ................................................................................... 35

Engaging with the Graphs over Time Script ............................................... 35
Engaging with the Concept Model Script ................................................... 36
Conclusion .................................................................................................. 37
References ................................................................................................... 37
4 Problem Scoping and Identification ........................................................ 39
Initial Conversations ................................................................................... 39
What Is the Problem? .................................................................................. 40
Is It Dynamic? ............................................................................................. 42
What Kind of Problem Is It? ....................................................................... 44
Does It Involve Feedback? .......................................................................... 48
What Kinds of Insights Would Help Solve the Problem? ........................... 48
What Would Be the Added Value of a Model? ........................................... 50
Modeling Project Description ..................................................................... 50
Reasons to Discontinue at This Stage ......................................................... 52
Conclusion .................................................................................................. 53
References ................................................................................................... 53
5 Core Modeling Team Planning, Training, and Capacity Building ....... 55
Forming a Core Modeling Team ................................................................. 55
Introducing Core Modeling Team to System Dynamics
and Group Model Building Process ............................................................ 55
Developing a Common Language............................................................... 56
Developing Process Maps ........................................................................... 56
Developing an Agenda ................................................................................ 58
Adapting and Developing Group Building Scripts ..................................... 59
Planning the Training .................................................................................. 59
Rehearsal ..................................................................................................... 59
Conclusion .................................................................................................. 60
Reference .................................................................................................... 60
6 Group Model Building Workshop and Facilitation .............................. 61
Setting the Frame ........................................................................................ 61
Preparing the Physical Setting and Layout ................................................. 62
Setup and Takedown ................................................................................... 63
Facilitating Group Process of Managing Boundary Objects ...................... 63
Guiding Principle ........................................................................................ 68
Facilitation .................................................................................................. 68
General Facilitation Tips ......................................................................... 70
Listen and Report Back, Edit with Transformation ................................ 71
Work as a Team ....................................................................................... 72
Improvisation .......................................................................................... 72
Recorders .................................................................................................... 73
Contents xv
Consolidating Deliverables ......................................................................... 74

Debriefing and Reflection ........................................................................... 75
Conclusion .................................................................................................. 76
References ................................................................................................... 76
7 Model Refinement, Integration, Formulation, and Analysis ............... 77
Participation Versus Modeling .................................................................... 77
The Role of the Expert Modeler ................................................................. 78
Why Model?................................................................................................ 80
Model Specification and Ownership ........................................................... 82
Model Review and Cleanup ........................................................................ 83
Integration ................................................................................................... 84
Simplification .............................................................................................. 86
Formulation and Testing ............................................................................. 87
Analysis....................................................................................................... 88
Conclusion .................................................................................................. 89
References ................................................................................................... 89
8 Implementation and Evaluation .............................................................. 91
Implementation ........................................................................................... 91
Evaluation ................................................................................................... 93
Conclusion .................................................................................................. 94
References ................................................................................................... 94
9 Conclusion ................................................................................................. 97
A First Step ................................................................................................. 97
Readiness .................................................................................................... 98
What’s Next? ............................................................................................... 98
Index ................................................................................................................. 101

Chapter 1
Introduction to Community-Based System
Dynamics
Logical pictures can depict the world.

(Wittgenstein 1974, 10)
Today’s knowledge about something is not necessarily the same
tomorrow. Knowledge is changed to the extent that reality also
moves and changes. Then theory also does the same. It’s not
something stabilized, immobilized.
(Horton and Freire 1990, 101)
One way to focus on this problem is to discover that we have no
conception of objectivity that enables us to distinguish the
scientifically ‘best descriptions and explanations’ from those
that fit most closely (intentionally or not) with the assumptions
that elites in the West do not want critically examined.
(Harding 1991, 97)
Why Community-Based System Dynamics?
Community-based system dynamics (CBSD) is a participatory method for involving

communities in the process of understanding and changing systems from the endog-
enous or feedback perspective of system dynamics (Richardson 2011; Sterman
2000; Forrester 1990). In system dynamics, informal causal maps and formal mod-
els that can be simulated on a computer are used to “uncover and understand endog-
enous sources of system behavior” (Richardson 2011, 241) with the goal of solving
problems by improving the mental models we use to perceive the system and act.
Mental Models
A mental model of a dynamic system is a cognitive representation of the real system

(Doyle and Ford 1998). We use mental models every day from the time we get up to
the time we fall asleep, at home and at work or school. As humans, we rely on men-
tal models to solve a wide variety of problems, from organizing a meal during fes-
tival to developing a global strategy for preventing chronic disease. When things are
P.S. Hovmand, Community Based System Dynamics, DOI 10.1007/978-1-4614-8763-0_1, 1

2 1 Introduction to Community-Based System Dynamics
going well, we generally have no reason to worry about our mental models, and
often our mental models are sufficient for managing the situation at hand.
However, there are times when the problems we’re experiencing are a consequence
of flawed mental models. In these situations, we are making decisions relying on the
wrong set of assumptions and inferences, which are in turn not solving problems and
often make matters worse (Dörner 1997; Senge 1990). When this happens in a system
where there is feedback, that is, where the consequences of the actions “feed back” to
influence the conditions we’re responding to, the situation can be disastrous.
In commercial fishing, a declining fish stock can lead to declining revenue for the
fishing fleet and a tendency to expand fleets. This expansion accelerates the rate that fish
are caught and the decline, leading to even more pressure to expand fleets. The pattern
continues until regulations put a moratorium on commercial fishing or ultimately, there
are no more fish. The causal chain that drives the decline of the fish stock is a reinforcing
feedback loop, whereas the prevailing logic of commercial fishers, “Expand fleets to
increase revenue,” ignores feedback. The problem from a feedback perspective is that
commercial fishers are trying to manage their revenues using a mental model that
excludes feedback when the dynamics of the real system are being driven by feedback.
From afar, it can sometimes seem obvious what one should do, but research con-
sistently points out that we routinely make these types of mistakes because we have
a hard time recognizing feedback in a system, underestimate the significance of
delays between causes and effects, and generally have a difficult time drawing valid
inferences about effects when there are two or more causes interacting (Sterman
2000; Dörner 1997; Moxnes 2000).
This does not mean that no one sees the system effects, but then the challenge is
often on how to reach some type of agreement about what to do when perspectives
differ. For example, there can well be someone who from a combination of experi-
ences, system thinking skills, and wisdom is able to see the system and recognize
the actions that need to happen to manage the system better. The problem for this
person, however, is that they are often in the minority and, even when they are in
charge, may have a difficult time communicating and persuading others to follow a
path conflicting with prevailing mental models of the situation.
Causal Maps and Formal Models
In system dynamics, informal causal maps and formal models are used to make our
mental models explicit and test hypotheses about the logical implications of our
assumptions on system behavior using computer simulation. Examples of informal
causal maps include causal loop diagrams and stock and flow diagrams of dynamic
systems. Causal loop diagrams (CLDs) such as those shown in Fig. 1.1 are fre-
quently used to show the feedback loops in a system.
In CLDs, the arrows represent hypothesized causal relationships between variables.
The basis of these causal relationships can vary from conjecture to evidence supported
by rigorous research. The plus and minus signs indicate the direction of influence.
Why Community-Based System Dynamics? 3
Administering
– dosages
Vaccine
dosages
B1
+
+
– Vaccinating Vaccinated children

children
+
Unvaccinated B2
Remaining children
time + +
+
B3
+
Number of staff –
needed Trained Staff
+
staff B4 turnover
+
R1
Training + +
staff
Fig. 1.1 Example of a causal loop diagram
Plus signs mean that increasing the cause variable increases or adds to the effect
variable with everything else being held constant. By the same logic, decreasing
the cause variable decreases or subtracts from the effect variable with everything
else being held constant. In Fig. 1.1, for example, the link from vaccine dosages to
vaccinating children is positive because increasing the vaccine dosages will increase
the rate of vaccinating children with everything else held constant, and decreasing
vaccine dosages will slow the rate of vaccinating children with everything else held
constant.
In contrast, minus signs mean that increasing the cause variable decreases or
subtracts from the effect variable with everything else held constant, and decreasing
the cause variable increases or adds to the effect variable with everything else being
held constant. For example, in Fig. 1.1, increasing the rate of administering dosages
will decrease or subtract from the available vaccine dosages with everything else
held constant, while decreasing administering dosages will increase the available
vaccine dosages with everything else held constant.
In CLDs, feedback loops are typically labeled as either balancing or reinforcing
with balancing feedback loops given “B” prefixes and reinforcing loops given “R”
prefixes. For example, B1 identifies the balancing feedback loop where increasing
the rate of vaccinating children increases the rate of administering dosages which in
turn decreases the available dosages, and this “feeds back” to limit the rate of
vaccinating children. Likewise, R1 identifies a reinforcing loop where increasing
Vaccine
dosages Administering
dosages
+
Dosages per
+ child
-
<Time>
Unvaccinated Vaccinated
- children Vaccinating
children
+ children
Remaining time
+ +
-
- Children per staff
Number of staff per year
needed
+
Trained staff
Training Staff
staff turnover
- + +
Avg time to hire +
and train staff Turnover
fraction
Trainees per
trainer per year
Fig. 1.2 Example of a stock and flow diagram
training of staff leads to more staff, which in turn facilitates a faster rate of recruit-
ing and training more staff.
Stock and flow diagrams (SFDs) are also used to represent systems. An example
of the childhood vaccination system is shown in Fig. 1.2 as a stock and flow dia-
grams. In SFDs, accumulations or stocks are represented as boxes, while flows or
rates affecting the stocks are represented as “pipes” or with double lines with tri-
angles representing the valves controlling the rates. The clouds at the beginning and
end of the flows or “pipes” represent infinite sources and sinks.
Stock and flow diagrams have the advantage of explicitly representing the accu-
mulations or stocks in a system but often make it somewhat hard to see the feedback
loops. However, stock and flow diagrams have a closer correspondence to the under-
lying mathematical representation in a computer model and are therefore generally
easier to translate into equations that can be simulated on a computer.
Why Community-Based System Dynamics? 5
The main role of computer simulation in system dynamics is to test hypotheses

about the relationships between the system structure and system behavior. A run-
ning simulation model demonstrates what the logical implications of the model are.
Because such models are rich enough in their structure to generate dynamic com-
plexity, simulation models can be viewed as logically entailing a potentially large
set of hypotheses that can subsequently be compared against reality (Black 1962).
Informal causal maps and formal simulation models provide a means to make
our mental models more explicit and test assumptions. Often the process of devel-
oping the model leads to counterintuitive insights about the structure and behavior
of a system, which in turn leads to recommendations that often challenge conven-
tional wisdom and therefore pose a challenge in terms of persuading decision mak-
ers to act based on these assumptions.
Group Model Building
In describing the motivation for her transition from biophysicist to journalist, Donella
Meadows (1991) tells the story of watching in frustration Jay W. Forrester, the founder
of the field of system dynamics, trying to explain and persuade viewers on a Boston
television show the policy implications from the Urban Dynamics Model (Forrester
1969). Other examples include the controversy surrounding the Club of Rome and the
World Model (Meadows et al. 2004), where a large secondary literature emerged that
misinterpreted both the purpose and conclusions from the model.
Today, we have the benefit of looking at these models with much more historical
data available and confidence in their policy recommendations, but we have in the
meantime lost 20–30 years of opportunity for making the policy changes that would
address the underlying the issues.1
Forrester himself has chastised the view that the problem of translating system
insights into implementation of solutions as one of communicating more effectively
and persuasively with decision makers:
One hears repeatedly the question of how we in system dynamics might reach “decision
makers”. With respect to the important questions, there are no decision makers. Those at the
top of a hierarchy only appear to have influence. They can act on small questions and small
deviations from current practice, but they are subservient to the constituencies that support
them. This is true in both government and in corporations. The big issues cannot be dealt
with in the realm of small decisions. If you want to nudge a small change in government,
you can apply systems thinking logic, or draw a few causal loop diagrams, or hire a lobby-
ist, or bribe the right people. However, solutions to the most important sources of social
discontent require reversing cherished policies that are causing the trouble. There are no
decision makers with the power and courage to reverse ingrained policies that would be
directly contrary to public expectations. Before one can hope to influence government, one
must build the public constituency to support policy reversals. (Forrester 2007, 361)
1
It is important to note that this lag between results and policy implementation is by no means
unique to system dynamics. In fact, it is common in many areas of scientific research with whole
new fields emerging such as translational science and implementation science to address this lag.
Fig. 1.3 Gautam Yadama introduces a reference mode of declining availability of fuelwood to
villagers at the start of a Foundation for Ecological Security effort to the engage villagers from
Boyapalle, Andhra Pradesh, India
One response to Meadows and Forrester comes in the form of group model
building. Group model building (GMB) is a participatory method for involving
people in a modeling process. For the most part, GMB has been applied within the
context of private organizations and government, often with a group of middle to
senior managers, all with the goal of informing a response to a problem, policy
analysis, or design of a new program or service (Rouwette et al. 2006). A limited
set of cases of GMB have occurred in community contexts (e.g., Stave 2002;
Dudley et al. 2008), but with questions arising about the level of participation in
the modeling process and to what extent people are actually involved in model
development.
CBSD emerged within the GMB discourse as an explicit attempt to involve com-
munity members in the modeling process in the spirit of Forrester’s critique of the
field. CBSD is about building the public constituency to support the policy reversals
that can address the root causes of dynamic problems from a feedback perspective.
It is about engaging communities, helping communities cocreate the models that
lead to system insights and recommendations, empowerment, and mobilizing com-
munities to advocate for and implement changes based on these insights (see
Fig. 1.3). To do this, we need to understand what it means to be a community, what
kinds of situations we are looking at where CBSD can have benefits in terms of
complex systems, and what it means for people to participate in a process to develop
informal causal maps and formal models that can be simulated on a computer.
Defining Community 7
Defining Community
There are a many ways to define the term “community” from definitions based on
geographic boundaries to loose networks of associations (Fisher and Sonn 2007).
Take, for instance, the fact that neighborhoods, small towns, metropolitan areas,
professional societies, universities, organizations, and Internet forums are all
referred to as communities. How we define “community” determines who is
involved, how the issues get framed, who the stakeholders are, how we understand
the politics and power, and even what language we use.
In social science, defining community is often a means to provide an operational
definition for a population and means to judge the appropriateness of a sampling
strategy for generalizing results. In this sense, defining community is often treated
as a scientific act. But here, by the very nature of the activity in CBSD, we need to
be conscious that defining the term “community” as well as a specific community is
a “speech act” and an act power.
A speech act is doing something with words (Austin 1962). For example, an
apology or joke is a speech act in that giving the apology or making the joke hap-
pens through the act of speaking. Including someone into a family (e.g., “You’re a
member of our family now”) is also a speech act. Likewise, membership in a com-
munity is often through speech acts (e.g., “Of course, you’re a member of our com-
munity!” or “They aren’t a member of our community even though they live here”).
What is important to recognize is that this is also an act of power, and specifically,
an assertion about who gets to determine who is in and outside a community.
Being a recognized member of a community comes with certain privileges (and
obligations), one of which is to determine access to the community by extending
and withdrawing membership (Fisher and Sonn 2007). In marginalized communi-
ties where conditions are often determined by persons outside the community, reas-
serting the right of a community to define community on its own terms is fundamental
to reclaiming control of access (Frye 1983).
While this can sometimes lead to musings about the essential membership char-
acteristics and identity politics, it is important to recognize that from a pragmatic
perspective, communities routinely define and redefine boundaries to suit different
purposes (Heyes 2000). For example, a community may draw narrow boundaries
when considering the distribution of vegetables from a community garden and broad
boundaries when discussing the potential placement of a new school or health clinic.
What is critical to recognize in CBSD is that the drawing and redrawing of boundar-
ies is a fluid process and something that is done by those within the community.
It is also important to be aware that when communities extend membership to
outsiders such as the members of the modeling team, that this is best viewed as
provisional, and more specifically conditional on the behavior of the modeling
team, in addition to coming with obligations as a provisional member of the com-
munity that is essential to establishing and maintaining trust. What this means in
practice is that membership privileges are not transitive, but obligations are.
In CBSD, we therefore begin to understand what is meant by asking those who

already have ties to the community how they define community and continually try-
ing to understand their use of the term “community” within the context of their
discussions. There is generally no best set of persons to start this process, and one
must be critical of how status and incentives to participate can distort interactions.
This requires a certain amount of self-awareness of one’s own status and privi-
lege, sensitivity to cultural diversity and how power and privilege operate within a
community, and paying attention to distinctions that community members might
draw between a definition of community imposed upon them and one that they can
extend.
For example, a rural village dependent upon a forest for their household needs
and livelihoods may feel powerless to change the behavior of commercial harvest-
ers, who see themselves as separate and unaccountable to the village. However, by
the village extending their sense of community to include some of the commercial
harvesters, the villagers make the commercial harvesters endogenous to their com-
munity and can organize to make the commercial harvesters aware and accountable
for their actions in the forest. This may not be sufficient to change the behavior in a
way that leads to a sustainable forest, but it is often a necessary precondition for
mobilizing communities and empowerment.
Ultimately, how we approach the question of defining community is process over
time that begins with how we approach and engage communities. Chapter 3 will go
into more detail about the process of engaging communities and how one develops
a team to guide the process and builds capacity to both understand definitions of
community and design and facilitate group model building sessions with
communities.
Complex Problems
From the outset, the types of concerns we are focused on in CBSD are often difficult
and complex problems. Some are difficult because they are complicated—they
involve a great many moving parts and details—while others are complex because
they involve many potential interactions and explanatory pathways.
A normal response to complex problems is to try and reduce them into smaller
components and explore more detail complexity. We see this in everyday life as
individuals try to organize their social realities through the creation of finer catego-
ries and jargon. Yet the increasing amounts of detail may ultimately add very little
to our overall understanding of a problem.
Complex system problems that have the characteristic that what makes them
hard to understand are the emergent behaviors of the parts interacting as a system.
That is, when the “sum of the whole is greater than the sum of the parts,” it means
that a system behaves in ways that could not be predicted or reduced to properties
of the individual components. When this happens, we say that the behavior of a
system emerges from the interaction of different elements. Since the interactions are
Complex Problems 9
determined by the structure of the system, we say that structure determines behavior.
This represents a subtle but profound shift in our viewpoint.
When we can understand a system by understanding its component parts and
then infer what a system will do, what matters most are strength of associations
between causes and effects. Increasing fishing will increase revenue. Increasing
studying will improve grades. Increasing access to care will improve health.
Decreasing taxes will improve the economy. Shortening commuting times will
reduce traffic. In this view of linear causality, the effects that matter are proximate
to the causes, meaning that the closer the cause is to the effect, the stronger the
effect. By the same logic, the further away one moves from the original cause, the
weaker the effect until the effect is indistinguishable from a random disturbance.
One can, using this logic, ignore the consequences of long causal chains since they
get lost in the noise. When this is the case, strength of association determines
behavior.
However, when structure determines behavior, we are saying something funda-
mentally different. Now it is the fact that there is a reinforcing feedback loop, for
example, that explains why the system behaves as it does. The power of feedback
loops is that the effects accumulate as they move around the loop. More fish caught
leads to fewer fish, which makes it more difficult to catch fish, which leads to fewer
fish being caught. Or, more births lead to larger populations, which lead to even
more births and even larger populations. When structure determines behavior, it is
less important what the actual harvest rate is or what the actual birth rate is than the
fact that it is positive and embedded within a feedback loop. Changes in the strength
of association will generally have little impact on system behavior, whereas chang-
ing the structure will.
One frequently puzzling consequence of structure determines behavior is that
the same structure can produce different types of behavior. The reinforcing feed-
back loops that produce exponential growth, for example, can also produce expo-
nential decline. So if more income leads to greater assets, which leads to higher
academic achievement, and this leads to even greater income is true as a virtuous
cycle of accumulation of wealth and educational attainment, this same structure can
also drive a vicious cycle of declining income and educational attainment. It is one
system that can produce two different system behaviors.
This notion that the same system can produce different behaviors is called
dynamic complexity and differs from the idea that systems are complicated or hard
to understand because they have many different elements, which is referred to as
detail complexity (Sterman 2000). While the fact that the number of elements and
connections in a system can be overwhelming in its detail complexity, the primary
concern of system dynamics is on understanding dynamic complexity. It is dynamic
complexity, not detail complexity, which arguably poses the greatest challenge to
understanding complex systems.
In a dynamically complex system, the same basic structure generating desirable
behaviors during one period can drive undesirable behaviors in another period. For
example, the feedback mechanisms that drive our early success in building coopera-
tion in a community can be the same feedback mechanisms that later lead to conflict
(Hovmand et al. 2009). What becomes challenging is that someone advocating for
more of the previous efforts to build cooperation is not wrong when they claim it
was effective, but now the situation has changed, and what was once the source of
success is now driving a pattern of failure.
The focus of CBSD is on understanding and solving problems that involve
dynamic complexity. It is in dynamically complex situations where understanding
the structure is essential to being able to both identify potential strategies for
improving the system and implementing the strategies in a timely manner. This
means, among other things, that one wants to first frame the issue as a dynamic
problem, that is, one that involves one or more variables changing over time. The
process for doing this in CBSD will be discussed in Chap. 3.
Participation
If people in a community are to be involved in developing informal causal maps and

formal models that can be simulated, we first need to have a clearer understanding
of what it means to participate in a modeling activity. Delineations of what is and is
not group model building rest on different views of what constitutes participation
and thereby determine whether or not a given activity fits under the heading GMB.
This also has political implications. For example, if a nongovernmental organi-
zation (NGO) or government seeks true participation to inform both the policy
design and its implementation, then the claim is that the results have some type of
true buy-in from one or more communities. A “slight of hand” can happen, however,
if the process that involves communities yields an informal causal map, but the
results used to inform policy making vis-à-vis a formal computer simulation model
are only loosely related. In this kind of situation, the community believes it has
participated and informed the policy making process as does the government or
NGO sponsor of the project. Minimally, this can lead to misinformed policies. At its
worst, it can result in the co-optation of marginalized communities and a participa-
tory process by persons seeking to reinforce a status quo at the expense of marginal-
ized communities. It is therefore essential to be clear on what we mean and how we
define participation.
There is also a tendency to view participation as static as opposed to a dynamic
process. Participation as a static concept focuses primarily on whether or not some-
one was involved at a particular point of time. So we look at the participation in a
meeting and draw a conclusion about whether or not there was true participation.
But participation can also be viewed as varying over time and a dynamic process.
Someone might be quiet in one meeting and cautiously assessing the responses of
facilitator, later speak up and get more involved, and eventually become an active
leader in the group and drive the decision making. It is this latter view of participa-
tion that is critical to CBSD because few if any communities come prepared to do
or understand system dynamics.
Community Based 11
Fig. 1.4 Students from Ritenour High School reviewing clustered graphs over time on scaling up
and sustaining systems thinking in schools in the Brown School Social System Design Lab,
Washington University, as part of the Systems Thinking in Schools Institute, St. Louis, MO
In CBSD, community participation varies over time, from being involved as a

passive source of information to active community mobilization and action (Kumar
2002). The essential point to recognize is that one wants to help design and facilitate
a community process that moves participation along this continuum. In this sense,
one is successful if participants move from being sources of information in a survey
or structure elicitation exercise to active participants in making decisions about a
model’s development. On the other hand, one would have been ineffective or failed
from a CBSD perspective if they started and ended a project with more or less at the
same level of involvement. Participation in CBSD should therefore be seen as a
process of building a community of practice around a model that empowers indi-
viduals to effectively use a model in a way that is consistent with its purpose and
limitation (Lave and Wenger 1991). Figure 1.4 shows an example of Ritenour High
School students leading a daylong workshop as part of the Systems Thinking in
Schools Institute. The students have been involved in various group model building
workshops over the years starting wtih participation in a group model building
workshop.
Community Based
It may take several projects in a community before there is a critical mass within the
community to become active in decision making around a model and use the tools for
mobilization and action. This speaks to the fact that often the goal of a group model
building project is not so much to build a model or analyze a policy as it is to increase
awareness, capacity, and motivation for a subsequent group model building project
(Rouwette et al. 2006). Some point out that how models built over the course of sev-
eral distinct projects in one community with high involvement in modeling at one
stage and less involvement in the modeling at a later stage can lead to social learning
and capital development (Stave 2010). However, this aspect of system dynamics
modeling—that modeling can happen multiple times on different topics within the
same community—is often overlooked in the group model building literature and
privileges views of learning and social capital at the level of individuals, teams, or
groups over the larger collectives such as the organizations or communities.
CBSD takes a more explicit approach to working at the community level over the
course of multiple engagements over time with different groups, with each group being
seen as distinct even when there may be a significant overlap of individuals from one
group to the next. Groups in this sense are and should be viewed as distinct because each
group starts with new goals, expectations, norms, and dynamics that emerge and have to
be managed in a group model building process. In this sense, CBSD is very much in line
with the term “group” in the phrase “group model building.”
While each group is seen as different, they are also increasingly connected in
community settings through social networks in community-based efforts. Individuals
from one project talk with others in their social networks. Over multiple projects
within the same community, stories about causal maps, models, and the group
model building experience accumulate and get transmitted to other parts of the com-
munity. Capacity and motivation develop for additional projects, but now more
focused on community and driven by community members and often motivated to
move more into formal computer simulation model building and analysis. The
insights and results from these more rigorous analyses “feed back” into other con-
versations within the community. In CBSD, participation and results from multiple
causal mapping and formal models with computer simulation within the same com-
munity coexist and reinforce insights.
This also means that the question of whether the goal in CBSD is limited to
mainly informing the conceptualization of a model versus being involved more
directly in the formulation and testing of a formal computer simulation models is
somewhat meaningless. A snapshot of any one project within CBSD would not
capture the larger context of what led up to the project, how the project participation
and results interacted with other current projects, or how the project might fit into a
longer term strategy to build one or more formal simulation models. In CBSD, there
is, over time, high community participation in all stages of building a model from
identifying the problem to conceptualization to model formulation and testing.
The central idea in CBSD is therefore recognizing that the continuity in the par-
ticipatory modeling process comes not from continuity of individual participation in
group but instead from continuity of working in the community (hence the term
“community based”2 in CBSD) and emphasis on building models (hence the fit
2
Some have characterized the approach as better described as community driven, while others
would see this fitting under the umbrella term of community-engaged research, but neither of these
emphasize the importance of basing activities in a community in a way that facilitates accumula-
Community Based 13
Fig. 1.5 Overview of the

modeling process
between CBSD and term “model building” in “group model building”).3 This idea
drives much of the content in this book, from the three stages of a CBSD project to
the use of scripts to the assessing readiness and building capacity for CBSD in a
community.
To visualize this, it is helpful to consider the system dynamics modeling process
more explicitly over time. Figure 1.5 shows a typical cycle of a modeling process
starting with problem definition that includes defining the reference mode, concep-
tualizing the system that focuses on identifying the various elements of the system
and how they are related, creating or formulating a formal model that can be simu-
lated, validating and analyzing the results to develop policy recommendations, and
transferring insights and ownership of the model to the participants in the process.
The process is highly iterative, requiring the one or more previous stages to be revis-
ited as the group develops insights about the system, as indicated by thin, counter-
clockwise pointing arrows.
Most descriptions of the system dynamics modeling process have something
similar to Fig. 1.5, and the tendency of viewing projects as single projects leads one
to expect that one must pass through all stages of the modeling process in order to
consider the project complete and successful.
In CBSD, multiple projects are distributed across various issues and time but
exist within the same general community allowing the social learning and social
capital around one or more models to accumulate over time. One way to illustrate
this is in Fig. 1.6 where the x–y coordinates in the plane represent where a project is
at any given time along the z or vertical coordinate. Initially, several projects may
focus on defining the problem, and some may cycle back.
tion over time. Hence, I prefer the term “community based,” and it is consistent with the common
usage of a community-based participatory research (Minkler and Wallerstein 2008).
3
The earliest articulation of this appeared in Hovmand et al. (2008) with work funded by the
National Science Foundation (SES-0724577) and the Missouri Transformation Project, funded by
the Substance Abuse Mental Health Services Administration Mental Health Transformation State
Incentive Grant (McFarland, Chair; Goon, Co-Chair; SM57474- 01).
Fig. 1.6 Overview of multiple projects in a community in CBSD
A by-product of this process is that people are being educated in system dynam-
ics and group model building and the capacity for identifying appropriate problems
and engaging more effectively in system dynamics and group model building is
increasing. So over time, more complex projects are undertaken that pass through
additional stages of modeling until modeling projects routinely begin to complete
all stages of the modeling process, and over time with even more capacity, the time
required decreases.
Conclusion
This chapter has sought to motivate the case for CBSD and establish some of its
main conceptual foundations. In doing so, key terms such as “mental models,”
“community,” “participation,” “group model building,” “dynamic complexity,”
“informal causal maps,” and “formal models” have been identified although not
always defined. The overriding priority has been to describe these terms in a way
that aligns with the pragmatics of conducting CBSD in diverse settings. In the chap-
ters that follow, we will place more emphasis on the practice of engaging and
involving communities in the process of understanding and changing systems from
the endogenous or feedback perspective (Fig. 1.6).
References 15
References
Austin, J. L. (1962). How to do things with words (2nd ed.). Cambridge, MA: Harvard University
Press.
Black, M. (1962). Models and metaphors: Studies in the language and philosophy. Ithaca, NY:
Cornell University Press.
Dörner, D. (1997). The logic of failure: Recognizing and avoiding error in complex situations.
New York, NY: Basic Books.
Doyle, J. K., & Ford, D. N. (1998). Mental models concepts for system dynamics research. System
Dynamics Review, 14, 3–29.
Dudley, R. G., Sheil, D., & Colfer, C. (2008). Simulating oil palm expansion requires credible
approaches that address real issues. Ecology and Society, 13(1), r1.
Fisher, A., & Sonn, C. (2007). Sense of community and dynamics of inclusion-exclusion by
receiving communities. The Australian Community Psychologist, 19(2), 16–34.
Forrester, J. W. (1969). Urban dynamics. Cambridge, MA: MIT Press.
Forrester, J. W. (1990). Principle of systems. Waltham, MA: Pegasus Communications. Original
edition, 1971.
Forrester, J. W. (2007). System dynamics-the next fifty years. System Dynamics Review, 23(2–3),
359–370.
Frye, M. (1983). The politics of reality: essays in feminist theory. Freedom, CA: The Crossing
Press.
Harding, S. (1991). Whose science? Whose knowledge: Thinking from women's lives. Ithaca, NY:
Heyes, C. (2000). Line drawings: Defining women through feminist practice. Ithaca, NY: Cornell
University Press.
Horton, M. and Freire, P. 1990. We make this road by walking: conversations on education and
social change. Edited by B. Bell, J. Gaventa and J. Peters. Philadelphia: Temple University
Press.
Hovmand, P. S., Ford, D. N., Flom, I., & Kyriakakis, S. (2009). Victims arrested for domestic
violence: Unintended consequences of arrest policies. System Dynamics Review, 25(3),
161–181.
Hovmand, P.S., D. F. Gillespie, Diane McFarland, Enola Proctor, Benton Goon, Barbara Levin,
and Sally Haywood. 2008. Science meets policy practices. Paper read at 26th International
Conference of the System Dynamics Society, at Athens, Greece.
Kumar, S. (2002). Methods for community participation: a complete guide for practitioners.
Warwickshire, UK: Practical Action.
Lave, J., & Wenger, E. (1991). Situated learning: Legitimate peripheral participation. Cambridge,
UK: Cambridge University Press.
Meadows, D. H. (1991). Global citizen. Washington, DC: Island Press.
Meadows, D., Jørgen, R., & Dennis, M. (2004). Limits to growth: The 30-year update. White River
Junction: Chelsea Green Publishing Company.
Minkler, M., & Wallerstein, N. (Eds.). (2008). Community-based participatory research for health:
From process to outcomes (2nd ed.). San Francisco, CA: Jossey-Bass.
Moxnes, E. (2000). Not only the tragedy of the commons: misperceptions of feedback and policies
for sustainable development. System Dynamics Review, 16(4), 325–348.
Richardson, G. P. (2011). Reflections on the foundations of system dynamics. System Dynamics
Review, 27(3), 219–243.
Rouwette, E., Vennix, J. A. M., & van Mullekom, T. (2006). Group model building effectiveness:
A review of assessment studies. System Dynamics Review, 18(1), 5–45.
Senge, P. (1990). The fifth discipline. New York, NY: Currency Doubleday.
Stave, K. (2010). Participatory system dynamics modeling for sustainable environmental manage-
ment: Observations from four cases. Sustainability, 2(27), 2762–2784.
Stave, K. A. (2002). Using system dynamics to improve public participation in environmental

decisions. System Dynamics Review, 18(139–167).
Sterman, J. D. (2000). Business dynamics: Systems thinking and modeling for a complex world.
New York, NY: Irwin McGraw-Hill.
Wittgenstein, L. (1974). Tractatus logico-philosophicus. New York: Routledge. Translated by D.
F. Pears and B. F. McGuinness. Original edition, 1921.
Chapter 2
Group Model Building and Community-Based
System Dynamics Process
Group Model Building
Group model building was initially developed in the 1980s by leaders in the field of
system dynamics (e.g., Richardson and Andersen 1995; Richmond 1997; Vennix
1996) who recognized the potential of developing computer models and simulations
with participants that leveraged the diagramming conventions of system dynamics
(Lane 2000). This was arguably enabled by the creation of the first icon-based sys-
tem dynamics software STELLA on the Macintosh, developed by Barry Richmond
at High Performance Systems (now isee systems).
While system dynamics has always had a rich tradition of involving people to
inform the structure, parameters, and policies to be tested in a simulation model
through meetings and interviews, the development of group model building sig-
naled a new direction in the field to involve participants more directly in the model-
ing process (Andersen et al. 2007).
However, definitions of group model building vary. For example, Vennix (1996)
argues that this common practice of involving stakeholders in the modeling process
introduces a social dynamic that can affect the quality of the model, buy-in from
stakeholders, and ultimately the likelihood that recommendations will be imple-
mented. Rather than leave this to chance, Vennix therefore argues for a more inten-
tional approach to working with stakeholders in the modeling process and uses the
term “group model building” broadly to describe “a process in which team members
exchange their perceptions of a problem and explore such questions as: what exactly
is the problem we face? How did the problematic situation originate? What might
be its underlying causes? How can the problem be tackled?” (p. 3).
At the other end of the spectrum, Richardson and Andersen (1995) have taken a
narrower use of the term to signal “the intent to involve a relatively large client
group in the business of model formulation, not just conceptualization” (p. 1). In
both cases, the underlying ideas are essentially the same and emphasize the benefits
of involving stakeholders in the process of developing a model with the expectation

18 2 Group Model Building and Community-Based System Dynamics Process
that this will not only lead to a more relevant model but shared insights, consensus,
and motivation for implementing the results.
More recently, some have argued for a broader term, “participatory systems
modeling” (e.g., Michaud 2012; Stave 2010), which encompasses group model
building and mediated modeling (van den Belt 2004) but places more emphasis on
seeing participation along a continuum of model building and formulation, from no
involvement to high involvement. Much of this work sits within the environmental
and natural resources decision support literature. One implication of this is that
much of this work is also place based. For example, Stave (2010) talks about how
computer simulation models with higher levels of participation in the modeling
process are subsequently used in workshops with different participants who have
not been involved in the development of the model.
One often overlooked consequence of this may be underestimating the role of
stakeholder participation in early stages of model development on later benefits
social learning and capital development (Stave 2010). Models that are developed in
same place around public issues often have a common referent of experiences
within the same community, so even when participants have not been involved in
the modeling process, there can be a connection to a model developed by others
from their community. Recognizing and drawing on the potential of communities to
learn and build capacity over time through multiple system dynamics and group
model building projects is a central idea in CBSD.
Approaches to Group Model Building
Vennix (1996) has described the design of group model building as varying along
four dimensions. First, who is defining the initial issue or problem? Initially, in
communities with little or no experience with system dynamics or group model
building, this will often start with someone with training in system dynamics.
However, as some within a community become more familiar with system dynam-
ics or group model building, community members start to take a greater lead in
defining the problem, which is explicitly pursued in CBSD.
Second, projects can be distinguished by whether or not they follow a structured
or unstructured group process. In a structured group process, a detailed agenda of
the group model building session is developed and usually in some collaboration
with the client or sponsor of the project. In an unstructured group process, there may
be a loose agenda and reliance on improvising group activities in response to the
group dynamics and conversation flow. An unstructured group process generally
requires high levels of system dynamics and group model building training and
expertise to be successful. Because much of the emphasis in CBSD is on building
capacity and designing group model building workshops that are community spe-
cific, CBSD is often a highly structured approach detailed in Chap. 5.
Approaches to Group Model Building 19
Third, group model building projects also differ by what type of model is going
to be developed. Will the focus of the project be to develop an informal causal map1
or a formal computer simulation model? Informal causal maps are frequently used
at early stage of a modeling process to help conceptualize the system and define the
problem, as well as at the end of a project to communicate the results from analyz-
ing a simulation model, but have come to be seen as the desired output on their own,
that is, without an accompanying simulation model (Lane 2000). In CBSD, the
goals for any specific project can be the development of an informal map or more
formal computer simulation model, but generally as capacity develops within the
community, demand for computer simulation modeling develops around one or
more well-defined problems based on the experience and results from earlier proj-
ects focusing on causal mapping.
Fourth, projects differ by whether or not they start a group with a “blank slate”
or some initial model structure. In the “blank slate” approach, one begins the work-
shop rather open ended, usually through some of type of exercise that elicits issues
or variables related to the problem of interest. When one starts with some initial
model structure, one might use a concept model to introduce the language of system
dynamics (Richardson 2013) or some type of seed or backbone structure of the
system as a starting place to elicit causal structures of a system.
For example, one might start with a basic stock and flow diagram illustrating
how people in a community move through different health and disease states and
then ask participants to identify variables that influence the transition rates or flows
between these stocks. The advantages of using an initial structure are that one is
often able to more quickly introduce the language of system dynamics and not ask-
ing participants to identify elements of the system that may already be known from
prior modeling activities, focus groups, key informant interviews, or the literature.
The main concern with using an initial structure is that it may bias participants and
create a strong framing effect on the rest of the workshop activities. So any initial
structure introduced into a workshop generally has to be carefully chosen and
piloted in a mock session to see whether or not the initial structure works as intended.
In CBSD, projects may begin with either a “blank slate” or some initial structure,
and the choice often depends on the history of models previously built in a com-
munity. With new communities, initial conversations may take more of an open-
ended “blank slate” approach to discover what some of the issues are and ground
problems in the local language. Later, as projects become more focused and com-
munity members familiar with earlier efforts, going through the same open-ended
exercises can start to feel like duplicating previous work and inadequately leverag-
ing the earlier work of other community members. At this point, elements or even
whole models can be shared at the start of a session.
1
Some use the term qualitative instead of causal map to distinguish a non-simulation from a simu-
lation model.
Teamwork
Richardson and Andersen (1995) were the first to note the importance of teamwork
in group model building and identified a number of different roles that were required
to facilitate a group model building workshop. They emphasized the high cognitive
loads involved in attending to group dynamics, facilitating the conversation, build-
ing a model, analyzing the model and developing insights, and reflecting back
observations about the model back to participants. As a consequence, they noted
this work tended to always be done in teams with essentially five different roles:
• Group facilitator to lead the session with training in system dynamics and facili-
tation skills.
• Modeler/reflector to develop and analyze the model and then reflect back model-
based insights to the participants.
• Process coach to observe the group process and provide the team with feedback.
• Recorder to take notes, document products from a session including drawings of
models and dynamics with enough training in system dynamics to know what to
include and what to ignore.
• Gatekeeper to represent the client perspective in selecting and recruiting partici-
pants who can advocate on behalf the client group with the modelers and on
behalf of the modeling team with the client group.
As structured group model building evolved through the use of scripts, additional
roles have been identified (Hovmand et al. 2012; Andersen and Richardson 1997):
• Wall builders to organize products from an exercise into thematic clusters.
• Runners to transfer products from an participants to the wall builder.
• Conveners and closers to open and close the session or workshop who have sta-
tus among the participants and help set the tone for the session.
• Specific to CBSD, community facilitators who co-facilitate the workshop with
the facilitator (then called a modeler-facilitator to distinguish their role from the
community facilitator) and understand the local language and can identify/miti-
gate power dynamics among participants.
Additionally, in CBSD, we have also had roles that are specific to the setting and
workshop, including:
• Translators to provide simultaneous translation between the local language and
language of the modeling team when the modeling team and community do not
speak the same language.
• Debriefer to lead and facilitate the debrief of the facilitation team after the group
model building workshop.
• Observers to observe but not participate in the process.2
2
We found it beneficial to call out the observer role explicitly as a way to define expectations about
their role during the session.
Teamwork 21
• Production coordinator to handle the preparation of products generated by the

modelers and recorders that are distributed during and at the end of a workshop
session.
• Choreographer to conceptualize and oversee the overall design of structured
group model building workshop including development of the detailed agenda,
scripts, facilitation manual, and training of the facilitation team.
It is important to recognize that any given project does not need one person for
every role and that some roles can be carried by the same individual. For example,
the gatekeeper, convener, and closer are often the same person, and in a two-person
facilitation team with a modeler-facilitator and community facilitator, one person
can serve as the wall builder.
On the other hand, some roles are demanding and do not allow this. For example,
recorders are nearly always working continuously through the session and rarely in
a position to take on other roles without compromising the recording process.
Facilitators having been in the front of the room for most of the session are also not
the persons to take on the debriefer role, whereas as a process coach who has been
taking notes during the workshop is often in a good position to lead the debrief after
the workshop. The bottom line is that group model building is a team activity, and
team performance can have a major impact on the group process that evolves and
the quality and impact of the results.
Generally speaking, facilitation teams require 3–5 people with complementary
skills and training. Smaller teams with less experience in system dynamics and
group model building should generally start with shorter sessions (90–180 min)
focusing on developing initial problem definition or conceptualizations of a system
using causal maps, and with experience, they can take on the challenges to eventu-
ally facilitate full-day and multiday group model building workshops that include
the development of a computer simulation model.
Teamwork and team learning can be enhanced by building into agendas struc-
tured places for the facilitation team to conference and debrief after a session with
a designated person leading the debrief. Creating a predictable and safe space where
initial impressions can be shared, team members have a chance to support and feel
supported by the team and learn, and feeling OK at the end is critical for long-term
development. One should not underestimate the impact on an individual at having
completed their first session in a new role, the sense of failure when the workshop
took an unexpected turn, the frustrations that arise with participants or team mem-
bers, or the sadness that can hit team members upon hearing and getting a structural
perspective on the hurt and suffering experienced by a community.
A structured debrief becomes especially critical when the team has to quickly
regroup and put together the next session, and is necessary whether or not things
went well or were seen as a failure. Team members with little or no formal training
in system dynamics and group model building also benefit from this early on and
will generally recognize that there will be a team there to support them when they
take risks in volunteering for a new role.
Boundary Objects
The relationship between visual representations (e.g., causal loop diagrams, stock
and flow diagrams, behavior over time graphs) in system dynamics and the role they
play in groups has been topic of discussion among system dynamicists, but it is
Laura Black (Black et al. 2004; Black and Andersen 2012) who first made the con-
nection that these visual representations functioned as boundary objects and play a
key role in group model building.
The notion of boundary objects originated in studies of distributed cognition and
transdisciplinary knowledge sharing and was coined by Susan Star (1989) to describe
the way visual metaphors were used to facilitate knowledge sharing across different
knowledge and user domains. While the literature expanded the definition of bound-
ary objects, in system dynamics and group model building in particular, the role of
boundary objects is more specific and especially useful for defining some of the
essential characteristics of group model building. More formally, a boundary object is
A tangible representation of dependencies across disciplinary, organizational, social or cul-
tural lines that all participants can modify. It can effectively advance shared understanding
when participants can transform the representation to show more clearly their understand-
ing of the dependencies among them and the implications for each participant’s resources,
operations and goals. (Black and Andersen 2012, 195)
In system dynamics, boundary objects have three essential characteristics (Black

and Andersen 2012). First, they are tangible two- or three-dimensional word sparse
representations (e.g., diagrams with few words). Second, these representations are
sufficient for participants to show key concepts, actions, and the relationships
between them. Third, they are accessible and modifiable by all participants. To this
list, Black reminds us that boundary objects are social constructions and there are
several different ways that visual representations can fail to be boundary objects
(Black 2013). In particular, Black has identified three general failure modes for
boundary objects:
• The visual representation is owned by one stakeholder group or knowledge
domain with others deferring to this representation. This can happen when a
model is no longer seen as the group’s model, but the system dynamics expert’s
model and participants automatically defer to the system dynamics expert’s rep-
resentation of their issue. Or, the visual representation is dominated by detail
from one stakeholder or knowledge domain.
• Each stakeholder group or knowledge domain develops their own independent
visual representation to the exclusion of the others. This occurs, for example,
when rather than trying to negotiate and resolve the semantic differences and
priorities between different stakeholder perspectives, the group fragments and
each decides to build their own visual representation while ignoring other
viewpoints.
• The visual representation covers all stakeholder groups and knowledge domains
without being selective in identifying key concepts, actions, and relationships.
Scripts 23
Similar to the second example, rather than resolving the semantic differences, the
group ends up with a visual representation that essentially includes everything.
Visual representations as boundary objects in system dynamics provide what
Donald Schön (1979) referred to as a generative metaphor in his study of product
innovation. In particular, Schön gives an example of a product development team
charged with developing a new paintbrush. Initially, the team is looking at the paint-
brush as an applicator until someone on the team recognizes the paintbrush as a
pump with a reservoir. The pump metaphor allows the team to think differently
about the paintbrush.
The use of informal causal maps and formal models that can be simulated in
system dynamics within a group model building session provides a systematic way
to negotiate and socially construct a series of boundary objects with a group that can
eventually serve as generative metaphors for developing system insights. In fact,
much of the activity within group model building is focused on designing, building,
maintaining, and transitioning a group from one boundary object to another bound-
ary object (Richardson and Andersen 2010).
Moreover, when a group model building process tends to collapse, it is nearly
always because the visual representations no longer function as a boundary object.
That is, one has run into one of the three main failure modes identified by Black.
This is especially useful to be aware of because it provides a framework for the
facilitation team to recognize the problem in terms of failure modes of boundary
objects and thereby find a way to restore the group model building process. One
might even go so far as to say that the essence of group model building is the explicit
design and management of a process to a socially construct boundary objects
involving system dynamics visual representations.
Scripts
As group model building practice developed, patterns for facilitating small groups
in the process of developing system dynamics emerged that Andersen and
Richardson (1997) called group model building “scripts.” These were essentially
standard exercises that teams would use such as setting group expectations (“hopes
and fears” script), identifying variables related to a problem (variable elicitation
script), eliciting dynamic stories (graphs over time script), eliciting causal structures
(structure elicitation script), introducing system dynamics (concept model script),
and finding where capacity and demand meet (ratio script). Initially undocumented,
collections of scripts provided a playbook that teams would use to design and facili-
tate group model building sessions.
Later efforts to move some of the art of group model building into a science
(Vennix, Andersen and Richardson 1997) stressed the need for documenting group
model building sessions as a sequence of scripts (Luna-Reyes et al. 2006), the devel-
opment of ScriptsMap (Ackermann et al. 2010) as a way to describe these sequences
in relation to project outcomes, and eventually the systematic documentation of

group model building scripts in Scriptapedia3 (Hovmand et al. 2012). Scripts in this
sense essentially form the patterns in a pattern language (Alexander 1968).4
An important insight in the development of ScriptsMap that was incorporated
into Scriptapedia was the idea that aside from “starter scripts” used at the beginning
of a group model building session, each script takes as an input a product from a
previous script and generates a product as an output for a subsequent script. Another
characteristic of scripts is that they generally tend to fall into one of four types of
categories of group activities:
• Divergent activities designed to produced an array of different ideas and
interpretations.
• Convergent activities designed to clustering and categorizing ideas and
interpretations.
• Evaluative activities designed to rank and choose between options and idea.
• Presentation activities designed to educate or update participants.
A general principle of good workshop design is for sessions to mainly consist of
alternating patterns of divergent and convergent group activities. Another principle
that has emerged is in the use of scripts in that most if not all of the outputs from one
script should be used in the subsequent script. We can think of relationship between
the outputs from one script being used as an input to another script as the efficiency
of a sequence of scripts within a group model building exercise.5
For example, in the “graphs over time” script, participants draw and then share
stories about dynamics related to the problem at hand (see Fig. 2.1). This is a diver-
gent activity that often generates a set of clustered variables with associated dynam-
ics. In addition to the tangible graphs over time, participants usually share rich
stories with causal relationships to explain the various changes in their graph over
time. If the next script uses both the information on the graphs as the list of variables
and the causal stories shared, participants will tend to feel that the effort was used
efficiently. If on the other hand, one only uses the results from the “graphs over
time” script to identify variables related to the problem and ignores the content of
the causal stories that are shared by participants, then at least some of their effort
may feel wasted as this did not get reflected in the next activity.
CBSD makes extensive use of scripts (Andersen and Richardson 1997) and par-
ticipatory rural appraisal (PRA) methods (Kumar 2002), ScriptsMap (Ackermann
3
Annaliese Calhoun coined the term “Scriptapedia” in early design conversations with Timothy
Hower, George P. Richardson, David Andersen, and myself. This work was partially supported by
the Center for Violence and Injury Prevention at Washington University in St. Louis through a
grant from the Centers for Disease Control and Prevention (Grant Number 1R49CE001510).
4
Jim Deering helped me see the connection between scripts in group model building and patterns
in a pattern language, although George Richardson objects to this characterization because it
detracts from recognizing the choreography of group model building.
5
This was a point that Bobby Milstein identified during a demonstration group model building
session as part of the 2012 Institute on Systems Science and Health at Washington University in St.
Louis.
Participants 25
Fig. 2.1 Participant sharing story in graphs over time exercise as part of the Veteran, Battering,
and Trauma project with clustered graphs in background
et al. 2010), and Scriptapedia (Hovmand et al. 2012) both as a means of designing
effective collaborations with communities when teams have little or no experience
in system dynamics and group model building and also a way to document and
evaluate the process of group model building in communities and thereby increase
the evidence based for effective group model building practice.6
Participants
Two of the most common questions are, (1) who should be involved and (2) how
many people are needed?
Who should be in the room of a group model building session depends on the
purpose of the session. If the goal of the session is to introduce an organization or
community to group model building, then one should be looking for individuals
who play the role of gatekeeper. If the goal of the session is to inform the design of
a new program for low-income teen moms, then one should be looking for
6
Making group model building practice evidence based is a challenging problem as most work-
shops and interventions are customized for the client and situation, and some if not a significant
component of the process depends on facilitation (Vennix 1996). Methodologically, evaluating this
entails separating specific from nonspecific treatment effects (Lohr et al. 2003), and the first step
in this is to first identify what the contribution is of the specific treatment effects.
individuals who can voice the experience and concerns of teen moms in addition to
the providers.
But, the reasons for involving them need to be clear. In contrast to the group model
building approaches that focus decision support and therefore decision makers, a goal
in CBSD is on involving participants to create a community of practice around a
model that can be used to design innovations that the community will advocate for and
implement. It is therefore less important in CBSD that the participants be statistically
representative of the population in a community and more important that they play the
role of opinion leaders or interpreters within their community.
In the design-driven literature, interpreters play a critical role in understanding
how various constituencies will respond to a given innovation (Verganti 2009).
They are researchers in the sense that they are inquisitive about how members from
their clique respond to something and have learned over the years what their prefer-
ences are and what motivates them. As a member of the community, they can both
identify with the needs and articulate them within a group model building session.
They also play important roles within their community as opinion leaders by bring-
ing in new interpretations of situations and innovations into the community; they
have credibility in translating and conveying insights.
In terms of size, groups smaller than 5 tend to lose the dynamics that leads to a
successful group model building outcome, and opportunities for sufficient interac-
tion tend to break down in groups larger than 17 (Yalom 1995). As groups get larger,
the proportion of participants diminishes and the risk of a few voices dominating the
conversation increases. One way to offset this is to have multiple group model
building sessions or subdivide the group into small groups.
Three Stages of a CBSD Project
CBSD projects are generally broken into three distinct stages: (1) problem scoping
and identification, (2) core modeling team planning and capacity building, and (3) the
actual group model building workshops (see Table 2.1). Here, we will focus on a brief
overview and then describe each phase more specifically with its own chapter.
Problem Scoping and Identification
Few, if any, problems involving social systems arrive as well-defined problems that
are readily amenable to the development of a formal simulation model and analysis.
Moreover, issues may not be posed as dynamic problems involving change over
time or have obvious feedback dynamics that are of interest. There are also ques-
tions about whether or not the type of modeling activity that would add the most
value can be developed within the available time and resources, for the modelers
and community partners.
Three Stages of a CBSD Project 27
Table 2.1 Three phases of community-based system dynamics projects

Phase Activities
Problem discovery or “scoping” Identifying the dynamic problem to be modeled
Assessing the suitability for system dynamics
Developing one-page project description defining background,
purpose, audience, scope, and resources needed
Core modeling team planning Developing concept model, seed structures, etc.
Building capacity within core modeling team
Designing group model building process
Creating agendas for each sessions
Developing scripts
Training
Group model building with Introducing SD
participants Variable elicitation
Defining the reference mode
Structure elicitation
Model formulation and testing
Policy analysis
Transfer of ownership
So this first stage involves, usually over the course of several meetings, discus-
sions to identify the problem of interest and assessing the suitability of system
dynamics and group model building. The output from this is usually a draft model-
ing project description that describes the potential modeling project defining back-
ground and motivation for the project, the dynamic problem of interest, the purpose
and audience for the model, its scope, and resources and values that are needed.
This is an internal document, a description of the potential modeling project, and
serves as a charter or mission statement of sorts for the model if the group decides to
proceed. It is not a project proposal or something that one would generally circulate to
external stakeholders or funders. Keeping it short (one page or less) is important
because at this stage, one wants to minimize the investment in a potential project
before people have developed a clear idea of what the project would be about.
Time invested at this stage can range from 1 to 3 hours over one or more meetings
stretched over several weeks or months with interim discussions or email exchanges
to clarify the modeling project description. There can be many good reasons for not
proceeding at this stage, which are covered in more depth in Chap. 3, but should there
be decision to proceed, a more formal proposal or bid is developed at this stage.
Core Modeling Team Planning and Capacity Building
Once the project has resources secured and the necessary approval to begin, a core
modeling team (CMT) is recruited to lead the design of the group model building
workshops. Members of the core modeling team usually include individuals
involved in the initial conceptualization of the project during the problem scoping
phase and other individuals who are either members of community or have suffi-
cient experience working in the community to serve as proxies. The CMT is gener-
ally a small team of 5–7 people who are “process tolerant” as this is the process of
designing the process for building a model.
The primary task of the core modeling team (CMT) is to design the group model
building workshop, which begins with an initial orientation to system dynamics and
group model building and then moves on to developing a process map of participant
groups and sessions, detail agenda, adaptation and development of scripts, prepara-
tion of a facilitation manual, and recruitment and training of the facilitation team.
This can usually be accomplished within five 2-hour meetings.
Group Model Building Workshops
After the planning process, the CMT takes on a new function and essentially serves
as a steering committee or workgroup to oversee the development of model through
the GMB workshops. Some members from the CMT during the planning phase may
continue on in this phase, while others drop out being more interested in seeing the
final results at the end of the GMB workshops.
The CMT also serves as the facilitation team that leads the actual GMB sessions
and is typically a mixture of members from the previous CMT and new people who
have been recruited to fill specific roles in the GMB workshop design. A training or
“dress rehearsal” prior to the first session is generally required even with an experi-
enced team to make sure everyone understands their roles as well as to identify and
solve unanticipated problems in the workshop design.
The actual group model building workshops then take participants through a series
of exercises and facilitated discussions that have been organized by the CMT.
Depending on the design, these can involve one short 90–120 minutes session with a
small group; several workshops with the same design replicated several times with
different groups, 1- or 2-day workshops with one group, or time separated workshops
over weeks or months with the same group. Sometimes the participants in the work-
shop are the main audience for the modeling, but other times a larger community
forum is held for sharing the results and involving a broader group of stakeholders.
After GMB workshops, recorders’ notes, causal maps and models, potential
leverage points and recommendations, and other products are reviewed by the CMT.
Participants are often invited to the review sessions and welcomed to join the CMT
if they are interested. The CMT then proceeds to work on the model and prepare for
the next session, community meeting, or final presentation of results.
Evaluation, Reporting, and Next Steps
At the completion of the group model building project, the CMT considers project
process and outcomes relative to the original modeling project description. Informal
evaluations can happen at the end of the last session with a review of the “hopes and
References 29
fears” from the first workshop session, or follow a rigorous approach using surveys
and other evaluation methods. These are generally summarized in report to the orig-
inal sponsor with a clear statement about what the outcomes were with respect to
the workshop goals and objectives in the modeling project description and discus-
sion of the next steps after this project.
Conclusion
This chapter has provided a brief overview of group model building with specific
attention to concepts that pertain and used in CBSD including the importance of
teamwork, the use of scripts, and the role of visual representations in system dynam-
ics serving as boundary objects. This introduction is not mean to serve as a descrip-
tion or primer for group model building in general. For a general and highly
accessible overview of general group model building practice, readers are encour-
aged to take a look at Vennix’s (1996) book, Group Model Building. This chapter
has also introduced the three main stages of CBSD, which will be expanded in more
detail with practice examples in the next three chapters.
References
Ackermann, F., Andersen, D. F., Eden, C., & Richardson, G. P. (2010). ScriptsMap: A tool for
designing multi-method policy-making workshops. Omega, 39, 427–434.
Alexander, C. (1968). A pattern language which generates multi-service centers. Berkeley, CA:
Center for Environmental Structure.
Andersen, D. F., & Richardson, G. P. (1997). Scripts for group model building. System Dynamics
Review, 13(2), 107–129.
Andersen, D. F., Vennix, J. A. M., Richardson, G. P., & Rouwette, E. (2007). Group model build-
ing: problem structuring, policy simulation and decision support. The Journal of the Operational
Research Society, 58(5), 691–694.
Black, L.J. (2013). When visual representations are boundary objects in system dynamics. System
Dynamics Review, 29(2), 70–86.
Black, L. J., & Andersen, D. F. (2012). Using visual representations as boundary objects to resolve
conflict in collaborative model-building applications. Systems Research and Behavioral
Science, 29, 194–208.
Black, L. J., Carlile, P. R., & Repenning, N. P. (2004). A dynamic theory of expertise and occupa-
tional boundaries in new technology implementation: Building on Barley’s study of CT scan-
ning. Administrative Science Quarterly, 49(4), 572–607.
Hovmand, P. S., Andersen, D. F., Rouwette, E., Richardson, G. P., Rux, K., & Calhoun, A. (2012).
Group model building “scripts” as a collaborative tool. Systems Research and Behavioral
Science, 29, 179–193.
Kumar, S. (2002). Methods for community participation: a complete guide for practitioners.
Warwickshire, UK: Practical Action.
Lane, D. C. (2000). Diagramming conventions in system dynamics. The Journal of the Operational
Lohr, J. M., DeMaio, C., & Dudley McGlynn, F. (2003). Specific and nonspecific treatment factors
in the experimental analysis of behavioral treatment efficacy. Behavior Modification, 27(3),
322–368.
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.
Michaud, W. R. (2012). Evaluating the outcomes of collaborative modeling for decision support.
The Journal of the American Water Resources Association, 49(3), 693–699.
Richardson, G. P. (2013). Concept models in group model building. System Dynamics Review, 29,
42–55.
Richardson, G. P., & Andersen, D. F. (1995). Teamwork in group model building. System Dynamics
Review, 11(2), 113–137.
Richardson, G.P., & Andersen, D.F. (2010). Systems thinking, mapping, and modeling in group
decision and negotiation. In Handbook of Group Decision and Negotiation (pp. 313–324).
Dordrecht: Springer Verlag.
Richmond, B. (1997). The strategic forum: aligning objective, strategy, and process. System
Schön, D. (1979). Generative metaphor: A perspective on problem-setting in social policy. In A.
Ortony (Ed.), Metaphor and society (pp. 254–283). Cambridge: Cambridge University Press.
Star, L. (1989). The structure of ill-structured solutions: Heterogeneous problem-solving, bound-
ary objects and distributed artificial intelligence. In M. Huns & L. Gasser (Eds.), Distributed
Artificial Intelligence. Menlo Park, CA: Morgan Kauffmann.
Stave, K. (2010). Participatory system dynamics modeling for sustainable environmental manage-
ment: observations from four cases. Sustainability, 2(27), 2762–2784.
van den Belt, M. (2004). Mediated modeling: a system dynamics approach to environmental con-
sensus building. Washington, DC: Island Press.
Vennix, J. (1996). Group model building. New York: Wiley.
Verganti, R. (2009). Design-driven innovation: changing the rules of competition by radically
innovating what things mean. Boston, MA: Harvard Business Press.
Yalom, I.D. (1995). The theory of practice of group psychotherapy. Fourth ed. New York, NY:
Basic Books.
Chapter 3
Engaging Communities
If the purpose is to solve the problem—then you don’t take the

time to let people develop their own solutions. If the purpose is
to solve the problem, there are a lot of ways solve the problem
that are much simpler than going through all this education
process. Solving the problem can’t be the goal of education.
It can be the goal of organizations. That’s why I don’t think
organizing and education are the same thing. Organizing
implies that there’s a specific, limited goal that needs to be
achieved, and the purpose is to achieve that goal. Now if that’s
it, then the easiest way to get that done solves the problem.
But if education is to be part of the process, then you may not
actually get that problem solved, but you educate a lot of
people. You have to make a choice.
Myles Horton (Horton and Freire 1990, 119)
Engaging Communities
One of the most common questions asked about CBSD is how to engage communi-
ties that may be unfamiliar with and generally lack skills and training in system
dynamics. These concerns are greatest when we are focused on marginalized com-
munities with little or no formal education much less training in system dynamics
and group model building and differ from the people initiating CBSD in their status,
cultural values, traditions, and language. Keeping the focus on empowerment means
that one must also be aware of the imposition of an outsider, technical language that
can exacerbate power differences and reinforce the very effects of colonization that
the community is seeking liberation from.
Paulo Freire (2007) faced this problem in organizing indigenous communities
along the Amazon River who were illiterate and thereby excluded from the political
process. The pedagogical problem that Freire faced was how to increase literacy in
a community without imposing the language of the colonizer. Extricating oneself
from the dominant language in way that allows one to establish moral and political
claims and assert power is already difficult (Penelope 1990), so one is keen in CBSD
to avoid adding to this problem. Along similar lines, introducing a new language or
way of talking about problems as system dynamics does can shift mental models in
a way that leads to empowerment and liberation, but it can also be used by elites
within community to effectively further institutionalize the dominant logic of power

32 3 Engaging Communities
relationships and subordinate others through speech acts (Austin 1962) and code
switching (Myers-Scotton 1993).
Engaging communities is therefore fundamentally about building up a shared
language and community of practice around “a model” or, rather, a series of models
since any given model is often a temporary and fleeting representation of reality, a
rung on a ladder we use to move from one mental model to another mental model.
The approach in CBSD builds on the different approaches of Horton and Freire in
adult education and community organizing (Horton and Freire 1990; Freire 2007).
Within this context, it is important to recognize that there are no insights that can
be communicated and implemented in a participatory way without the shared lan-
guage and understanding around a model within a community. This may feel frus-
trating to the expert who already knows the desired behavior based on scientific
knowledge of the real system. Soil fertility, sustainable harvest rates, global climate
change, and energy balance are not something we can will away through social
construction of reality, but real facts. The social problem is that despite their reality
and scientific basis in recommendations, one still needs to compete against alterna-
tive viewpoints however irrational and unscientific they might be for findings to take
hold and make a difference.
This is made harder in many systems by the fact that conventional wisdom may
be reinforced by empirically supported short-term results. Crops do grow more with
more water. Revenues do increase with larger fishing fleets. Drinking a Coke does
not lead to increased body weight. Smoking does not cause cancer. The problem
with each of these statements, of course, is that they neglect the long-term, accumu-
lated consequences of our actions.
In CBSD, “the model” does not begin with the scientist’s or policy maker’s pre-
conception of what the problem is, but with the issues that the community identifies
and in their language. One starts with where the community is at and has to trust that
the “right” model will emerge through a process of participatory modeling. The
language of system dynamics comes in as needed within the context of the issue
they have identified, ideally appearing not through lectures by an expert providing
definitions but instead by attaching the concepts to the language game that already
exists around the problem.
Engaging communities in this way that respects the longer-term goals of educa-
tion, empowerment, and organization that will enable the eventual recommenda-
tions to be implemented also means that one must accept without prejudice a refusal
to participate.
This can be hard. In one case, my colleagues and I traveled from the United
States to India and sat in a community meeting with rural farmers for about an hour
while they debated in Telugu whether or not they should share their stories about
soil fertility, a pressing issue that was impacting their lives. Had they said “No” at
the end of the debate, we would have left. In another case, a resident in a St. Louis
neighborhood asked point-blank what the benefits would be, “Would this lead to
new programs that would help us?” I explained that we would not be providing a
program, but a model, and the model could be used to identify needs and write pro-
posals for funding programs. She then asked, “Will what you’re doing stay in the
Engaging Communities 33
community, or will you take it when you leave?” “No” I said, “The process we
develop with you is something we want to leave with you, to teach you how to do
on your own.” Four years later, she still comes to the core modeling team meetings.
The reason she says is that she learns something new every time.
Members of marginalized communities have at this stage absolutely no reason to
trust the “foreigners” in their community. In many cases, their experience with pre-
vious researchers, experts, politicians, and other educated elites has left them rightly
skeptical and protective of their community. Promises of building capacity and writ-
ing more grant ring hollow. They have heard this before. They know the outcome.
They know the way the incentives are structured. They are right to be skeptical.
In CBSD, we seek to develop a meaningful and sustainable relationship with
communities. This means, among other things, making sure that we are accountable
over time and focused on activities that are meaningful and sustainable within the
communities. To do this, we generally try to avoid distorting participation through
financial incentives. We want to build activities, and understanding that is meaning-
ful and valuable to participants on their terms. What we often tend to forget is the
practical value of a good theory, and this is what we have to offer in the immediate
moments of engaging with communities.
Enabling people to visualize their system, to see the feedback loops, and to
understand that their circumstances are the consequence of a larger system and not
their own fault and that others both within and from outside the community see this
too, while at the same time building connections and helping people identify ways
to influence the larger system, can be validating, uplifting, empowering, and even
healing as new narratives are formed about the system.
The surest way to do this is by demonstrating the approach on a topic that is
important to the community participants. It generally does not matter for this pur-
pose whether or not the topic is related to those of the researchers, experts, or policy
makers. The goal is essentially the same—to demonstrate how one can translate and
reflect back the stories that are important to the community using the visual lan-
guage of system dynamics. There are several different ways to do this using stan-
dard group model building exercises.
Initial Community Participants, Gatekeepers, and Organizations

During Engagement
In CBSD, the initial community participants are usually a small group of people
who have some sense of the community as residents, community organizers and
leaders, and direct service providers who are familiar with and accountable at a
personal level to their clients. An important characteristic is that they have some
knowledge of the local issues and experiences and participate in the community in
way where their evaluation of the methods can carry some weight within the com-
munity. They also know the values and language of the local community.
It is important to distinguish the initial community participants from the role of

gatekeepers, who often play a broker role and control access to the community. The
initial community participants are members of a specific linguistic community and
familiar enough with the issues and power dynamics within the community to
inform design decisions for a group model building process. They are often the first
community members to become a part of the core modeling team (CMT) and play
important roles over the life of a project in designing, facilitating, interpreting, and
communicating the process and results of the modeling process to other members in
the community. Their power often stems from their knowledge of the system, a
knowledge acquired over time from experiences observing and trying to change the
system. They have achieved a standpoint from which to better see issues in the com-
munity (Harding 1991).
Gatekeepers, on the other hand, control access to the community and may have
their own interests and agendas to advance in marginalized communities.
Gatekeepers can include elected and government officials, business leaders, philan-
thropists, researchers and academics, volunteers, and leaders of nongovernmental/
nonprofit organizations serving the community. The organizations they represent
are also diverse.1
The community trusts some organizations, while others have a negative reputa-
tion that can sour potential community participation in CBSD. Some see themselves
as leading innovation, while others are more conservative in their approach and
want evidence that something works before committing resources. Some have the
resources and bandwidth to learn, while others are struggling to keep doors open for
the communities they serve. Gatekeepers as leaders have a constituency to consider
when making a decision of whether or not to be involved with a community-based
project.
Gatekeepers are important to include the process but often removed from the
community when compared with the community members. This can pose a dilemma
even with the most supportive and well-intentioned gatekeepers. On the one hand,
they may be essential to include for any viable solution to be implemented. On the
other hand and however well intentioned, the value of their input may be limited
because of their distance from the issues, and their status can distort the initial pro-
cess of engaging communities with CBSD.
My experience has been that the most effective gatekeepers tend to take a similar
approach. They quickly involve a small set of community members in the process
of evaluating CBSD and deciding whether or not to engage in a project. In a village
or neighborhood, the gatekeepers often want to see a demonstration of a group
model building exercise with a set community members they already have an estab-
lished relationship with. In the context of an organization, the senior leader will
typically want a workshop that introduces and demonstrates group model building,
with a follow-up discussion with his or her staff to solicit their opinion on whether
1
Jim Braun, former CEO of Youth in Need, pointed out the importance of recognizing that gate-
keepers, like the organizations they represent, are diverse and the different roles that gatekeepers
can take in relation to marginalized or high-need communities.
Engaging with the Graphs over Time Script 35
or not to engage further. In both cases, the most effective approach is to provide a
demonstration.
The First Audition
Demonstrating group model building to a prospective community is essentially an

audition for the modeling team. This is usually brief and takes an abbreviated form.
The primary purpose of these sessions is to show by example a group model build-
ing process and illustrate what a model is within the context of an issue they are
concerned about. There are two basic approaches for doing this. One is to engage
participants in the graphs over time script. Another is to engage through the use of
a concept model script.
Engaging with the Graphs over Time Script
In the first approach, one starts with the graphs over time script, which involves ask-
ing participants to generate as many graphs over time (also called behavior over
time graphs) of “things that affect or affected by” the problem variable of interest.
After several minutes, participants are then asked to share their favorite or most
important behavior over time graph over time, one at a time in a round-robin fash-
ion. The facilitator collects each graph and then hands it to a wall builder who orga-
nizes the graphs over time in thematic clusters.
Meanwhile, modelers sitting outside the group are drawing causal structures
inferred from the stories being shared by participants as they describe their behavior
over time graphs. It is crucial that as much as possible, the modelers use the partici-
pants’ words with only slight modification if necessary. If modelers are working in
a different language than the community, simultaneous translation is used during
the discussion. A break follows, which allows the modelers to consolidate the causal
structures into an informal causal map of the system, usually in the form of a causal
loop diagram (CLD), which is drawn on a whiteboard or flip chart paper at the front
of the room. When modelers are working in a different language, the CLD is trans-
lated back into the local language, either by having one CLD for each language or
by having one CLD with the variable in local language and parenthetically with the
variable in the modeler’s language. When working in communities with limited
literacy, pictures or icons can be used to represent variables.
The modeler then presents the CLD to the participants reflecting back the stories
they have just shared to introduce variables and key concepts such as causal links,
link polarity, feedback loops, balancing and reinforcing feedback loops, delays, and
stocks. The participant, having just shared their stories, sees the same story repre-
sented using the grammar of CLDs and can then rather quickly figure out how to
read the rest of the diagram. The modeler then invites the participants to comment
on the diagram: “How did we do?” “What is missing?” “What would you add or
change?” Done right, participants respond almost immediately (less than a minute
or two) with suggestion and ideas of what needs to be changed: “Yes, you are right
in that it costs more to buy the Jersey cows initially, but over time they also reduce
costs” “I don’t think that happens immediately, there probably needs to be a delay
in there somewhere.”
A variation of this approach uses a focus group or community discussion as the
basis of stories from which to draw the CLDs. This may be a bit easier to do in situ-
ations where simultaneous translation is required than the graphs over time script.
Engaging with the Concept Model Script
A concept model is a tiny system dynamics model that is used to introduce participants
to the basic language of system dynamics within the context of problem (Richardson
2013). Importantly, concept models are deliberately flawed or incomplete in ways that
are easily recognizable by participants. The term “concept” in “concept model”
Reflects the conceptual nature of these little models in two senses. The models introduce
concepts, iconography, and points of view of the system dynamics approach. In addition,
the models are designed to reflect the group’s own concepts of its problem in its systemic
context. (Richardson 2013, 42)
In the concept model script, the modeler/facilitator begins by saying that they are
going to introduce a concept model of the problem situation, that this concept model
is intended only as a way to introduce them to the concepts in system dynamics, and
that it is wrong and they will be asked in a few minutes what is missing or incom-
plete about the model. The modeler/facilitator then draws on a whiteboard, chalk-
board, or flip chart the concept model taking care to introduce each term, symbol,
and structure as they arise. When the first stock is introduced, the modeler/facilitator
goes to the side and introduces the concept of a stock and flow using the bathtub
metaphor (or similar metaphor depending on the cultural context) and then returns
to completing the drawing of the concept model.
The modeler/facilitator then shows a projected version of the same diagram in
the modeling software and reinforces the correspondence between the two. The
modeler/facilitator then runs several simulations to illustrate how these models can
generate dynamic behavior. Having established the correspondence, the modeler/
facilitator then returns to the whiteboard, chalkboard, or flip chart and asks partici-
pants what is wrong or incomplete with the model.
Participants are usually very quick to point out problems if they haven’t done so
already. As the different issues are identified, the modeler/facilitator draws the cor-
rections on the diagram and then chooses to either fix the current projected model
or pull up a new version that already has a correction. The model projected on the
screen is run several more times to illustrate the structure–behavior relationship.
References 37
The concept model script can be an especially efficient approach to introducing

the language of system dynamics in as little as 40 min and quickly give participants
a sense of the key concepts in system dynamics as well as overall arc of a modeling
project. The concept model script can also be an effective approach in situations
requiring translation if participants are comfortable with the use of computers. Done
well, the group is also highly motivated in discussing their problem in more detail.
One limitation of concept models is that they require some prior knowledge of
what the issue is in a way that will be relevant to stakeholders. This is hard to do
without some face-to-face meeting with the gatekeepers to identify what the poten-
tial issues of interest might be. Another limitation is that building the concept model
usually takes some system dynamics modeling skills and is therefore usually diffi-
cult to replicate in the community without support of an experienced system dynam-
ics modeler. There is also a risk, especially if the concept model becomes too
sophisticated, that participants will see the concept model as the start of the model
they are working on instead of as a teaching tool.
Conclusion
Both the graphs over time exercise and concept model exercise provide a way to
share with a set of community participants and gatekeeper what a group model
building exercise is, what we mean by a model, and how their participation can lead
to a model. It is not unrealistic at this stage that participants will, with the right
encouragement, take on the role of introducing these concepts to others who are
new to the process in the community. The following chapters describe each of the
three phases of CBSD in more detail.
References
Austin, J. L. (1962). How to do things with words (2nd ed.). Cambridge, MA: Harvard University
Press.
Freire, P. (2007). Pedagogy of the oppressed. New York, NY: Continuum.
Harding, S. (1991). Whose science? whose knowledge: Thinking from women’s lives. Ithaca, NY:
Horton, M and Paulo F. 1990. We make this road by walking: conversations on education and
social change. Edited by B. Bell, J. Gaventa and J. Peters. Philadelphia: Temple University
Press.
Myers-Scotton, C. (1993). Social motivations for code switching: evidence from Africa. Oxford:
Claredon Press.
Penelope, J. (1990). Speaking freely: Unlearning the lies of the fathers’ tongues. New York, NY:
Pergamon Press.
42–55.
Chapter 4
Problem Scoping and Identification
Theory is not inherently healing, liberatory, or revolutionary.

It fulfills this function only we ask it do so and direct our
theorizing towards this end.
(hooks 1994, 61)
Essentially, all models are wrong, but some are useful.
However, the approximate nature of the model must always
be borne in mind.
(Box and Draper 1987, 424)
Initial Conversations
An initial introduction from a colleague, a chance encounter at a meeting, a referral

from someone familiar with your work, or an invitation to give a presentation on
system dynamics brings you together with a few people in a room to exchange ideas
and explore a potential collaboration. Maybe you or they already have a pressing
issue that seems like it might involve systems, is complex, and could benefit from a
system dynamics approach. This may be a first meeting or a follow-up at the end of
a prior group model building project that engaged the community. Maybe it’s obvi-
ous at the end of the meeting what direction you should stake, or more likely, there
are a few more meetings to explore what a potential collaboration might look like
and assess if this is a good fit for system dynamics and group model building. What
should you be considering at this stage?
Problem scoping and framing is a critical stage for any project.1 Projects succeed
and fail on the basis of whether or not they achieve their intended purpose within the
available resources. This is especially true when considering projects that deal with
complex systems because the very nature of a complex system obscures our ability
to easily see and understand the system. Such problems rarely arrive isolated from
other systems and dynamics and frequently involve a mixture of a “soft” socially
1
There is a rich literature on problem structuring methods in working with client groups (for an over-
view, see Eden and Ackermann 2006, 2013), and group model building is among these (Andersen et al.
2007). In CBSD, one of the main ideas is that one engages communities and builds participation and
capacity through education over multiple projects so that the community can and is doing more problem
structuring on their own and within a project with participants in the GMB session.

40 4 Problem Scoping and Identification
constructed (Berger and Luckmann 1966) systems and “hard” systems constrained
by laws of nature.
Moreover, the motivation for solving complex system problems is usually the
highest when the problem needs to be solved within some fixed time frame, and
existing approaches have already been tried and failed or known to be unsuitable for
the problem at hand. So the initial conversation may have some urgency at least for
some in the room. At the extreme, urgency can lead to a desperate and indiscrimi-
nate search for any approach regardless of whether or not it has the potential to help.
There can sometimes be strong incentives and pressure to accept a project without
clearly scoping the issue and framing the problem for a potential modeling project.
This is a mistake that, unfortunately, happens more than it should. Projects poorly
scoped may never be completed or fail to satisfy the sponsors of the project because
the purpose was vague, the problem was never clearly defined, the boundary of the
model kept expanding, project timelines were unrealistically estimated, the end
result was not usable in the way originally intended, the skills of the modeling team
were insufficient or stretched too thin, or the purpose that the model could fulfill at
the end could ultimately have been completed in an easier way and lower cost
(Meadows and Robinson 1985).
Moreover, there are a wide range of choices in systems approaches and ways to apply
them which vary in their goals and ways of understanding the world (Jackson 2000;
Pidd 1998; Midgley and Ochoa-Arias 2004; Lane 1999). So assessing the presenting
issue and deciding on an initial approach are challenging to say the least.
There can, however, also be a significant opportunity to add value within the first
conversation if the one or more individuals in the room can quickly scope out the
problem and frame it appropriately. Such meetings, at their very best, help a group
take a problem that was overwhelming in its complexity at the start of the meeting
and transform the situation into something more manageable by the end and thereby
end on note of calm and enthusiasm for moving forward.
To do this effectively, it is helpful to have some conceptual frameworks for orga-
nizing information presented at the meeting and focusing the time on answering
critical diagnostic questions in Table 4.1, each of which will be discussed in more
detail in the next sections. The answers to these questions are then summarized in a
one-page modeling project description. As mentioned earlier, this is an internal
document that succinctly describes the potential modeling project that is used to
reflect back and revise understanding of the problem situation and proposed
approach.
What Is the Problem?
The first set of questions for the group in the room begins with identifying the pre-
senting problem and determining whether or not it is dynamic. The term “problem”
often triggers a range of reactions. Some see it as focusing the attention on deficits
What Is the Problem? 41
Table 4.1 Critical questions to consider before starting a system dynamics project
Question How is this answered
What is the problem? Is the Drawing a reference mode with the desired and feared behavior
problem dynamic? over time over a defined period of time
What kind of problem is it? Primary diagnosis as a learning, coordination, analysis, or
restructuring problem or combination thereof
Does the system involve Drawing a diagram of the system that involves one or more
feedback mechanisms? feedback loops
What kinds of insights Identifying the types of model-based insights such as visualizing
would help solve the the system or identifying leverage points that will help solve the
problem? problem
What is the purpose of the Write a model project description that defines the problem,
model? explains why it is dynamic and involves feedback, and clearly
states the purpose in terms of the type of insights that will help
solve the problem
What would be the added Identifying how the approach being considered would offer
value of the model? something above existing tools
as opposed to strengths, but in the context of system dynamics, the term is neutral
and merely refers to a situation one wants to improve. Moreover, the solution to a
problem in one situation can be viewed as a part of the problem in another. For
example, one organization can be focused on how to scale up an immunization pro-
gram to reach a given target, while another organization having already achieved
this is concerned about accelerating scale-up.
Another common objection to the term “problem” is that the problem has not yet
been defined or has multiple competing perspectives on what the problem is that
lead to a lack of consensus and conflict. For example, marginalized communities
often do not experience just one issue (e.g., access to local fuelwood, poverty, lack
of education, crime, discrimination), but multiple and often interacting issues. So
asking “What is the problem?” carries the risk of presupposing that there is a prob-
lem and biasing the conversation from the start.
What is important to keep in mind during the initial discussions and problem
scoping is, first, that the problem definition is generally always provisional, a work-
ing hypothesis about what the issue at hand might be, and, second, that there is
usually a problem to start with for the initial conversation to be happening in the first
place, so one should start with trying to understand what that problem is and see if
and how this fits with the system dynamics approach.
There is, of course, a third possibility that the meeting has been convened with-
out any clear issue to address. This is much less frequent, but it does happen. For
example, perhaps three is a conversation with a group that is in the early stages of a
community needs assessment where they do not yet have information about what
the community issues are. At least at this stage, there really is not a problem to pur-
sue using system dynamics.
While there may be interest or pressure to collaborate, one should resist this pres-
sure for two reasons. First, such situations almost always are symptomatic of a need
to first build more capacity with community partners before attempting to define a
problem that does not have relevance. And second, there is usually another situation
with a more clearly defined problem that has much more potential impact that could
benefit from the resources expended to continue searching for a problem.
So the best response when no clear problem emerges is to reframe the conversa-
tion to one focusing on a way to build capacity for identifying potential problems
suitable for system dynamics and keeping doors open for a future problem. This can
sometimes require sensitivity and diplomacy as the group realizes that this is not
leading into a system dynamics project. Part of the issue is that those with little or
no experience in system dynamics or group model building may not be able to see
why the project they have in mind cannot work and therefore take the reason as
something that is wrong with either them and their organization or you and the sys-
tem dynamics approach. When this happens, providing a range of low-risk opportu-
nities for them to learn more about the process including some that they can engage
in learning without you can be helpful.
Is It Dynamic?
Assuming that there is a problem of interest to focus on, the next task is to determine
if it is dynamic or not. A dynamic problem is one that involves altering a systems
behavior from one dynamic (the status quo or undesired pattern) to another dynamic.
Descriptions of the dynamic problem that will become the focus of a system dynam-
ics project are called reference modes (Randers 1980). While reference modes can
be verbal or graphical, being able to draw a reference mode in one or more behavior
over time graphs is a good litmus test to see if one is able to capture the essence of
a dynamic problem.
For example, Fig. 4.1 illustrates two different reference modes where the one on
the left depicts a situation where the focal variable of interest (percent of population
with access to clean water) is changing over time and includes both a historical
trend and a projected trend if things do not change, along with the desired behavior
pattern that represents a solution to the problem. The figure on the right depicts a
different situation where the focal variable of interest (number of children immu-
nized) is not changing over time and the desired behavior is shown as changing over
time. Note that in the figure on the right, the dynamic problem has a different time
axis and looks into the future with no historical data as one might view an immuni-
zation program before it is launched. The essence of a dynamic problem is then how
to intervene in a system through one or more leverage points2 to change the dynamic
from the status quo or undesired pattern to the desired pattern representing a
solution.
2
A leverage point is a place in a system where small changes can lead to big effects.
Is It Dynamic? 43
Percent of Population with Number of Children

Access to Clean Water Immunized
100% Desired 1 million Desired
Status
quo Status
quo
0% 0
2010 2013 2020 0 5
Year Year
Fig. 4.1 Examples of reference modes describing dynamic problem of access to clean water (left)
and childhood immunization (right)
A common mistake in drawing reference modes is to put some variable other

than time on the horizontal axis. Time should always appear on the horizontal axis,
although time can be calendar time, age, length of time in a hospital, or some other
measure of time that is appropriate for the problem at hand. The time period defin-
ing the problem is called the time horizon, and different time horizons imply differ-
ent dynamic problems. For example, school attendance viewed over the academic
year with ups and downs is a very different dynamic problem from one where school
attendance is viewed over the last 20 years with a gradual downward trend.
If time series data is available, it is tempting to define the reference mode in
terms of the numeric data. Some caution is in order when doing this. Properly
speaking, reference modes are abstractions, a way to view a problem, so including
all of the noise in a reference mode that might come with numeric time series is
essentially making a commitment to address not just the overall trends but also all
the variations over time (Saeed 1992). It is arguably much better to redraw the refer-
ence mode in a stylized form to make it explicit which features one is interested in
focusing on and which features one intends to ignore.
A second problem with using time series directly for the reference mode is a
temptation to define the problem in terms of available data as opposed to the prob-
lem one is really interested in working on. For example, in one project focusing on
understanding the social determinants of childhood obesity trends in low-income
communities, the social dynamics of interest span several decades, while the
numeric data that is available on obesity trends is unavailable for this particular
community. This is not unusual when it comes to marginalized communities as one
of the consequences of marginalization is that organizations and local and state
governments are less likely to collect data or make it available on the issues relevant
to the community.
This does not mean that one should not use empirical data such as time series to
support reference modes when data are available, but the emphasis here is on cor-
roborating the reference mode, not defining it. When numeric time series data is not
available, one might consider other strategies such as focus groups, “graphs over
time” exercises with community members, surveys that reconstruct historical trends
from time or dates of events, and the use of indirect indicators from secondary data.
Initially at this stage, however, the primary focus is usually on simply establish-
ing the problem as dynamic, and this is verified by being able to draw and agree on
the reference mode. If there is significant disagreement at this stage about the
dynamic problem, preliminary work in a community may be required to determine
the reference mode using existing data or collecting new data.
What Kind of Problem Is It?
Having a working hypothesis that the problem is dynamic, it is important to con-

sider what the most immediate barrier is to addressing the problem. This involves
problem framing and will ultimately inform the purpose of a model in a project.
Problem framing refers to the idea that how problems are defined has a lot to do
with the solutions being sought. This idea is not new, and many have discussed the
issue of appropriate problem framing as a key to successful modeling projects.
Burrell and Morgan (1979) developed a popular framework for classifying socio-
logical theories of organizations by their underlying paradigms of social science
and society. This framework was then used to locate the differences between soft
systems methodology and other methods (Checkland 1981), provide an overview
for critically selecting and integrating different systems approaches (Jackson 2000),
and show how system dynamics did not fit into any fixed socio-theoretic paradigm
(Lane 1999, 2001a, b).
Burrell and Morgan’s framework organizes theories and methods in the study of
organizations along two different dimensions. Figure 4.2 shows the adaption of
their framework to problem framing. This is a novel use of the framework in that a
problem and the main purpose of a model to solve a problem are considered from at
least four different perspectives to decide where to start in CBSD with a particular
project and how to sequence problem solving over a sequence of discrete group
model building projects each with its own purpose, which collectively lead to solv-
ing a larger community issue in a systematic way.
On the vertical axis, theories and methods are distinguished by how society is
viewed with status quo or regulation views at the bottom and radical change views
at the top. In this representation, problems are framed in terms of fixing or maintain-
ing the status quo at the bottom and as rejecting or replacing the status quo at the
top. Being at the bottom reflects a basic commitment to accepting the structure of
the system as it is, whereas being at the top is often associated with rejecting the
current system or seeking to restructure it in some fundamental ways.
On the horizontal axis, theories and methods are organized by their view of
social science. At the right are objective views of science that emphasize realism,
positivism, determinism, and nomoethic approaches to science. On the left side are
subjective views of science that stress nominalism, humanism, voluntarism, and
What Kind of Problem Is It? 45
Fig. 4.2 Framing problems and group model building activities across different paradigms of
society and social science. Adapted from Burrell and Morgan (1979) and Lane (1999)
ideographic approaches to science. Between them is a continuum of theories and

methods where the location determines the relevant criteria for evaluating the theo-
retical claims or the soundness of a method.
This framework can be used to broadly distinguish four types of problems: anal-
ysis problems, coordination problems, learning problems, and transformation prob-
lems. Analysis problems involve identification of leverage points, root causes, and
best or most robust ways to implement policies or interventions and find more effi-
cient ways of doing things and typically require the use of computer simulations to
support rigorous analysis. Many system dynamics modeling projects often fall into
this category. The “right answer” in an analysis problem is determined by how well
it objectively improves the existing system. There is usually a strong commitment
in analysis problems to working with existing and well-established measures of a
problem. The focus in analysis problems is often the technical analysis and getting
the correct answer. If the overarching concern for a group is going out to dinner and
finding the right restaurant, framing this as an analysis problem means finding the
answer that gets the group to the right restaurant in an optimal way, perhaps by
maximizing some joint utility function and calculating distances to different estab-
lishments. The role of modeling and participation in analysis problems is on improv-
ing the rigor of the analysis and better data of stakeholder perspectives.
In coordination problems, the focus is on developing a shared vision and consen-
sus on how to proceed. Coordination problems have the characteristic that the lack
of coordination is a larger determinant of the outcomes than accuracy or alignment
with the right technical solution. There are many cases of this where scientists and
experts have settled on what appears to be the right technical solutions through a
rigorous analysis, only to have the entire effort rejected because there was not suf-
ficient consensus among stakeholders to implement it. The exemplar of a coordina-
tion problem is where the conflict does more damage than having a suboptimal or
technically flawed solution.
In the case of a group going out to eat, the coordination problem manifests when
the argument over what is the best restaurant leaves people delaying from any action
so that the entire group is now hungry and faces a walk to the nearest eatery to
everyone’s dissatisfaction. As a coordination problem, developing a shared vision
or consensus solves the problem. The role of a model and participation in the coor-
dination problem is to develop shared understanding and consensus among all
stakeholders.
Both the analysis and coordination problems accept the structure of the system
as it is. Learning problems, however, focus on helping stakeholders develop and
apply their own models to solve problems by learning and modifying the system.
The goal here is both different in terms of the ontology and epistemology of the
model and the expectations for the types of change that might evolve.
The key criteria for a model and participation in a learning problem are not
whether the activities generated shared understanding or consensus, nor whether
they helped the group arrive at the technically correct answer through rigorous anal-
ysis, but whether or not they are using the models and their participation to learn
about the system in a way that is helping them solve the problem. Not all models
will do here, and models may be technically wrong but still quite beneficial if peo-
ple are learning how to model better, and with better modeling comes better insights
to improving the system. In the restaurant case, the learning problem would focus
on helping the individuals or subgroups develop a causal map whereby they could
understand the dynamics in a way that would help them learn how to reach consen-
sus so that everyone felt satisfied.
Like learning problems, transformation problems reject the status quo and seek
to restructure the system. What differentiates the learning problems from the trans-
formation problems in practice is that one is treating facts differently. In the trans-
formation problem, there is an objectively wrong system producing undesired
outcomes that needs to be changed. This often happens by restructuring the system
by adding or removing feedback loops or changing the stock and flow structure of a
system. In contrast, modeling in the learning problem may have little or no commit-
ment to objective facts of the system. In the restaurant example, a transformation
problem would reexamine the given structure of the problem (e.g., that the group
needs to go out to eat) and consider, for example, options for ordering food and hav-
ing it delivered to the hotel or conference center.
In our work, we have found it valuable to be able to frame problems in different
ways according to different stages of the project. For example, we might view the
initial phase of our work as primarily involving a learning problem, where we would
like our participants to become more comfortable using causal loop or stock-
flow diagrams in modeling situations, and we look for evidence that they are
actively engaged in revising models or spontaneously drawing their own structures.
What Kind of Problem Is It? 47
Later, we might focus on a coordination problem when we are trying to work with
diverse stakeholders to understand what might be a feasible set of solutions and later
as an analysis problem when we are building the simulation model and triangulating
the model with survey data and other information. Through the analysis, we might
then discover why the problem cannot be solved as is and seek to view the problem
as a transformation problem. In participatory modeling with diverse stakeholders,
paying attention to problem framing and how we might sequence activities helps
everyone be much more explicit about the goals for each stage of activity.
Moreover, at times, a problem might be best framed as in the middle of a con-
tinuum. For example, some situations call for balancing the need to solve a coordi-
nation problem with the need to develop a rigorous analysis of the system. The
utility of the framework in this type of situation is that it quickly focuses attention
on whether one should consider this as two separate projects (one as a coordination
problem, the other as an analysis problem) and then integrate the results or have a
single project that makes compromises between forming a consensus and rigorous
analysis.
Some have raised critiques about this approach to framing problems and sug-
gested that it would be better to select the appropriate systems method as opposed
to try and apply system dynamics to suite different types of problems. Indeed, this
seems to be the general trend in systems approaches to solving problems.
I do not disagree with the overall benefits and potential of an integrated or eclec-
tic approach if practitioners are able to build competence and expertise in multiple
methods or form multidisciplinary teams that are able to effectively coordinate
activities. Nor, to be clear, am I suggesting that every problem can be solved using
system dynamics. Quite the opposite, in fact, since I am arguing throughout this
book that system dynamics is suitable for a specific class of problems, namely, those
where the focus is on understanding how feedback loops generate dynamics. This
means that there are lots of situations where we should not be using system dynam-
ics, including when the primary focus involves social networks or the interactions
between individual actors and the rules they used to make decisions, which will be
covered in the next section.
What I am arguing is, however, building on David Lane’s (1999, 2001a, b) argu-
ments that system dynamics does not fall neatly into a functionalist sociological
paradigm and then extending this argument by saying that what differs is the pur-
pose of the model, not the use of system dynamics modeling. More precisely, what
changes when we consider a problem from functionalistic sociology to interpreta-
tive sociology to radical humanism and radical structuralism is not the system
dynamics method, but what we ask of it, specifically the purpose of a model. This is
what determines the criteria for a good model and establishes what counts as evi-
dence and impact and ultimately the success of the project.
There are also two practical reasons why taking this position is important with
CBSD. First, becoming proficient in even one method is a challenge in terms of the
training, experience in communities, availability of good supervision, etc. So the
likelihood that one can become proficient in multiple methods in a way that proves
to be effective in community settings seems somewhat daunting, though not
impossible. Second, in order for the training and results of having multiple projects
in a community accumulate over time, it is important that there is an underlying
coherent framework that allows the social learning and social capital developed to
be easily shared.
Does It Involve Feedback?
Having identified the problem, determined that it’s dynamic, and framed the prob-
lem, the next question is to see if this system involves feedback. In system dynam-
ics, all systems of interest involve feedback because of the endogenous or feedback
perspective in system dynamics (Richardson 2011). But, system structure and
behavior can also be understood from other perspectives. For example, when we
look at a given situation, we may see relationships and social networks or focus on
how the rules that people learn and use to make decisions explain system behavior.
These are different perspectives, and they may be more appropriate than focusing
on feedback loops. System dynamics, however, is about feedback loops, and so it is
prudent to establish how relevant a feedback explanation might be to understand the
problem situation. The easiest way to do this is sketch a causal loop diagram of the
feedback system and see whether or not one is able to provide an initial explanation
about what is happening from a feedback perspective.
What Kinds of Insights Would Help Solve the Problem?
The purpose of building models in system dynamics and involving people in the
process through group model building is to develop insights that change mental
models, which in turn lead to changes in decisions and alter the dynamics. The types
of insights that are needed vary, however, by the type of problem being considered
(e.g., learning problem, coordination problem, analysis problem, and restructuring
problem). Moreover, different insights call for different types of visual representa-
tions, informal maps, and formal simulation models.
Figure 4.3 depicts different levels of system insights, from awareness that there
is a system at the top to being able to rigorously explain why things happen in terms
of the structure of the system at the bottom. If asked what the system is, how com-
ponents are connected, where the leverage points are, why things happen, and so on,
most of us would be able to provide an answer by relying on our flawed mental
models of the system.
Modeling as an activity makes our mental models more explicit, replacing infor-
mal cognitive representations of a dynamic system with formal visual representa-
tions of system that function as boundary objects in group model building workshops.
However, the type of model required to develop the insight varies along with the
level of expertise, time, and hence cost to develop more formal models in a group.
What Kinds of Insights Would Help Solve the Problem? 49
Fig. 4.3 Different levels of system insights
Simply helping groups recognize that there is a system, the components that
constitute the system, or how the components might be related through feedback
can readily solve some problems. Such insights can be developed through system
pictures and diagrams. Moving further down the levels, recognizing how others
think about the system, where one might be able to intervene in terms of potential
leverage points, what transforming a system might mean by adding or removing
feedback loops or changing the material flows in a system, and recognizing generic
structures such as system archetypes (Senge 1990) can in many cases also lead to
changing mental models in a way that addresses the problem. However, developing
these insights typically requires more rigorous tools for representing the system
such as causal loop diagrams and stock and flow diagrams.
Moving still further down toward even deeper system insights involves develop-
ing more sophisticated and counterintuitive insights about a system. Understanding
the impact of accumulations and nonlinear relationships is cognitively challenging
for even the simplest of systems (Sterman 1989, 2002, 2010; Sweeney and Sterman
2007). Understanding which system structures can generate the dynamics and
which cannot usually develops through extensive involvement in the process of
building and testing simulation models. Determining where the leverage points are,
in contrast to identifying potential leverage points, often leads to another set of
counterintuitive insights and (Meadows 1999) also requires extensive simulation
testing and analysis to verify.
Many systems generate the same basic dynamics regardless of their initial condi-
tions or boundary conditions, but in some cases, this not true. For example, the cur-
rent prevalence of an infectious disease in a neighborhood may have little or no
influence on the spread of an infectious disease under certain conditions. However,

under other conditions, the current prevalence rate may determine whether or not
the spread of the infectious disease becomes an epidemic. Understanding when one
needs to focus more attention on establishing the current conditions versus when
this can be ignored can lead to insights that help us develop much more effective
public health surveillance and prevention programs. Lastly, gaining insights into a
system on which feedback mechanisms are driving the behavior patterns at different
periods in time can prove critical to knowing when and how to intervene in a system
as the influence of feedback loops shifts through one or more nonlinear interactions
(e.g., Ford 1999; Hovmand et al. 2009; Richardson 1995). Developing these deeper
levels of insights is so counterintuitive for even relatively simple feedback systems
that they require computer simulation models.
Given that the expertise, time, and cost of building a model to develop insights
generally increase rather significantly as one moves down from surface to deep
system insights, it is prudent to consider focusing activities on the insights that
appear to have the most potential for addressing the problem.
For example, if the primary problem at the moment is a coordination problem, to
what extent would an informal causal map such as a causal loop diagram or stock
and flow diagram suffice? This may be fine for many situation, but not if this is an
analysis problem and there is a need to identify the leverage points in the system
that have the greatest impact. In this case, one will need to build a computer simula-
tion model.
What Would Be the Added Value of a Model?
As the scope and purpose of a potential modeling project become clearer, it is useful
to ask what the alternative approaches would be and what is the added or compara-
tive value of system dynamics and group model building over these other approaches.
For example, it is not unusual for persons unfamiliar with group model building to
view group model building as another way to conduct a focus group. In such cases,
the information sought from the group model building session could be found from
conducting a focus group and lot more easily in terms of time and money. On the
other hand, if one of the key goals is to visualize the system and the interaction of
components through one or more feedback loops, then a group model building ses-
sion might be more appropriate.
Modeling Project Description
The modeling project description distills the conceptualization of the problem into
a one-page single-spaced summary that serves as an internal document to review
and build shared understanding and consensus for a potential project. It is
Modeling Project Description 51
Table 4.2 Example of a modeling project description

Early childhood initiative community design workshops
• The Early Childhood Initiative involves developing, implementing, and scaling a program
of services that will meet the needs of children from prenatal to age 8 in the city to achieve
measurable population level improvements in health and school readiness. This initiative
recognizes that there already exist organizations in the area that can provide evidenced-
based interventions and that the major obstacles to improving population level outcomes
involve the creation of an innovate program design that effectively coordinates the existing
programs to meet the needs of children.
• The primary purpose of this system dynamics model is to help design a strategy for
implementing a coordinated system of care that is innovative and meaningful to families.
Such a model should help the program leaders and partners visualize the major components
and how they are related and create unique meaning of what it means to be involved in the
Early Childhood Initiative over the next 20 years. The model will be at the strategic level with
an emphasis on involving families in the design of the strategy for implementing and scaling
up a coordinated system of care.
• To achieve this, a system dynamics model will be developed using participatory group
model building methods with approximately 20 community members. The primary goals of
workshops will focus on building leadership capacity with community members to help
design a strategy that leads to new, more meaningful experiences for parents and children
born in the city.
importantly for everyone involved to carefully review and make changes to the doc-
ument at this stage because this will essentially serve as mission statement or char-
ter for the modeling project should resources and agreements made to move on the
next step.
Table 4.2 provides an example of a modeling project description with many of
the key elements from the previous discussion included. It identifies the dynamic
problem as being one of developing, implementing, and scaling up a program of
services over a time horizon of 20 years and the major barrier as a coordination
problem. The purpose of the model as one that helps design a strategy for imple-
menting a coordinated system of care where the main insights sought is to help
program leaders and partners visualize components of the system and how they are
related.
The description defines the scope of the model as focusing on the strategic
level as opposed to operational level, the model will be built using a group model
building approach that involves community members, and the primary goal of the
community design workshop is to build capacity to help design the program. This
signals that there is also an aspect of this project that is framed as a learning
problem.
The terms “innovative” and “meaningful” appear throughout, and this reflects
the view the sponsor and partners have that it is not enough to just develop another
set of services or coordination system but that the goal here is more aspirational in
terms of design and that this is an explicit expectation of what the modeling process
will contribute.
Modeling descriptions can also include general expectations of resources, such
as a commitment from the partners and their role including recruitment of
participants and involvement in the design process. Modeling project descriptions

may also include expectations about the specific value orientation of a workshop.
For example, potential interventions should be evidence based or aspire to build
capacity for the partnering organization to independently conduct group model
building workshops in their communities.
If the opportunity arises and time permits, it can be helpful to wordsmith the
modeling project description with the potential sponsors and partners of the project
in a meeting using flip charts or a computer with a data projector. Once completed,
it provides a basis for subsequent discussions and can be used to generate internal
and external support for the project through subsequent proposals and bid.
Reasons to Discontinue at This Stage
There can be any number of reasons to discontinue or shelve a project. Ideally, the
time invested at this stage is minimal, and any party to the initial planning can with-
draw without losing face. One should be careful from the outset to explain to poten-
tial partners the process of developing a modeling project description as a means to
see if there is a potential project that is of mutual interest and that system dynamics
and group model building are not only approach nor the approach for every situa-
tion. The reasons for not continuing can vary from there not being a viable problem
to work with to the partner refusing to engage the process or imposing expectations
that are unrealistic given limited resources. Some of the most common reasons for
ending discussions or shelving the project are:
• Lack of a clearly defined dynamic problem involving feedback. Without a clearly
defined problem involving feedback, it is generally difficult and often inappro-
priate to continue.
• Poor fit between the problem of interest to the potential sponsor and methods.
For example, the sponsor may be interested in insights that could just as easily be
achieved through a focus group or is primarily concerned about the structure of
social networks in the community.
• Insufficient resources to complete the project within the given time. This can hap-
pen, for example, when the resources available would only support a small,
short-term project that did not include simulation modeling, but what is attractive
about system dynamics is the potential of doing computer simulation models that
would allow for what-if type of scenario analyses.
• No buy-in from key constituents needed to complete the project successfully and
implement the results. Sometimes it happens that the champion for a group
model building project cannot build the support needed to initiate or sustain
efforts that lead to a meaningful project.
• Lack of readiness of partners for engaging in CBSD. The reasons here can vary
and include lacking a basic understanding of the process, difficulty committing
to meeting logistics necessary for planning and execution of a GMB session, and
limited bandwidth within a partnering organization for engaging in new activi-
ties and learning.
References 53
• Failure to work within the expectations of the modeling project description.

Sometimes partnering organizations do understand or take seriously enough the
importance of the modeling project description and simply defer to the persons
trained in system dynamics and group model building under the assumption that
things can be changed later. While modifications to the modeling project descrip-
tion are possible, significant departures from the modeling description should
raise warning flags, for example, if the partners suddenly insisted on a computer
simulation model when the modeling description clearly stated that a causal map
would be developed. In such cases, it may be necessary to reconsider the
partnership.
The last but not insignificant point to make about the problem scoping and defini-
tion phase and development of a modeling project description is that the goal is not
to get every potential project converted into an active project with core modeling
team developing a group model building workshop. The goal of this phase is to
select the most appropriate projects given the resources available and readiness of a
community to engage in CBSD and will tend to vary over time as the community
partners become more familiar with CBSD through projects, workshops, and con-
versations about new potential projects.
Conclusion
In this chapter, we have started with the initial conversations with community part-
ners and the types of questions someone should be considering in conceptualizing a
potential system dynamics project and then introduced several conceptual frame-
works for organizing information and asking questions during this meeting. The
goal has been to provide a foundation for weighing the different choices one must
consider in the formation of a potential project and then summarizing those choices
into a modeling project description. This problem scoping and definition phase may
end without materializing into project, by being shelved because either there is not
a well-defined dynamic problem involving feedback loops to work with, the meth-
ods are not a good fit, or the community partners are not ready for engaging in
CBSD at this time. The next chapter will take up the process from the point of a
group having secured the agreements and resources to proceed beginning with the
formation of the core modeling team.
References
Andersen, D. F., Vennix, J. A. M., Richardson, G. P., & Etiënne, R. (2007). Group model building:
problem structuring, policy simulation and decision support. Journal of the Operational
Berger, P. L., & Luckmann, T. (1966). The social construction of reality: a treatise in the sociology
of knowledge. Garden City, NY: Doubleday.
Box, G. E. P., & Draper, N. R. (1987). Empirical model-building and response surfaces.
New York: Wiley.
Burrell, G., & Morgan, G. (1979). Sociological paradigms and organizational analysis: Elements
of sociology of corporate life. London: Heinemann.
Checkland, P. (1981). Systems thinking, systems practice. Chichester, UK: Wiley.
Eden, C., & Ackermann, F. (2006). Where next for problem structuring methods. The Journal of
the Operational Research Society, 57(7), 766–768.
Eden, C., & Ackermann, F. (2013). Problem structuring: on the nature of, and reaching agreement
about, goals. EURO Journal of Decision Process, 1, 7–28.
Ford, D. N. (1999). A behavioral approach to feedback loop dominance analysis. System Dynamics
Review, 15(1), 3–36.
hooks, b. (1994). Teaching to Transgress. New York, NY: Routledge.
Hovmand, P. S., Ford, D. N., Flom, I., & Kyriakakis, S. (2009). Victims arrested for domestic
violence: Unintended consequences of arrest policies. System Dynamics Review, 25(3),
161–181.
Jackson, M. C. (2000). Systems approaches to management. New York, NY: Kluwer Academic/
Plenum Publishers.
Lane, D. C. (1999). Social theory and system dynamics practice. European Journal of Operational
Research, 113, 501–527.
Lane, D. C. (2001a). Rerum cognoscere causas: Part II–Opportunities generated by the agency/
structure debate and suggestions for clarifying the social theoretic position of system dynam-
ics. System Dynamics Review, 17(4), 293–309.
Lane, D. C. (2001b). Rerum cognoscere causes: Part I-how do the ideas of system dynamics relate
to traditional social theories and the voluntarism/determinism debate? System Dynamics
Review, 17, 97–118.
Meadows, D. (1999). Leverage points: places to intervene in a system. Hartland, VT: The
Sustainability Institute.
Meadows, D. H., & Robinson, J. M. (1985). The electronic oracle: Computer models and social
decisions. System Dynamics Review, 18(2), 271–308.
Midgley, G., & Ochoa-Arias, A. E. (Eds.). (2004). Community operational research: OR and sys-
tems thinking for community development. New York, NY: Kluwer Academic/Plenum
Publishers.
Pidd, M. (1998). Computer simulation in management science (4th ed.). West Sussex, UK: Wiley.
Randers, J. (1980). Guidelines for model conceptualization. In J. Randers (Ed.), Elements of the
system dynamics method. Cambridge, MA: Productivity Press.
Richardson, G. P. (1995). Loop polarity, loop dominance, and the concept of polarity. System
Richardson, G. P. (2011). Reflections on the foundations of system dynamics. System Dynamics
Review, 27(3), 219–243.
Saeed, K. (1992). Slicing a complex problem for system dynamics modeling. System Dynamics
Review, 8(3), 251–261.
Senge, P. (1990). The fifth discipline. New York, NY: Currency Doubleday.
Sterman, J. D. (1989). Misperceptions of feedback in dynamic decision making. Organizational
Behavior and Human Decision Processes, 43(3), 301–335.
Sterman, J. D. (2002). All models are wrong: Reflections on becoming a systems scientists. System
Sterman, J. D. (2010). Does formal system dynamics training improve people’s understanding of
accumulation? System Dynamics Review, 26(4), 316–334.
Sweeney, L. B., & Sterman, J. D. (2007). Thinking about systems: Student and teacher conceptions
of natural and social systems. System Dynamics Review, 23(2/3), 285–312.
Chapter 5
Core Modeling Team Planning, Training,
and Capacity Building
Forming a Core Modeling Team
One of the first questions to consider in the second phase of a CBSD project is who
should be on the core modeling team (CMT). The primary task of the core modeling
team is to design the group model building workshop or set of workshops over the
next four to five 2-hour meetings. The CMT is generally a small team of 5–7 people
at most, although there are times when CMTs get to be large with multiple partnering
organizations all wanting to participate. This can become unwieldy and detract
significantly from the efficiency of the planning process. A better approach in these
circumstances is to suggest that the CMT function as a working subgroup and report
back with periodic progress reports on how the design and planning process is going.
In terms of who should be on the CMT, it is important to have individuals who
are in a position to anticipate how various community members from different
stakeholder groups might respond to exercises, know the local language and cus-
toms, have some sense of what would be meaningful deliverables at the end of a
workshop, and be able to identify potential issues related to power dynamics and
cultural appropriateness of the activities. It is also essential that each person on the
CMT is someone who will raise questions and challenge assumptions about the
design and process, as opposed to deferring to the system dynamics experts in the
room. It is often ideal to have representatives from various stakeholder groups from
the community, but if this is not feasible, people who can serve a proxy such as
direct service providers and community organizers are often a good choice.
Introducing Core Modeling Team to System Dynamics

and Group Model Building Process
The first meeting of the CMT generally consists of an introduction to system dynam-
ics, group model building, the role of the CMT, and process for planning the GMB
workshops over the following four sessions. Members of the CMT may already

56 5 Core Modeling Team Planning, Training, and Capacity Building
have had some exposure to system dynamics and group model building from
previous workshops and, in some cases, served on a CMT prior to the current proj-
ect. If this is the case, then one can usually move into the next step of planning.
However, unless everyone has already attended the same workshop or observed
similar exercises, it is usually beneficial to demonstrate a group model building
exercise and provide an example of a model. At some point during this meeting, the
modeling project description is reviewed by the CMT to ensure that the entire team
is clear on the purpose of the model and expected outcome from the project.
Developing a Common Language
One of the core design and planning functions of the CMT is to work out the specific
terms that will be used during the work and how these will be translated if working
in a different language than the local community. Should we use the term interven-
tion point or leverage point? What is the best translation of “feedback loop” in
Telugu? Can we use the bathtub metaphor for introducing a stock? What is the best
translation of “buffer” in Spanish?
Although the need for translation is obvious when working in a different lan-
guage than the local community, one should not overlook the importance of recog-
nizing that words have different conations in different communities. The term
“system,” for example, can have a technical and neutral meaning when working
with a group of scientists or engineers but mean something quite different when
working in a community that has been marginalized and something else to a person
with a serious mental illness who has to navigate a bureaucratic maze just to get
their medications adjusted.
Developing Process Maps
The second meeting of the CMT usually focuses on identifying the stakeholder
groups within a community one wants to engage in the process along with a
sequence of one or more group model building workshops. Sometimes the choice is
relatively easy when the sponsor of a project is already clear about wanting to
include a specific set of participants in the workshop. But often, the question facing
the CMT is who should be involved and how.
One approach that is especially effective is to use the process map script that
builds on the work of David Straus (2002) for designing effective collaborations.
Figure 5.1 shows an example of a process map. The process map shows the progres-
sion of meetings and workshops across time. Each horizontal band represents a
different set of stakeholders, and each vertical band represents a different phase of
the project. Each circle or oval represents a meeting or group model building
session. A shape that spans three groups (e.g., universities, hospital, and provider)
Developing Process Maps 57
Project Planning GMB I GMB II

Phase Partnership and initial Participant program design
program design workshops workshops
Time period
Community
Core modeling
team
Universities
Hospital
Providers
= Focus groups
= Community design workshop
= Core modeling team (responsible for design and facilitation of PPIP design workshops)
= Core modeling team (responsible for design and facilitation of community design workshops)
= Provider partnership and initial program (PPIP) design workshop
= Steering committee/advisory committee
Fig. 5.1 Example of a group model building process map
indicates that all three groups meet in the same workshop session. It is usually help-
ful to also include other meetings such as focus groups or core model team meetings
explicitly. Additional features of a process map can include calling out specific
deliverables or products from each session and dependencies between sessions.
In the process map script, each member of the CMT generates a list of potential par-
ticipant types (e.g., service providers, teachers, students, clergy) with one type of partici-
pant per sheet. Then, the facilitator asks the group to sort their list of potential participants
into a pile with the most important on top and asks them to share one at time in a round-
robin fashion. As the facilitator does this, a wall builder clusters the sheets of papers into
groups. The wall builder then describes each cluster and the reasoning behind it and asks
participants if these clusters make sense. Each cluster gets a name written on a sheet of
paper, and these are placed on the left side of a wall (see Fig. 5.2).
At this stage, the CMT discusses the best way to organize the sessions including
how many sessions, whether there should be one large opening session across
groups or several parallel sessions, if the sessions should be sequenced or phased in
a certain way, and if the sessions should be contiguous as in a 2- or 3-day workshop
or time separated. Examples from other process maps from other projects might be
used as samples to help the CMT visualize their options.
Fig. 5.2 Example of process map script during a core modeling team meeting in the West End
childhood obesity project
Usually the main design constraint is the availability of participants and the fre-
quency they can realistically be expected to be involved in a group model building
workshop. A short 120-min workshop is realistic for most community members,
and so then the question becomes if one designs the process to involve a set of one-
session workshops with different groups or a workshop series with the same group.
In other cases, one may decide it is better to have several daylong workshops.
As these different approaches are considered, the facilitator begins to draw out
the workshop sessions on the process map and revises the process map as the con-
versation evolves. At the end of the session, the facilitator reflects back what has
been discussed to make sure that everyone is on the same page. A picture is taken of
the resulting process map, and then the process map is redrawn on the computer.
Developing an Agenda
Once the CMT has developed the process map, the next step in the third meeting
is to develop a detailed agenda for each group model building workshop. This usu-
ally starts with a general sketch of what each workshop agenda might look like
with the persons experienced in group model building sharing different exercises
that might work given the overall goals of the project. Attention is paid to the
convergent-divergent structure of the session, how the outputs from one activity
provide inputs for the next activity, and team roles required to successfully execute
the workshop.
After the meeting, a detailed agenda is frequently drafted based on the CMT
discussion. The detailed agenda describes the timing, name of the activity, and a
more detailed description of who is doing what during each activity. This is then
used to draft the facilitation manual, which contains the modeling project
Rehearsal 59
description, detailed agenda, list of team roles needed for the workshop(s), and each
script in the order that it will be used in the workshop. This is then distributed to the
CMT for review.
Adapting and Developing Group Building Scripts
The fourth meeting of the CMT focuses on reviewing the detailed agenda, draft
facilitation manual, and scripts to ensure that the overall design works, the activities
are culturally appropriate, and the language is clear. A good way to start this meet-
ing is to have the person who is leading the CMT and essentially functioning as the
“choreographer” of the workshop talk through the detailed agenda from top to
bottom.
This is where the CMT usually determines the language for specific prompts and
reviews the language for additional questions and clarifications that might be
needed. For example, the CMT may decide that it is important that the community
facilitator ask participants a couple of questions to check their understanding or use
of a key term. What is critical to note here is that probably more important than the
actual facilitation manual and language is that the CMT is developing criteria for
facilitating the session, how to support each other if they need help, when and how
to improvise, and so on.
During this meeting, it is normal for the CMT to discover one or more problems
in the workshop design such as the sequence of activities being wrong or a need for
a new activity or script. Several ideas may be sketched out and then assigned to
someone to draft a new script.
Planning the Training
The fifth meeting generally consists of reviewing the facilitation manual, finalizing
team roles, developing a training agenda, and scheduling the rehearsal session, loca-
tion, and time. Often members of the CMT take on facilitation roles and by default
become the facilitation team, but for some, this ends their formal participation in the
planning phase on the CMT.
Rehearsal
It is difficult to overstate the importance, especially for new teams inexperienced in

group model building, to schedule and go through a rehearsal of the group model
building workshop. The rehearsal provides both a chance for the facilitation team to
practice walking through the workshop and also another opportunity to discover
problems that originally went unnoticed. For example, the plan may have originally
called for the facilitator to hand the sheets of paper from the graph over time script
to the wall builder. However, during the rehearsal, the facilitation team realizes that
this will not work given the room layout. Other issues to consider at this stage also
include the availability and placement of electrical outlets if electricity is used (and
then a backup plan if there is a power outage, which is common in many settings
around the world). Lastly, the rehearsal is most effective if the team physically
walks through the exercises as if they are doing the actual workshop.
Teams with little or no experience can, with adequate preparation and rehearsal,
execute a workshop that is well choreographed with smooth transitions and enough
flexibility to handle the inevitable deviations that require improvisation (a fire alarm
halfway through a session, easel falling down, humidity causing a wall of graphs
over time to slip one by one).
If the project consists of a workshop agenda replicated across several different
groups, only one training is needed. However, if different workshop agendas are
involved, it can be useful to allot time before each session to review the room layout
and rehearse the choreography of the workshop.
Conclusion
This chapter has provided an overview of the planning and design process over the
course of five CMT meetings, from initial introductions to preparing the training of
the facilitation team. Process maps have been introduced as tools for designing
effective collaborations along with the use of detailed agendas and facilitation man-
uals for designing the specific activities. This structure is intended to serve as a
foundation to work from that core modeling teams may decide draw on as needed
or adapt to existing approaches for planning a workshop. The next chapter covers
the actual facilitation of group model building sessions.
Reference
Straus, D. (2002). How to make collaboration work. San Francisco, CA: Berrett-Koehler
Publishers.
Chapter 6
Group Model Building Workshop
and Facilitation
It is only when she is on the other side and the shell cracks
open and the lid from her eyes lifts that she sees things in a
different perspective. It is only then that her consciousness
expands a tiny notch, another rattle appears on the rattlesnake
tail and the added growth slightly alters the sounds she makes.
Suddenly the repressed energy rises, makes decisions connects
with conscious energy and a new life begins.
(Anzaldúa 1987, 49)
Setting the Frame
Anzaldúa reminds us of what it feels like when you can see things in a different light
and make new kinds of decisions. We need to keep her words in mind when we
consider what it is we are asking people to do and what the benefits might be when
working with communities. Fundamentally, we are offering people a different way
to look at things, and that can be a gift and something terrific, but getting there can
be frustrating, disorienting, and confusing. The meanings of words that were per-
fectly clear a few hours ago can seem lost in a haze, while new, foreign tools are
being offered to help guide the way. Seeing others get it while you don’t raises self-
doubt and shame.
The psychologist Robert Langs (1998) used the term “frame” when referring to
physical and emotional context that allows a client to open up to viewing and chang-
ing their life. For Langs, the frame included everything from the physical layout of
the room, furniture, and credentials on the wall to how the therapist related with the
client. It is worth pointing out that despite all the research into specific treatments
for mental illness, the single largest component of effective therapies are what are
called nonspecific treatment effects (Lohr et al. 2003) such as the attitude of the
therapist toward the client, sense of unconditional positive regard, trust, authentic-
ity, and respect. That is a stunning fact for it means that despite all the medications
and treatment protocols, the single largest determinant of a positive outcome is
about how we relate to each other.
While group model building is not therapy, Vennix (1999) made a similar claim
about group model building—that the most important factor, more so than skill, is

62 6 Group Model Building Workshop and Facilitation
having the right attitude. So this chapter is about understanding what and how to set
the frame, from preparing the physical setting and layout of the space to group
facilitation and all the way through the end of a group model building session.
Preparing the Physical Setting and Layout
Group model building workshops can be conducted in a wide variety of settings,

from rooms specifically designed for conduct group model building workshops to
classrooms, conference rooms, community meeting spaces, people’s houses, and
outside venues such as a field or under a tree. Even when one has a room specifically
designed from group model building, it is critical to take the time and arrange the
physical setting in a way that is conducive to group facilitation.
Some aspects of this include establishing the front of the space where the facili-
tators will be, where the participants will sit (e.g., in clusters or in more of a
C-configuration), and where other members of the modeling team including transla-
tors, recorders, and modelers will be in relation to participants (sitting with the
group or outside a circle).
For the facilitators, it is important to anticipate how physical space can be used
to open up communication within the group by stepping out, regain control by step-
ping into the group, or more directly take control from a specific participant by
moving toward the participant. Along the same lines, it is beneficial to be able to
maintain line of sight with other team members and discuss how the team will com-
municate during the workshop (e.g., use of hand signals, nonverbal cues the team is
familiar with, written notes).
If walls are to be used for certain exercises (e.g., graphs over time script, hopes
and fears script), which ones can be used and work most effectively? Sometimes
rooms are decorated with posters or pictures or have wall treatments that the hosts
would generally be offended if suddenly decorated with lots of paper and blue
painters tape. In these cases, can one use the windows in the room, a portable white-
board, a flip chart on an easel, or find some other arrangement?
It is also useful to think about how the flow of the workshop will correspond to
the products that appear over the course of a workshop. If possible, it can be effective
to arrange products along a continuum of the wall from start to finish. For example,
one might post the results from the “hopes and fears” script at the left corner, graphs
over time script in the center, the reference mode to the right of the graphs over time,
the causal map to the to the right of the graphs over time, and so on until one has the
last product of the workshop at the right corner of the room. This provides an easy
way for a reflector or facilitator to summarize the session and what happened by
reviewing the products on the wall in the sequence they were produced.
If laptop computers and data projectors are to be used during the session, one
should consider where people will sit in relation to the outlets, if extension cords are
needed for the computers and data projector, and whether or not team members
need tables to work on that might affect other room layout decisions. If a data
Facilitating Group Process of Managing Boundary Objects 63
project is used, it can be helpful to have the person with the computer sit behind or
at the furthest distance from the screen so that problems with small fonts can be
detected and fixed in the session, as opposed to having the person working the com-
puter sit in the front of the room.
It is common to have refreshments or food available during a workshop in a com-
munity, so one should also consider where to place the food and whether or not this
will interfere with the flow of the workshop.
In unfamiliar community settings, it is always good to ask where people meet
and what the customs are for a meeting. Do people tend to meet under a particular
tree? Is there a specific way that chairs are normally arranged and should they
remain that way or can they be rearranged? Will there be distractions from other
meetings or activities during the session? For these reasons, it is often prudent for
the facilitation team to visit the space before the day of the workshop to get a sense
of space and how it might be used, which can be combined with a rehearsal of the
workshop. Other options include asking someone to take a picture of the space or
provide a map of the room layout if possible.
One should not go by standard room capacity to determine the suitability of a
room for group model building. The movement within a workshop around the room,
placement of facilitation teams outside the participants, and interaction among
participants can generally require 20–30 % more space than a room is designed to
accommodate in conventional seating arrangements.
Setup and Takedown
The facilitation team should generally arrive well in advance of the actual workshop
to prepare the physical space and then be ready to start before the first participants
arrive. In order for facilitators to effectively use space during the workshop, the
facilitators’ positions in relation to participants need to be established before the
first participants arrive. It is awkward to say the least to have to ask participants
arrive, sit down, and then ask them to move after you have rearranged the room.
The team should also allow time for participants to linger after the workshop,
take down materials that have been used if they are not to be left there, and restore
the room to its original condition. The overall implication of this is that a space
often needs to be available for the facilitation team at least an additional 2 hours
(one before and one after) the actual workshop time.
Facilitating Group Process of Managing Boundary Objects
Effective group model building teams recognize and manage the role of boundary
objects in relation to the participants’ mental models, principles of system dynamics
modeling, and previous boundary objects. Richardson and Andersen have
Fig. 6.1 Managing the group process around boundary objects (redrawn and adapted from
Richardson and Andersen 2010, 6)
articulated this most clearly as shown in Fig. 6.1. Recall that in system dynamics,
boundary objects are social constructions of system dynamics visual representa-
tions such as graphs over time, causal loop diagrams, and stock and flow diagrams
(Black 2013; Black and Andersen 2012; Black et al. 2004).
Andersen and Richardson (2010), Richardson and Andersen (1995) have stressed
the importance of team roles, which can be mapped into the three zones for the
modeling team shown in Fig. 6.1. In CBSD, the modeler-facilitator, community
facilitator, and process coach focus their attention on managing the connection
between the participants’ mental models and the current boundary object. The mod-
eler focuses on managing the connection between the current boundary object and
principles of system dynamics. And, the recorders and production coordinators are
focusing on remembering the current and already completed boundary objects.
Additionally, because the intent in CBSD is also strongly focused on unobtru-
sively teaching principles of SD for the expressed purpose of enabling participants
to describe and work more effectively with boundary objects based on SD modeling
principles, one should expect that there is gradually more overlap between the
boundary objects being generated by participants and SD modeling principles as
shown in Fig. 6.2.
A separation of any of the three main connections represents a breakdown of the
group model building process and needs to be assessed and restored by an interven-
tion from the facilitation team. Hence the facilitation team needs to be monitoring
each connection continuously during the workshop and watch out for one of three
failure modes. First, visual representations may begin to lose their connection to SD
Fig. 6.2 Increasing capacity of participants in CBSD to generate and contribute to boundary
objects with SD modeling principles
Fig. 6.3 Failure of visual representation when boundary object no longer represents SD modeling
principles
modeling principles if participants start to draw diagrams that no longer reflect SD

modeling principles as shown in Fig. 6.3. This can happen, for example, when par-
ticipants drop conventions of causal loop diagrams or stock and flow diagrams or
draw graphs without a time dimension.
Fig. 6.4 Failure of visual representations when boundary object no longer represents participants’
mental model of the dynamic system
Second, the participants may lose connection to the visual representation as shown
in Fig. 6.4. This can happens when a facilitation team fails to keep continuity from one
diagram to the next, or if what is presented to the participants is mainly the product of
the modeling team. It can also happen when participants are unable to express or see
their mental models visually using the conventions of system dynamics.
For example, in some of our early work in rural India on natural resources with
Foundation for Ecological Security (FES), the role of institutions plays a central role
in how the nongovernmental organizations work with villages. Our initial tendency
was to start with the natural resources systems such as watersheds or forests to intro-
duce concepts from system dynamics. This had worked when involving farmers, but
the staff did not see how institutions could be represented with the conventions we
provided from SD. So the tendency was for the conversations and ownership with
staff to either break down because the visual representations lost their SD principles
as in Fig. 6.3, or they could not relate to the SD diagrams of institutions we generated
as in Fig. 6.4. It took several years of capacity building fieldwork in transdisciplinary
teams with villagers before we developed the capacity to create visual representations
of institutions that could function as boundary objects.
A third way that the role of boundary objects can fail in group model building
happens when continuity has been lost between the visual representation and the
already completed boundary objects as shown Fig. 6.5.
This can happen for a variety of reasons including failing to adequately record
and store the visual boundary objects, insufficient documentation on the group’s
conversation related to the boundary object, major transformations of the model,
failure to distribute deliverables in a timely manner, and long delays between ses-
sions with no interim interaction with participant groups.
Fig. 6.5 Failure of visual representations when boundary objects lose their connection to previous
boundary objects
Lastly, in CBSD, failure to see learning over time along the lines of Fig. 6.2 also
represents a failure mode. When this happens, the participants essentially increase
their dependency on the modeling and facilitator and modeler. To see this, assume
that the project in terms of informing a policy decision has been wildly successful
and met with great enthusiasm from the community. They implement the recom-
mendation and the problem is solved. However, over time new problems emerge, or
the situation has changed in a way that they need to revisit the previous project.
Having seen the success, they don’t approach the next project in the same way as the
first. They now see the value of the modeling and demand more from the expert
modeler, and because they are in not better position to do the work than before, their
dependency on the modeler has increased.
To be clear, the expectation that I am putting forward with CBSD is not that
everyone should become an expert system dynamics modeler. What I am pointing
out is that if I leave the community with the same SD capacity as when I came, they
may have solved the problem, but only by increasing their dependency on me as an
expert if I don’t do something else.
However many incremental steps it takes, increasing their capacity to do SD is
what needs to happen to avoid a situation where they become increasingly depen-
dent on an outside expert to solve problems. There are many ways to do this, from
creating opportunities in workshops for participants to get hands on practice draw-
ing diagrams, thinking through formulations, building simple structures from a
casual map, providing encouraging feedback on their use of diagramming conven-

tions and sketching of reference modes, providing opportunities for them to work in
small groups and present stories about structure–behavior relationships, and so on.
A great way to help people who are interested in learning more is to invite them to
be a part of the core modeling team in designing and planning a group model building
workshop, take on a facilitation role, or lead a group model building exercise.
Moreover, these opportunities are mutually reinforcing. One can also help identify the
people in the community or organization who pick up and can explain SD principles
to others in the community using their own examples, and identify students and teach-
ers in local schools and university to develop learning opportunities on projects in
their community. These are not great leaps, but in a workshop with facilitation also
directed at educating and lots of continuous face-to-face interaction, the small insights
and peer-to-peer learning start to add up. Accumulation is a powerful concept.
Guiding Principle
For any given workshop session, there should be a well-defined set of objectives
that are understood by all members of the facilitation team. That is, what are we
expecting to achieve at the end of the workshop? For example, the goal may be to
have a reference mode that everyone can agree to or an initial causal map. Goals can
also be intangible, for example, to have participants understand the notion of a
leverage point or to participants motivated to build a simulation model or to have
participants understand what a model is.
To achieve the goals set for a particular group model building session, the facili-
tation team will need to shape the group behavior of the participants to achieve these
goals. Preparing for the workshop involves knowing what these behaviors are and
identifying the one or two guiding principles that can be used by the facilitators to
shape the group behavior. There should be only be a few guiding principles, and
they should be short and easy to remember without having to refer to a sheet of
paper. Examples of guiding principles for a workshop session might be “Get them
talking about their issue” or “Get them to describe feedback loops.”
Facilitation
Group facilitation is both an attitude and a skill that can take a lifetime of training
and practice to perfect (Vennix 1999):
The right attitudes are critical, more critical than the required skills. It is sometimes
overlooked that the most important characteristic for a facilitator is a helping attitude.
(Vennix 1999, 389)
Facilitation 69
Vennix (1999) goes on to describe the characteristics of a facilitator who has the
right attitude: as someone who has a helping attitude; is neutral with respect to the
content of the discussion; is inquiring and curious about how people perceive and
interpret situations and how and why they define situations as problematic; asking
questions rather than providing answers; does not teach, but fosters reflection and
learning; has integrity; and is authentic with the group.
Observing and experiencing the benefits of a great professional facilitator or
group clinician can be an amazing experience. Most of us will not become profes-
sional facilitators. Some will have more experience or feel more natural in the role
of facilitation, but that does not mean that we cannot facilitate a workshop.
Good facilitation helps keep the conversation going, encourages even participa-
tion, and helps the group stay focused. Good facilitation also involves recognizing and
managing conflicts that can arise in groups around different agendas and individual
personalities. With the right planning, training, and support, most of us can learn to
become good and effective at facilitating group model building workshops.
It is important to recognize that good facilitation is a physical interaction with
participants in the room including both verbal (what we say and write) and nonver-
bal behavior (our expressions, body language, where we stand in relation to others)
and shaped by how we use our body and voice in the room. For example, the effects
of standing next to a participant who is seated can have very different effects
depending on how tall the facilitator is.
How people perceive us and who we are also shape the interaction with partici-
pants. We can’t change who we are, but we can take the time to consider how we
might be perceived in a group might affect the dynamics, and in turn, things we
might do to alter perceptions. One obvious example is how we dress for a workshop.
What might be appropriate for a professional workshop or retreat in one community
can be seen as distant or trying to establish superiority in another. One should not
underestimate how subtle cues shape perceptions.
I often wear professional clogs in teaching and workshops, partly because they are
comfortable for standing all day in a workshop, but also because I grew up in Denmark
wearing clogs. I started regularly wearing clogs in Michigan during the winter after
my son born and in daycare to solve the problem of taking my shoes on and off while
carrying him in one arm, backpack with his things on the shoulder of the other. Yet I
have been surprised by how many times in certain workshops someone who was skep-
tical about the approach has remarked on my clogs and opened up a conversation.
It is also important to recognize that what might work effectively for one person
won’t for another. Along similar lines, being perceived as an authority on the topic or
substantive expert can have different effects depending on the participants. The role of
a facilitator is generally not to be a substantive expert on the topic being discussed,
and injecting one’s own expertise on the topic during a discussion can interrupt the
flow of conversation and sharing of ideas. However, there are cases when being a
substantive expert can enhance the effectiveness of a facilitator. For example, in a
workshop with physicians, having a facilitator that the physicians can recognize and
identify with can enhance communication within a workshop of physicians.
General Facilitation Tips1
For some new to facilitation or group model building, here are some general tips
that have proved useful over the years to share with the facilitators of the core mod-
eling team:
• Connect with participants. Before the session starts, try to connect with partici-
pants in the room. Whether you know the participants or not, greeting and estab-
lishing a connection with participants makes it easier to draw in participants later
and helps establish you as someone who can be neutral and fair with the partici-
pants in the room. Learn and use their names.
• Stay neutral and balanced. Focus on staying neutral and balanced. Your role is
not to advocate a particular position or share your expertise on the topic being
discussed but to facilitate a discussion where different opinions can be shared.
Sometimes this means making sure everyone has a chance to speak and recogniz-
ing different opinions (e.g., paraphrasing the different points of view that have
been raised). However, it can also mean interrupting someone who is pushing his
or her agenda and not listening to others (e.g., “So you’re bringing up [state their
position]. Could you push that further and relate it to what [another position that
is raised by someone else]?”).
• Use physical space. Arrange and use the physical space in the room to help man-
age conversation flow. For example, if someone is dominating the conversation
and you need to bring in other speakers, walk toward the group and invite other
opinions (e.g., “Are there other thoughts on this?”). Likewise, if the group is hav-
ing a great discussion and you want to encourage the conversation flow, step
away from the group.
• Work the room during small group exercises. Small group exercises are not a
time to take a break. Work the room. The small group exercises are a great oppor-
tunity to connect with individual participants during the session (e.g., by asking
participants if the directions are clear, providing positive reinforcement to the
groups, etc.).
• Point and name. Many activities in group model building involve clusters on a
wall, diagrams with variables and linkages, boundary objects generated during
different stages of a workshop, and so on. When referring to something in the
room, point to and name the object in the room. For example, if referring to the
reference mode, point to the actual reference mode hanging in the room to rein-
force the connection. Or if reviewing a clustered set of “hopes and fears,” point
to a cluster and summarize the theme of the cluster, then go onto the next cluster
and summarize that theme. If describing a structure–behavior relationship, point
to the structure and say, “this structure” and then move over to the behavior time
1
This list is based on a list originally developed by Amy Schneider and me as part of the Rise,
Sister, Rise project sponsored by the Ohio Department of Mental Health with a grant from the
Substance Abuse and Mental Health Services Administration (SAMHSA, grant number
5U79SM057460-04).
Facilitation 71
graphs and say, “produces this behavior.” This might sound trivial in one sense,
but just showing a PowerPoint slide with some structure and dynamics and say-
ing “This is the dynamic hypothesis” does help someone to know what to look at
and therefore what you mean.
• Don’t be in a rush to fill in silence. Many activities involve asking people to
contemplate new ideas or ways of thinking, and that takes time. In asking people
if they have something else to add or want to change a structure, allow them time
to think through this even if there is a period of silence. If you rush in to fill the
silence, not only are you not allowing them to think through your question, but
you’re also signaling to them that you were not serious about asking the question
in the first place and the question was rhetorical.
• At any given point, know what you’re trying to do. At any moment during the
workshop, you should know what it is you are trying to do to facilitate the con-
versation. You are the guide in the conversation, and the participants rely on you
to keep the process moving toward some productive end. If at some point you get
lost and are no longer sure what you are trying to accomplish, turn to your team
and ask for help. Having a process coach to turn to can really help at such points
because the process coach is usually already seeing that you are stuck and think-
ing of a solution. This also means, of course, that if you’re the process coach, you
should be monitoring the group and facilitators continuously and if you start to
see them get in trouble, have one or more “lifelines” that you can throw them if
they ask or appear to need help.
Listen and Report Back, Edit with Transformation
The dynamic between the modeler-facilitator and modeler in eliciting information

that the modeler can readily use is critical to both capturing the information quickly
and efficiently, and if edited or transformed, done so in a way that that is transparent
to participants. To do this, it helps to have the modeler-facilitator listen, parse, and
restate what participants say in a form that can be used by the modeler.
Andersen and Richardson (2010) have developed a facilitation principle they call
listen and report back, edit with transformation (LERT), which involves first listen-
ing and reporting back what participants said using exact words, concepts, and
phrases and then faithfully recording and displaying these, and then second, edit
with transformation by finding ways to filtering participants speech in ways that are
consistent with modeling principles. For example, if a participant says, “I was get-
ting so frustrated that I couldn’t get the support I needed from the doctor because he
was too busy at the time to return my calls,” the facilitation would first listen and
reflect back, “You were frustrated that you couldn’t get the support you needed
because the doctor was too busy?” If participant affirms this, facilitator might edit
with transformation. “So the doctor’s caseload decreases support that in turn
increases patient frustration?”
This accomplishes three things. First, it significantly improves the efficiency

with which the modeler can transform participants’ words into a model since the
modeler is listening to just one voice, the modeler-facilitator. Second, having the
facilitator do this also ensures that the transformation is transparent to participants,
which in turn builds trust. And third, the modeler-facilitator is teaching through role
modeling the sentence structure of cause–effect relationships in the model, the idea
of polarity, and so on. Participants will generally begin to pick up on these conven-
tions and talk in these terms and, when presented with a new version of the model,
quickly recognize the correspondence between what they said and the diagram.
To apply this effectively, both the modeler-facilitator and facilitator need to have
training in system dynamics and building models for activities that involve structure
elicitation, identification of variables, and dynamics. The LERT technique is also
useful for activities that identify potential leverage points that need to be mapped
into a system, scenarios to be tested, and operational definitions of variables.
Work as a Team
This should go without saying given the emphasis on group model building work
requiring teamwork, but I can’t tell you how many times I have seen this break-
down. Sometimes this happens through poor planning and training when someone
on the team does not understand or take their role seriously. Sometimes the work-
shop design is failing and participants are getting frustrated and angry and start to
confront the facilitator in the front of the room, while the other team members try to
distance themselves from the conflict by withdrawing and leaving the facilitator
hanging. Sometimes you end up working with people who are unreliable and this
when you discover this fact. I can recall a few occasions where a co-facilitator who
should have been in the front of the room either left the room or stood off to the side!
The major reason for this is usually not spending enough time preparing as a
team, clarifying roles and expectations, and building trust. Selecting people who are
reliable is obvious, but in addition to that, spend some time talking with your team
and especially your co-facilitators on how you will work together, how you will
share your concerns and how you can support each other, how you will communi-
cate needing support, and how that support will be provided. After the workshop,
take the time to debrief and reflect on how the workshop went.
Improvisation
No matter how much design and planning one does, or how familiar one is with the
room and materials, or how many times one has done the exercise with the same
team in the same room with the same materials, there is always a point where some
improvisation is required. I remember a workshop where in the middle of the “hopes
and fears” exercise, the sheets of paper started to fall down even though we had used
Recorders 73
the same paper, tape, and wall many times before with no problem. These things
happen, and being able to recognize that you are or need to improvise is part of the
game.
A more common reason for improvising is a visual representation starting to fail
as a boundary object. Maybe the diagram has become so complicated that no one
can really work with it any more, or the elegant system dynamics model that simu-
lates is rejected by the participants because it did not capture their mental models or
was too big of a jump from the previous version they saw. Group dynamics can also
emerge that erode the quality of interaction and require intervention in the structure
of the workshop.
In fact, one reason for using structured group model building exercises with a
detailed agenda, script, and facilitation manual is that the facilitation teams can
quickly identify when they are going off script, may need to improvise by changing
roles or developing a new script, and what the impact might be for the rest of the
workshop.
Andersen and Richardson (2010) have developed a taxonomy of improvised
behavior in structured group model building and three rules to follow when
improvising:
• The person “holding the chalk” calls the shots.
• Always know who is “holding the chalk.”
• Always seek permission for improvised conversations where (1) the facilitator
initiates conversations with public requests (e.g., the facilitator says to the group,
“I wonder if I could ask Timothy to offer insight on the reference mode we have
so far?”) or (2) the modeler initiates conversations with a private signal (e.g.,
raising a hand).
The last point to make here about improvising is that one needs to have some free
bandwidth to recognize the need and respond effectively. Small teams where every-
one is already in highly demanding roles can quickly find themselves caught in a
vicious cycle of making one bad decision after another.
Having a process coach can be very helpful in such situations for two reasons.
First, the process coach is monitoring the situation and thinking about a plan B, C,
D… and ready to help out if asked. This alone may suffice to prevent a disruption.
Second, the process coach can be the point person who consolidates the information
from other team members not in front of the room and then makes a recommenda-
tion, as opposed to having three or four other people trying to make suggestions or
remind the facilitators that they missed a step in a script.
Recorders
One or more recorders (we usually have two) take notes through the entire session,
usually on a laptop computer, and then consolidate the notes after the workshop.
The notes are usually parsed for key information depending on the activities. For
example, in the graphs over time script, recorders take notes on the causal stories
and how someone defined the variable. In structure elicitation exercises, recorders
take notes on the two variables, relationship and polarity. In activities involving
generation of potential leverage points, recorders note the name participants have
used to describe the potential leverage point and how it maps into the system.
Recorders also take notes on general process issues and agreements that have
been made with participants and next steps and help prepare products that are to be
shared with participants as deliverables during or at the end of the workshop.
Some groups use digital recordings instead of recorders to document the session.
While digital recordings can serve as a backup for recorders taking notes, they are not
reliable and not as accessible during and immediately after the workshop. It can be
very difficult to understand what people are saying in a group conversation in a room
with poor acoustics, and it usually takes several days to transcribe a recording leaving
the facilitation team at a loss for reviewing the notes and using them to inform deci-
sions about the workshop midway through during a break or at the end of the day.
Moreover, raw transcripts need additional analysis to pull out structures and review
the process, whereas the recorder is filtering this information in real time.
Recorders as opposed to digital recordings offer another advantage—a way for
participants to add or remove something from the notes during or after a session and
therefore a level of confidentiality that makes it easier to share openly. To establish
this, it is important that a facilitator announce to the group at the start of the work-
shop what the recorders are doing and that if there is something they want to add or
have deleted from the notes, they should just let one of the recorders know during a
session. This helps build further trust with the group, something a digital recording
does not.
Consolidating Deliverables
One of the functions of the facilitators and reflector is to help the group recognize
and consolidate insights and progress along the way and reinforce this through the
clear identification products that are of interest to the participants, that is, deliver-
ables. For example, if the group has just completed prioritizing a list of issues, it is
important that a facilitator point this out, “OK, so now we have a list of five key
issues. First….Second…Third….” If the products generated a tangible such as dia-
grams or lists of strategies to consider, it can be especially effective to have this
printed, copied, and distributed to participants while they are in the room or at the
end of the workshop.
It is also important to point out mental models that were made explicit and how
they shifted. If the mental models did not shift and they are dissatisfied with that,
point this out as well. If the group had several key “ah ha” moments, then it is
important that the reflector point this out, “I saw several key insights we developed
today. First….Second…Third….” Key themes are also helpful to draw attention to.
Debriefing and Reflection 75
Effective reflection back to a group usually takes some preparation by taking and
organizing notes throughout the workshop. The best examples of this that I have
seen involved the reflector taking pages and pages of notes all day long and then
distilling these down into a few key points that he elaborated on in a way that added
tremendous value to the daylong discussion. As participants, the information was
not really new, but the way he presented it consolidated the discussion, left us under-
standing what we had achieved and motivated us to dig into the next day. On the
other hand, winging it or impromptu remarks have never really seemed that effec-
tive and usually reinforced the idea that everyone is tired at the end of the workshop
and ready to leave. So, build in the time and space for someone to prepare a good
reflection and close on a bang!
Debriefing and Reflection
After a workshop, build in some structured time for debriefing and reflecting for the
facilitation team. It is best if the debrief is led by someone who was not tied up
throughout the entire workshop, and designate who this is before the workshop
starts along with the time and location of the debrief.
The debrief session should be separate from any socialization that might happen
after the workshop and conducted in a space where the team can air any frustrations
that arose during the workshop.
A good format to follow is for the debriefer to start with the people who were in
the front of the room and just ask how they are feeling, let them speak, and empa-
thize. After they have had a chance to speak, invite others to share how they are
feeling about the workshop starting with those who were the next most active (usu-
ally the modeler and recorders), and then let others join the conversation.
It is tempting to jump right in and discuss what worked, what didn’t, and how to
fix things, but this can short-circuit any assessment of where people are emotionally.
Not attending to the emotions of the team at the end of the workshop can be signifi-
cant barrier to learning and development of team members. The team may be expe-
rience a range of emotions, from elated at having completed the first workshop to
deeply saddened at hearing and seeing people’s suffering to anger at other team
members for being so naïve and privileged. Some might think they did their job
fantastically, while someone else felt let down. Often, however, the situations to
worry the most about are when everyone is elated at the success of the workshop
because this often leads to a complacency thinking “this is easy” and failure to take
the same care in preparing for the next workshop.
Once team members have had a chance to share how they are feeling, the
debriefer can move onto asking, what worked? What didn’t? How can things be
improved? What do we need to do next? Once the debriefing is done, it is done, and
people should be free to go and recharge.
Conclusion
This chapter has covered the actual group model building session beginning with
preparing the space and setting up the workshop and then covering what is needed
for facilitating an effective group model building workshop including managing
boundary objects and respective roles of the facilitation team; developing and using
guiding principles for shaping the group behavior of participants; general facilita-
tion tips; the technique of listen-report, edit, and transform; importance of working
as a team; the role of improvisation; use of recorders; consolidating insights and
preparing for a reflection back to the group; and ended with the debrief and reflec-
tion session.
No single chapter can cover nor convey all the knowledge and experience for
facilitating group model building workshops, so the goal has been to provide enough
of a framework, tips, and facilitation stories to hopefully enable the reader new to
group model building facilitation to feel more comfortable in a new role. The next
chapter covers the follow-up after the session including work on the models after
the session and the process of transforming informal maps and diagrams of models
into formal simulation models for analysis.
References
Andersen, D.F., and Richardson, G.P. 2010. Improvised facilitation: a third leg on the group model
building stool. Paper read at 2010 International System Dynamics Conference, at Seoul, South
Korea.
Anzaldúa, G. (1987). Borderlands the new mestiza. San Francisco, CA: Aunt Lute Books.
Black, L. J. (2013). When visual representations are boundary objects in system dynamics. System
Black, L. J., & Andersen, D. F. (2012). Using visual representations as boundary objects to resolve
conflict in collaborative model-building applications. Systems Research and Behavioral
Science, 29, 194–208.
Black, L. J., Carlile, P. R., & Repenning, N. P. (2004). A dynamic theory of expertise and occupa-
tional boundaries in new technology implementation: Building on Barley’s study of CT scan-
ning. Administrative Science Quarterly, 49(4), 572–607.
Langs, R. J. (1998). Ground rules in psychotherapy and counseling. London: Karnac Books.
322–368.
Richardson, G. P., & Andersen, D. F. (1995). Teamwork in group model building. System Dynamics
Review, 11(2), 113–137.
Richardson, G. P., & Andersen, D. F. (2010). Systems thinking, mapping, and modeling in group
decision and negotiation. In handbook of group decision and negotiation. Dordrecht: Springer.
Vennix, J. (1999). Group model-building: Tackling messy problems. System Dynamics Review,
15(4), 379–401.
Chapter 7
Model Refinement, Integration, Formulation,
and Analysis
We need to be able to see how gender, race, and class interests

shape laboratory life and the manufacture of scientific knowledge.
(Harding 1991, 101)
There are countless legitimate, objectively grounded ways of
classifying objects in the world. And these may often cross-
classify one another in indefinitely complex ways. Thus while I
do not deny that there are, in a sense, natural kinds, I wish to fit
them into a metaphysics of radical ontological pluralism, what I
have referred to as “promiscuous realism.”
(Dupré 1993, 18)
The possibility of describing the world by means of Newtonian
mechanics tells us nothing about the world: but what does tell
us something about it is the precise way in which it is possible
to describe it by these means. We are told something about the
world by the fact that it can be described more simply with one
system of mechanics than with another.
(Wittgenstein 1974, 68)
Participation Versus Modeling
In the previous chapters, we have mostly been talking about how to involve com-
munities in the modeling process and way one seeks to build capacity in the com-
munity for CBSD. The main benefit of this has so far been mostly discussed as a
way to involve communities in problem structuring over time and developing causal
maps and stock and flow diagrams of their dynamic systems.
There are many reasons why this alone can help solve certain types of problems
and help communities adapt to changing environments through social learning. We
have also talked about the power of models to change people’s view of a system and
that this in and of itself can have benefits in terms of hope, motivation, self-efficacy,
empowerment, and sense of control over one’s own situation. Indeed, without this,
much of the initial participation in CBSD would quickly drop off.
Remaining is what is arguably a thornier and more nuanced problem that CBSD
seeks to address, namely, the dilemma of participation versus simulation modeling.
This is in some ways not a new dilemma. It has existed for as long as people have
debated the merits of democratic participation for informing complicated policy issues.

78 7 Model Refinement, Integration, Formulation, and Analysis
Take almost any policy issue from family planning to global warming that reaches an
impasse with public involvement, and you will hear the grumblings of experts and
analyst saying they know what to do, while the public lacks the political will to push
for implementing the rational decision or, more frequently, actively opposes the expert
recommendations. This creates an impression of a dilemma between democratic par-
ticipation and expert analysis.
In system dynamics, this manifests in the form of participation versus modeling
rigor and analytic insights. In this view, having people participate means committing
to activities that largely exclude active involvement in formulating a simulation model.
Learning to formulate the questions for a good simulation model generally takes
many years to learn, and the difference in modeling speed between a novice and
expert can be stark. For argument’s sake, let’s say it takes an individual 10 years to
become an expert modeler and that the difference in how fast a novice modeler works
in relation to an expert is on the order of 1:100, so that it then takes the novice modeler
of 1 year of experience about 100 times longer to build the same structure as the expert
of with 10 years of experience. If we consider that rigorous models can take anywhere
from 1 to 5 years to build, then the idea of novices of 1 year or less building rigorous
system dynamics models to solve problems seems completely impractical.
On the other hand, if the system is changing sufficiently fast or needs to be commu-
nity specific to have relevance, there might simply not be the time or resources available
to have an expert complete the model in a timely way. This tends to leave one with the
impression that one can have either high participation through informal mapping or
rigorous analytic insights through formal simulation modeling, but not both.
What is missing here, of course, is the dynamic perspective of participation and
model development. CBSD emphasizes educating and capacity building over mul-
tiple projects as a means to not only engage and mobilize communities for change
during the early phases with informal maps but also build the motivation and capac-
ity for problem structuring, model specification, testing, and analysis for rigorous
formal models and computer simulations and the ability to convey the insights in a
way that will mobilize communities to action.
This approach is also consistent with the observation that there are different
phases of modeling (Costanza and Ruth 1998). One might start with one or more
informal maps or small simulation models to scope out the issue better and identify
the problem by building scoping models. Having identified the issue better, one then
moves to develop a research model, followed by a management model for monitor-
ing and evaluation. In effect, one can build lots of scoping models in a community as
a means to both structure problems and build capacity and motivation for a commu-
nity to invest in active participation in the development of a research model, which
is then much more likely to be implemented and used as a management model.
The Role of the Expert Modeler
It is important to recognize that in CBSD, it is communities and not the modeler that
usually ends up pushing for more rigorous simulation model. Over time and multi-
ple projects, communities start to recognize and learn that it is difficult to draw
The Role of the Expert Modeler 79
inferences from an informal causal maps alone. Heuristics may be offered based on
Meadow’s (1999) article on places to intervene or Senge’s (1990) Fifth Discipline,
but eventually questions arise about how to apply these effectively and with confi-
dence to influence the system and its behavior. People start to understand the need
for and demand simulation to build better models.
It is also important to remember that the path for a community from informal
causal maps and short workshops to engaging and demanding simulation modeling
is a road littered with many boundary objects along the way, one for each step, and
with many twists, turns, and forks. The expert modeler may be able to run down this
road and expedite the modeling, but only by being the driver with everyone else
feeling a bit lost, unable to reconstruct the journey, and entirely dependent on the
modeler.
In CBSD, the expert modeler is teacher and guide, helping people see what the
modeler sees in each boundary object,1 one step at the time so that the next one
follows from the previous one at a comfortable but challenging pace and thereby
creates trust, confidence, and empowerment in creating and using models along the
way. The expert modeler looks for lots of small opportunities to move one step here
and one step there. New people join the walking party, while others stray off on
their own to try things. Some come back to share their successes and learning,
while others decide that this isn’t the right road for them, and everyone accepts
that. In CBSD, the expert modeler looks and encourages participants to take on
more and more roles in modeling and supports them when they get stuck. The
expert modeler teaches with unconditional positive regard.2 One must ultimately
remember what it is that is being asked of someone when their mental models of a
situation are at stake.
It is also important to realize that succeeding here means always being aware of
how to see and apply the principles of system dynamics in full to gain the greatest
insights. A teacher and guide who leaves people with the false impression of the
kinds of inferences they can draw from informal causal maps without simulation is
doing a disservice. People will tend to interpret silence of the expert as an endorse-
ment that their interpretations are correct, only to be later disempowered by the
discovery that the expert did not point out the issue.
This tension—between extending unconditional positive regard and the need to
provide accurate feedback on the status of inferences based on a flawed model—is
perhaps one of the most demanding aspects of CBSD. It can at times manifest as a
tension between ownership over the model being developed and pursuit of rigorous
analytic insight.
1
Schön (1990) talks about this in the context of how a teacher helps a student see an architectural
design or model, and one of the key points is that it is not a lecture, but by the teacher walking
around an object the student has produced and saying things out loud that helps the student learn
how to view the object.
2
Carl Rogers (Kirschenbaum and Henderson 1989) was once asked what is the difference between
psychotherapy and his approach to teaching. He said they were the same. Also note that Vennix
(1999) has been very clear about the importance of facilitative attitude in group model building,
something that Carl Rogers also emphasized in talking about change in dynamics environments.
Negotiating this requires one to understand the reasons for modeling and limits
of informal causal maps for reasoning about systems, and understand the choices
and options facing a group in moving forward with a model, whether that is within
a group model building workshop or part of the follow-up to a workshop. The
remainder of this chapter is therefore devoted to laying out a strategy for doing this
starting with why we need to model. The emphasis will be on describing the various
approaches for refining, synthesizing, formulating, and analyzing informal causal
maps and formal models that are simulated. Readers interested in learning more
about the formulation of rate equations, confidence building tests, and analysis are
encouraged to look at Sterman (2000) or Ford (1999).
Why Model?
Group model building workshops generate lots of informal causal maps, but fewer
formal models, and only some of these are turned into an actual simulation models
that bring the full rigor and analysis that system dynamics has to offer back to par-
ticipants (Homer and Oliva 2001). We know from experience and experiment that
people are just not very good at even inferring the simplest behaviors from an infor-
mal causal map. So if we want to be able to draw valid inferences about the relation-
ship between a structure and the behavior of that structure, then we need to
simulate.
Some might be tempted to argue that simulation is unnecessary if we test our
causal map empirically or that empirically testing the causal map is a better form of
evidence than simulation alone. But, this is to fundamentally ignore the seriousness
of the logical error being committed.
The psychologist and philosopher of science Paul Meehl (1990) argued that
when we think we are testing a substantive theory by running a statistical test on
empirical data, we are implicitly assuming that the connection between our substan-
tive theory and hypothesis to be tested is true and then drawing the conclusion from
the result of the statistical test. Our assumption that the logical connection between
our substantive theory and hypothesis is true is based on verbal reasoning. But, this
is essentially what we already know to be flawed when it comes to complex systems
as we discussed earlier in Chap. 1. We just don’t get it right even when the systems
are relatively simple (Dhawan et al. 2011).
One could argue that experience in a system allows one to develop, over time, the
ability to learn how to manage a system and develop accurate predictions about how
it would behave in response to certain changes. But, our ability to generate such
predictions presupposes effective dynamic problem-solving abilities of dynamically
complex systems, and this is far from a universal ability. In research on anesthesia
residents’ dynamic problem solving and decision making, for example, many fell
into various problem-solving modes with only one that led to solving the problem
(Morrison et al. 2008, 2013). These were residents, of course, and there are physi-
cians who are able to solve such problem, but as Bray et al. (2008) point out,
Why Model? 81
Just as a virtuoso musician will learn to play over a range of loudness, the versatile problem
solver will develop the ability to adjust the pace of acting, interpreting, and cultivating
alternatives to match the needs of the situation…. However, such expertise presumably
develops over considerable time and exposure to a variety of situations. (p. 33)
In addition to the fact that many in a field are not virtuosos and for those who do
it takes a long time to develop these skills, a third problem that arises is that the
variation over which one learned and acquired the expertise generally involves a
system with a relatively stable structure. The general biological structure of the
human body does not, for example, evolve over the time scale of the physicians’
learning. However, the structure of socially constructed systems can change quickly
relative to someone’s ability to learn from experience and sometimes very fast
through the very act of drawing the structure using the conventions of system
dynamics (Warren 2004).
Collecting and analyzing more data do not necessarily get us out of the problem
of the underlying system structure changing. Data systems generally lag in their
development and implementation of the structural changes in a system. I recall one
colleague at a meeting about making child welfare research more relevant exclaim-
ing in a mixture of exacerbation and humor, “If they could just stop changing the
system for 10 years, we could tell them what to do!”
The conclusion we should take away from this argument is that there really is not
some way to avoid simulation of formal models of complex systems if we want to
be able to draw rigorous logical inferences about the relationship between system
structure and system behavior.
“OK” one might say, “But, what if drawing inferences about the relationship
between structure and behavior” is not our goal? What if we are basically just inter-
ested in describing the structure of the system without drawing inferences about its
behavior? Would not a causal map be enough?
No, it only avoids the problem by avoiding asking the question. We would be
looking at the structure of a system and not know whether or not that is the structure
of the system producing the behavior of the real system. We would not know because
we had a priori decided not to test the dynamic hypothesis, which would require
simulation.
What if we had multiple diagrams of the same or similar situation and looking
across these diagrams we saw that they all contained a generic structure of sorts,
would not this tell us something about the structure of the system? Yes, but some-
thing much more modest than what we might have been looking for.
Looking across causal maps, for example, would tell us how people think the
system works, that is, what are their espoused mental models or theories of the sys-
tem, and we may not even get to their theories in use (Schön 1983). All the people
we involved or perhaps society in general could be thinking a certain way about an
issue and still be objectively wrong. This is clearly not the same as knowing what
the underlying structure of the system could logically be, nor what the structure
underlying the real system actually is.
But, we should be aware that this is still something and that might be sufficient
for gaining a system insight to changing the system, for example, a coordination
problem where agreement or achieving consensus is more important than having the
right answer. But this works, not by delivering rigorous insights but instead from
agreeing to use a model as a boundary object to seek consensus. For this, any causal
map or model will do as long as participants believe in the diagram.
Moreover, even an incomplete or seriously flawed formal model can lead to learn-
ing in the right context and expectations. Richardson’s (2013) concept model is delib-
erately designed to be incomplete so that participants can quickly find mistakes and
use simple equations that are easy to explain over more sophisticated and better for-
mulations and often without units that lead to dimensional consistency. The model
would be problematic if one was using this for policy analysis, but the concept model
is meant for teaching. A good model here is not the one that passes scientific muster
and yields analytic insights, but one that proves to be an effective teaching tool for
introducing concepts from system dynamics within the problem domain.
The point to take away from this is that our use of formal models that can be simu-
lated goes beyond the immediate task of building a model with a community during a
GMB workshop. Furthermore, the criteria for determining whether this is a good
move or not comes down to the type of problem being solved, the types of insights
that are thought to help solve the problem, and ultimately the purpose of the model.
Model Specification and Ownership
Meehl (1990) draws a distinction between different levels of theory specification,

from the categories that define the concept as the least specified to defining the rela-
tionships between variables in the middle and to ultimately making predictions
about the numeric values of specific variables. One of his aims in laying out this
framework is to emphasize the importance of appraising theories by their level of
specification.
This notion is relevant in modeling because as we build a model, we are for the
most part concerned with only certain kinds of transformations on a model, namely,
changes that inject new ideas that conflict with the previous ideas (Hovmand et al.
2011). As an example, consider a theory about the relationships between color and
anger where someone has specified a variable called “redness”:
• Changing this to “softness,” “blueness,” or “hardness” would mean something
entirely different than originally intended. This is problematic because now the
meaning has changed.
• On the other hand, if one specifies the theory by defining that “redness” causes
anger, then that is all that has been done. Someone might object and say, “Well, I
think it goes the other way!” But, this is precisely what we expect from further
specification of our theory—to be more explicit about what we are claiming.
Hence, going from less to more specific can invite critique precisely because we
are making our theories explicit. This is a good thing.
Model Review and Cleanup 83
• Moreover, if one goes from “redness” causes anger to claiming that there is an
association between redness and anger; one has lost specificity but not changed
the meaning. So going from more specific to less specific does not generally
invite much of a debate.
What is important here is to notice that despite all three involving changes to
some theory, some changes involved more significant shifts in meaning and are
therefore potentially more controversial. That is, ownership of a model as a bound-
ary object is not tied to the fact that we make a transformation, but the kind of trans-
formation we make. This is useful because what is often relevant in terms of
participation by a community is not that they are involved in every detail of the
modeling but that they are involved in the aspects that have the most significance for
the project. The implication is that a key function of the core modeling team is to
discuss and understand which types of transformations on the model would be
acceptable to the participants and which are not.
There are no hard guidelines on this. One group of participants may feel that they
lost ownership simply because the model that emerged from the modeler-facilitator
was developed on a computer even though the work happened during the workshop
in their presence. Meanwhile, another group might prefer to have the expert mod-
eler “clean up” the diagram to look more professional and expect this at the next
meeting. What this means is that one is constantly clarifying and negotiating the
terms for the exercise.
Model Review and Cleanup
Most of the results from a group model building session tend to be somewhat raw.
It is possible that participants did not understand the directions well enough, did not
have enough capacity to draw better diagrams, said things that were not (but should
be) included in the diagram, or, conversely, said something that they decided they
did not want to be included in the model or notes.
So models are generally reviewed and refined. This typically includes entering the
diagrams into a software package such as Vensim or iThink/STELLA as close to how
they appeared during the session if this did not happen during the session. And then, the
diagrams are compared against the recorder notes to ensure that all the variables and
linkages that are in the diagram correspond with what was said during the session.
There could be, for example, causal links that someone described but were not
captured in the model drawn on a whiteboard or projected onto a screen. There can
also be variables and relationships in the diagram from the session that should have
been changed or deleted. For example, participants often revise the meaning of a
variable or change a set of causal relationships during a session, but these changes
may have been missed and not captured in the diagram.
Sometimes, a participant will also speak directly to a recorder and ask that some-
thing be added or removed. For example, the participant may have taken a risk in
sharing with the group a particular aspect of the system using a slang term but later
regret sharing this and prefer another term.
The number of edits to the diagram generally represents only a small percentage
of the total variables and linkages (5 % or less) and are usually marked in a different
color for the model review session by the core modeling team that follows the group
model building workshop.
During the model review session, the model structure is reviewed with specific
attention to the variables and linkages that involved changes or were questionable in
meaning. The primary purpose of this model review session is to ensure that the
diagram represents as much as possible a literal representation of the content from
the session with issues such as event thinking, absence of balancing feedback loops,
and missing delays ignored at this point.
Often, during the model review session, the core modeling team will find some
terms that require further discussion and elaboration in what they meant. Sometimes
members of the core modeling team who were at the session or are from the com-
munity can readily clarify these. Other times, the core modeling team may decide
that an additional session or two is needed with a specific group from the commu-
nity to elaborate.
For example, in our Boyapalle study with Foundation for Ecological Security, it
became apparent that we needed to understand some of the decision behavior of the
small restaurant owners in a nearby town as they influenced demand for fuelwood.
This called for both an expansion of the model boundary and an additional session
with them to understand their situation from their perspective. In another case, in
our Veterans, Trauma, and Battering behavior study, military sexual trauma (MST)
came up as a theme in all three group model building sessions and called for a spe-
cial session designed to elicit more structure specific to MST.
The model review and cleanup of models generally have little impact on the
continuity of the boundary object from one session to the next. However, the trans-
formation of a model from hand drawn to something drawn on the computer can
sometimes be enough of a shift to disrupt the status of the boundary object. When
this is a concern, the core modeling team usually transfers the electronic version
back to a hand-drawn version on several sheets of paper.
Integration
After diagrams and changes have been reviewed and cleaned up by the core model-
ing team, structures from multiple sessions or groups within a session are integrated
into a single diagram. The goal here is to essentially take the union of the different
structures, merging similar variables from different structures along with their rela-
tionships. For example, in one session a group might have used the term “implement
EBP” and another “implementation of evidence-based practices.” The differences in
the terms here are usually trivial and easily combined or merged into one variable.
Integration 85
However, sometimes the same word is used in very different senses. Or two dif-
ferent words that would normally appear as synonyms or be proxies for each other
mean quite different things. For example, the term “income” is sometimes used as a
flow variable and other times used as a stock variable when participants think of
income as their wage or salary. In these cases, the core modeling team needs to
clarify whether or not the distinction in use is real by going back to the recorder
notes and if it cannot be resolved there, noting the issue for the next group model
building workshop.
For example, in one group model building workshop, participants working in
teams took several diagrams and integrated them into one diagram. Several of the
original diagrams had contained the word “depression,” but participants at this stage
concluded that while this is the correct term for a general audience, their peers
would misinterpret the term and not relate to what was intended. After some discus-
sion, they chose the term “down mood” instead.
In another example, the core modeling team from the West End was looking at a
feedback loop involving marketing of fast food to residents in a low-income pre-
dominantly African American community. Much discussion ensued as the initial
suggestion from the modelers for a variable was “marketing.” The problem the
members from the community had with this is that while it might be the accurate
term from the business side, it did not quite capture how they experienced the rela-
tionship, which was seen as more intensively focused on the population in the com-
munity. In particular, community members described a shift in food preferences tied
to demographics in the neighborhood that happened as high school students gradu-
ated and went to college. At college, they were exposed to fast food and returned
with the idea that food such as a pizza was a meal. This created demand for fast food
and establishments moved into the area to meet that demand, which in turn led to
more unhealthy eating and changed norms of a meal even more, creating a vicious
cycle and generational loss of knowledge about how to prepare a meal. While the
research literature might describe this as “targeted marketing” (Grier and Kumanyika
2008, 2010), residents were adamant about capturing some of the nuance of both the
demographic shift and shift in food norms and settled on the term “designed for a
purpose based on population serving.”
Because integration is generally restricted to taking the union of variables and
linkages, these changes also tend to be relatively uncontroversial in terms of owner-
ship over the boundary object. However, the expansive causal map that results can
lead to a potential failure of the boundary object because instead of being selective
in choosing the relationships, everything has been included. So the results are gen-
erally only shared as an intermediate result toward simplification.
The mechanics of integration usually follow one of two trajectories. One is to
import all the structures into the same file (e.g., in Vensim) using different views for
each structure and then combine structures in a new view and merging variables that
are essentially the same along with their causal connections. The second approach,
and one which I tend to favor, involves laying out the different diagrams and then
looking across the diagrams to search for key structures, which I highlight with a
marker or pen, and then create a new model from scratch by redrawing these
structures crossing out each structure as I do that. In either case, it is important to

document the process as carefully as possible so that one can explain to others how
one arrived at the model.
Simplification
Simplification applies principles of system dynamics to edit the diagram. For exam-
ple, parts of a model diagram that reflect event thinking are reinterpreted into causal
structures. The naming of variables is changed to be more consistent with principles
of system dynamics. Key stock variables may be identified with a box in a causal
loop diagram. Duplicated feedback mechanisms are simplified. Sets of exogenous
variables that all influence only a single variable are consolidated or even eliminated
if they seem to be peripheral to the structure.
Additionally, the core modeling team may identify and include a small number
of implicit causal connections and delays. These are usually drawn using different
conventions (e.g., dashed line or a different color) to highlight the fact that the core
modeling team added these into the model as opposed to the participants.
Generally, the goal of simplification is to generate a new and more parsimonious
diagram that is more consistent with the principles of system dynamics than the
integrated diagram. This represents a much larger shift in the visualization of the
system than the previous transitions, and hence there is the risk of losing the bound-
ary object.
An essential aspect of a successful transition from one boundary object to another
is being able to retell the story using a simplified diagram based on principles of
system dynamics and using participants’ exact terms as much as possible. This
sometimes requires those with more training in system dynamics to offer interpreta-
tions of participants’ situations.
For example, it is not uncommon for groups with well-intentioned social scien-
tists to describe phenomena related to racism using a term “race” as the cause and
then create links to the effects such as “educational attainment.” The problem from
a system dynamics perspective is that this does not reflect the actual causal mecha-
nism. Race does not cause educational attainment. Race is a socially constructed
attribute of an individual and usually not a cause in the sense that the term is being
used. Instead, what the social scientist is trying to include is an association without
the benefit of a language or theory of the underlying causal mechanisms involving
stereotypes, expectations, grades, educational attainment, etc., that is, the underly-
ing causal structures that generate the observed correlation. The difference is impor-
tant to system dynamics which emphasizes operational thinking as opposed to
correlational thinking (Olaya 2012).
At this point, it is important to educate the team and participants about the shift
and why it is important. Done well, there is a transition from one boundary object
to another and the development of system insights. But often, especially when peo-
ple are not members of the community and do not have sufficient training and
Formulation and Testing 87
experience yet in system dynamics modeling, there is a tendency to stick with the
literal story. This can prove problematic from the point of view modeling since this
actually obfuscates rather than reveals how a phenomenon such as structural racism
functions.
Skills for simplifying a casual loop diagram or stock and flow diagram are gener-
ally developed from training and practice in building formal simulation models
adhering to the principles of system dynamics. This does not mean that one has to
become an expert modeler; usually, an introduction to formal simulation modeling
with some practice and feedback will go a long way to handling this type of situa-
tion. Sharing causal maps of integrated models with experts trained in system
dynamics can also be very helpful.
Formulation and Testing
The simplified model represents a “road map” for building a formal simulation
model. Sometimes, the structure is close enough to something that can readily be
simulated, but this is usually not the case. So a first step is usually to identify the
major stocks in the system and feedback loops one needs to “tell the story” from the
group model building sessions.
From there, there are several ways to go about developing a formal simulation
model. The usual approach in system dynamics for most projects of a small to mod-
erate size is to have one person who is trained in system dynamics build the formal
simulation model, sometimes with assistance from other members of the team. The
major difficulty with this in CBSD is that the conversation around the model is often
lost as the simulation model when one person takes over all the work for formula-
tion. The second problem is that this does not really develop capacity in the same
way as the other techniques do.
One solution to this is team-based modeling. In team-based modeling, groups of
three people with different levels of modeling experience work together on model
formulation and simulation of a subsystem. All formulation, simulation, and testing
are done by the team with everyone present allowing the model to exist as a boundary
object and embedding insights about why a structure has to be one way as opposed
to another within the conversation, which can then be shared with the larger core
modeling team and eventually participants. When teams get stuck, each member
can work on their own to develop small experimental models and work out a solu-
tion. The team then reconvenes at their next meeting to see what they have come up
with and what might work.
One of the major benefits of this is that the public talking through of model for-
mulation equations makes the process of model formulation much more transparent
and facilitates learning of formulating, testing (for a list of confidence building tests,
see Sterman 2000), and analyzing of simulation models, activities that are ongoing
and iterative in the modeling process. A key aspect of this is the regular use of par-
tial model testing (Homer 1983).
There are two basic approaches to combining the results similar to the integration
and simplification of informal maps. The first takes results of subsystem models and
combines them into one larger simulation model, which can then be simplified through
further analysis and testing to develop a more parsimonious model. This follows con-
ventions similar to software development along with the accompanying problem of
versioning. It is arguably easier to take this approach when all the variables have an
unambiguous operational definition, and hence this tends to appeal to modeling that
has a strong positivist orientation. However, it tends to bias models toward expanding
boundaries and greater complexity with novice modelers and can introduce problems
with interpretation of results when differences in modelers’ orientation are inconsis-
tent. Activities such as periodic design reviews are therefore required, and modeling
tends to be more hierarchal in structure.
In the second approach, a team looks across the current generation of models and
then begins to develop the next-generation model from scratch based on insights
gained from the first generation. The building of a new model from scratch based on
the previous generation has a tendency to force teams to simplify their structures. It
also has the advantages of containing discovered modeling errors in the previous gen-
eration and being able to leverage the learning of modeling skills from work of the
previous generation of models to speed up the development of the next iteration.
Analysis
Model analysis is a broad topic, and rigorous treatment is outside the scope of this
book. Analysis is, however, often an overlooked aspect of modeling, especially at
the early stages of developing modeling skills. So a few remarks are in order.
When starting out learning how to develop models, there is a tendency to focus
nearly all the energy on just getting the model developed and, in the case of a simu-
lation, running on the computer with some sensible results. This can be so consum-
ing at times that teams often neglect to return to the original purpose of the model
described in the modeling project description and lose their way in terms of what
system insights they were trying to develop. Participants may be impressed by ini-
tial results from a group model building workshop and having a way to visualize the
system, but it does not take long before someone asks, “So what do we do with this?
How do we use it?”
This ultimately comes down to following through on what were seen as the origi-
nal system insights sought from the model. If the goal was to help participants
visualize the system, analysis is mainly about describing the structure and subsys-
tems that were identified through this process. If the goal was about identifying
leverage points or the effect of boundary conditions on the dynamics, one should
see an extensive set of simulation runs that are summarized and distilled into read-
able insights backed up by computer simulations. Explaining why behavior is hap-
pening should be verified through behavioral testing and analysis of feedback loop
dominance.
References 89
Conclusion
This chapter has covered a broad area of modeling in an effort to emphasize aspects
of refinement, integration, formulation, and analysis as they might relate to CBSD.
Part of the goal here has been to stress the different ways of working that maintain
continuity with the boundary objects and developing capacity within the core mod-
eling team and larger community. The chapter has not attempted to go into more
specifics about formulations such as defining rate equations and model testing as
these topics have been covered in other texts.
While the prospect of taking on development of formal simulation models may
be daunting at first, it is important to remember that there are many different types
of models that can be built during the life cycle of a project, from the development
of scoping models and a concept model in the early phases to design of a seed struc-
ture in the design and planning phase and to the development of a model for analysis
in the group model building workshop and follow-up. While some of these do
require the skills that come from years of experience, others do not and provide
opportunities to build those skills. Moreover, a commitment to team-based model-
ing offers many advantages over trying to develop models as an individual within a
community.
References
Bray, C., Morrison, D. S., & McKay, P. (2008). Socio-economic deprivation and survival of non-
Hodgkin lymphoma in Scotland. Leukemia & Lymphoma, 49(5), 917–923.
Costanza, R., & Ruth, M. (1998). Using dynamic modeling to scope environmental problems and
build consensus. Environmental Management, 22(2), 183–195.
Dhawan, R., O’Conner, M., & Borman, M. (2011). The effect of qualitative and quantitative
system dynamics training: an experimental investigation. System Dynamics Review, 27(3),
313–327.
Dupré, J. (1993). The disorder of things: Metaphysical foundations of the disunity of science.
Cambridge, MA: Harvard University Press.
Ford, A. (1999). Modeling the environment: An introduction to system dynamics modeling of envi-
ronmental systems. Washington, DC: Island Press.
Grier, S. A., & Kumanyika, S. (2008). The context for choice: Health implications of targeted food
and beverage marketing to African Americans. American Journal of Public Health, 98(9),
1616–1629.
Grier, S. A., & Kumanyika, S. (2010). Targeted marketing and public health. Annual Review of
Public Health, 31, 349–369.
Harding, S. (1991). Whose science? Whose knowledge: Thinking from women’s lives. Ithaca, NY:
Homer, J.B. 1983. Partial-model testing as a validation tool for system dynamics. Paper read at
International System Dynamics Conference, at Cambridge, MA.
Homer, J., & Oliva, R. (2001). Maps and models in system dynamics: a response to Coyle. System
Hovmand, P.S., Brennan, L., and Chalise, N. 2011. Whose model is it anyway? Paper read at 29h
International Conference of the System Dynamics Society, July 24–28, 2011, at Washington,
DC.
Kirschenbaum, H., & Henderson, V. L. (Eds.). (1989). The Carl Rogers reader. Boston, MA:
Houghton Mifflin Company.
Meadows, D. (1999). Leverage points: Places to intervene in a system. Hartland, VT: The
Sustainability Institute.
Meehl, P. E. (1990). Appraising and amending theories: The strategy of Lakatosian defense and
two principles that warrant it. Psychological Inquiry, 1(2), 108–141.
Morrison, J.B., Jenny, W.R., and John, S.C. 2008. The dynamics of diagnosing: virtuous and
vicious cycles in the operating room Paper read at The International Conference of the System
Dynamics Society, at Athens, Greece.
Morrison, B. J., Rudolph, J. W., & Carroll, J. S. (2013). Dynamic modeling as a multidisciplinary
collaborative journey. System Dynamics Review, 29(1), 4–25.
Olaya, C. 2012. Models that include cows: the significance of operational thinking. Paper read at
30th International Conference of the System Dynamics Society, at St. Gallen, Switzerland.
42–55.
Schön, D. A. (1983). The reflective practitioner: How professionals think in action. New York,
NY: Basic Books.
Schön, D. A. (1990). Educating the reflective practitioner: Toward a new design for teaching and
learning in the professions. San Fransisco, CA: Jossey-Bass.
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.
Irwin: McGraw-Hill.
Vennix, J. (1999). Group model-building: Tackling messy problems. System Dynamics Review,
15(4), 379–401.
Warren, K. (2004). Improving strategic management with the fundamental principles of system
dynamics. System Dynamics Review, 21(4), 329–350.
Wittgenstein, L. 1974. Tractatus logico-philosophicus. Translated by D. F. Pears and B. F.
McGuinness. New York: Routledge. Original edition, 1921.
Chapter 8
Implementation and Evaluation
Rhythm…I had been hitchhiking in cars and trucks, and I

needed to learn how to ride on freight trains, because they’re
better for long distances. I asked the people living in the camp
about catching freights, and they told me, “Look, if you ride a
freight train you’re going to get killed, so we’re going to have to
teach you.” And they actually simulated the whole experience.
One of them would run along and be the train, and he’d make
me keep pace with him: when he’d speed up, I’d speed up, when
he’d slow down, I’d have to slow down. In other words, they
taught me to synchronize my pace with the train until it was
exactly the same…These experiences helped me think about the
pace of social change and how to relate to it.
(Horton 1998, 82–83)
Implementation
No book on community-based system dynamics (CBSD) is complete without talk-

ing about implementation, for this is one of the central motivations for pursuing
CBSD. Implementation means putting some innovation such as a new idea, behav-
ior, or method into actual use and is usually distinguished from adoption of the
innovation (Klein and Knight 2005). There can be many promising innovations out
there that we feel should be implemented and argue the world would be a better
place if they were. The general difficulty is that the really big problems are big in
the first place because there is a lack of demand to challenge the cherished policies
(Forrester 2007).
The foundation of CBSD rests on the idea one is working over time and multiple
projects to build capacity through education, which is one of the primary motiva-
tions for saying this is community based. A consequence of the accumulated capac-
ity is then the possibility of developing models that have both the powerful insights
of system dynamics and the mobilization of a community to implement the changes.
This approach is very much influenced by Horton’s (1998) distinction between
educating and organizing and specifically his recognition that history oscillates
between periods of organizing where the emphasis is on building capacity for
change and social movements when that capacity is put to use by a critical mass of
people with similar concerns.

92 8 Implementation and Evaluation
Fig. 8.1 First group model building session with clergy from the West End talking about child-
hood obesity
In this context, what we do with the models and what it means to implement
models differ by whether we are in a period of organizing or a period of a social
movement. During organizing times, implementing models means using them to
address learning problems within oneself, a small group or team, or maybe an orga-
nization or community. It can also mean using the model to organize and reach
consensus on goals and solve coordination problems, develop recommendations,
and ultimately create the network of system thinkers positioned in place for the next
social movement.
During the period of a social movement, implementation takes on a very differ-
ent meaning. Here, the social capital and social learning capability developed over
time are combined to push the leverage points identified through analysis. In this
context, implementation means seeing those actions lead to tangible changes like
restoration of forest or launch and scale-up of a new program. During these times,
implementation can also mean restructuring the system as might happen by creating
new pathways for people seeking services or redefining the boundary of a commu-
nity to gain leverage by creating new feedback loops.
In CBSD, some insights from a model are implemented very quickly. This
became apparent during our first group model building session with clergy from the
West End as part of our childhood obesity project (see Fig. 8.1). Participants quickly
started to identify ideas for addressing childhood obesity and ways that the churches
and temples in the community could share resources. One church was going to offer
fruit to the kids at service to encourage them to both eat fruit and avoid going across
Evaluation 93
the street during a break to get junk food from the gas station. Another talked about
ways to get to the farmers’ market, and someone else shared that their church had a
bus they could use to organize a weekly trip.
In another example, 3 years after the initial engagement with villagers from
Boyapalle, one of our first projects to use what we now call CBSD, much of the forest,
has regrown. The villagers tell a story how our work with them happened at “a very
interesting time” because until then, they had not seen themselves as part of the forest.
They would just go in and take what they needed, but around that time they started to
see themselves as part of the forest, cordoned off an area, developed rules for self-
regulation, and started to access the National Rural Employment Guarantee Scheme,
which reduced the pressure to harvest the fuelwood to sell to the local town.
These are not necessarily ideas that stem from or require rigorous models.
Serving fruit at service is a low-risk innovation, and while adopting an endogenous
perspective is a change in mindset, it still takes time for the forest to grow back.
Other much more difficult dilemmas lie further down the road, some of which are
appropriate for more rigorous system dynamics models. The point to make here is
that communities do not wait around for the final analysis to come in. Systems start
changing almost as soon as we start to bring people together, develop reference
modes, and create models.
The consequence of investing time and effort to build capacity in a community is
that subsequent projects are much more focused and faster and increasingly have
communities demanding simulation models as either a microworld for teaching
insights or analysis. Such projects start out from the beginning with the community
ready to implement the results. There is at this point no longer an implementation
problem.
Evaluation
Evaluation of CBSD workshops and community impact can take many forms, from
informal assessments of “hopes and fears” to more formal pre-post-follow-up sur-
veys of process and workshop outcomes. Rouwette (Rouwette 2012; Rouwette et al.
2006, 2011) has done extensive work to try and organize the research supporting
group model building through meta-analyses of published outcome measures and
evaluating the use of group model building using communications theory.
One of the major challenges, however, is the fact that group model building
workshops tend to be highly customized to the specific client or community and
topic. Moreover, there is likely to be a strong component tied to the attitude and
skills of the facilitators (Vennix et al. 1997; Vennix 1996) and hence difficulty sepa-
rating the specific from nonspecific treatment effects (Lohr et al. 2003).
Some efforts have started to document workshops (Luna-Reyes et al. 2006) and
standardize the description of group model building scripts (Hovmand et al. 2012).
These efforts will contribute to the toolkit for evaluating group model building
workshops and interventions.
94 8 Implementation and Evaluation
However, challenges exist for evaluating CBSD. First, CBSD is itself a dynami-
cally complex system. This book is an attempt to provide a more explicit account of
CBSD, the underlying philosophy, and expected outcomes. These can in turn form
the basis of more systemic data collection and evaluation efforts. Also in the works
are system dynamics models of the CBSD process itself.
While the emphasis on educating and empowerment can be measured, the nature
of these outcomes means that participants will, if the effort is successful, choose
their own initiatives. Moreover, it appears that while most provide very favorable
reviews after a workshop, there are usually a few who use the content and results to
mobilize new resources within the organization or community. These individuals
tend to be a minority of participants, and the delay between when they participated
and when their initiatives appear can be on the order of several years or more. This
suggests that evaluation studies of CBSD really need to consider the use of longitu-
dinal designs.
Also to be evaluated are the system dynamics models. What is a “good enough”
model really depends on the purpose of the model and type of problem. We expect
a concept model to lead to participants understanding and being able to apply con-
cepts from system dynamics to describe their problem situation. We expect a model
developed to solve an analysis problem to have the “right” answer, a model created
for a coordination problem to yield consensus, and a model used for restructuring to
show evidence that changes in the real system led to predicted improvements.
Conclusion
This chapter has briefly covered the implementation and evaluation of results from
CBSD. With more communities engaging in CBSD, it will be both increasingly
important and easier to conduct more systematic investigations on the process and
outcomes of CBSD.
References
Forrester, J. W. (2007). System dynamics-the next fifty years. System Dynamics Review, 23(2–3),
359–370.
Horton, M. (1998). The long haul: an autobiography. New York, NY: Teachers College Press.
Hovmand, P. S., Andersen, D. F., Rouwette, E., Richardson, G. P., Rux, K., & Calhoun, A. (2012).
Group model building “scripts” as a collaborative tool. Systems Research and Behavioral
Science, 29, 179–193.
Klein, K. J., & Knight, A. P. (2005). Innovation implementation: Overcoming the challenge.
Current Directions in Psychological Science, 14(5), 243–246.
322–368.
References 95
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.
Rouwette, E. (2012). Does group model building work? Evidence from and commons on the paper
by Videira et al. Systems Research and Behavioral Science, 29, 620–623.
Rouwette, E., Korzilius, H., Vennix, J. A. M., & Jacobs, E. (2011). Modeling as persuasion: The
impact of group model building on attitudes and behavior. System Dynamics Review, 27(1),
1–21.
Rouwette, E., Vennix, J. A. M., & van Mullekom, T. (2006). Group model building effectiveness:
A review of assessment studies. System Dynamics Review, 18(1), 5–45.
Vennix, J. (1996). Group model building. New York: Wiley.
Vennix, J. A. M., Andersen, D. F., & Richardson, G. P. (1997). Forward: Group model building,
art, and science. System Dynamics Review, 13(2), 103–106.
Chapter 9
Conclusion
A First Step
This book describes an approach for engaging and building system dynamics mod-
els in communities that have been developing over the last several years. Community-
based system dynamics (CBSD) is also not static. As more people pick up and try
CBSD, there will inevitably be more innovations, more communities of practice
using CBSD, and greater learning on how best to use CBSD.
Throughout the book, I have tried to describe it in as clear terms as I can, what
the underlying ideas are, how they are applied, heuristics, and pitfalls, and shared
some examples of things that went well and things that did not. For some, who have
been interested in the approach and started to use it in their own communities, my
hope is that this provides the kind of background and framework for using the
approach and trying out new ideas with more confidence. I have also tried to keep
the book succinct and easy to use in way that could be easily be carried into the field
if needed. But, there are inevitably gaps and limitations in describing a method like
this for the first time.
Although CBSD has a structured process, I do not intend for CBSD to be used in a
rigid fashion. It is important to realize that for most of the time that we have been
using what I am now calling CBSD, we have worked and debated the concepts along
the way. Moreover, in the Brown School Social System Design Lab, we are constantly
innovating and improving methods and learning from our colleagues. So while this
has been a first step toward describing the approach, I suspect we will continue push-
ing ahead and learning from our colleagues around the world.

98 9 Conclusion
Readiness
I am optimistic about the possibilities for CBSD. I am also aware that the very nature
of activity involves among other things achieving a synergy between people, proj-
ects, and organizations within a community. Throughout the book, I have tried to
share what I have learned from developing and using CBSD in communities to give
a sense of what one might want to consider before starting a project in a community.
This has largely focused on specific aspects like facilitation or considering a project
with a specific community partner. Less has been said about some of the more gen-
eral issues to consider with respect to readiness of a community for CBSD, which
means assessing to what extent the approach can work in the community over time.
When I start working with a new community, the main question we are discuss-
ing is whether or not this approach can work in their community. Some communi-
ties will have through a combination of urgent issues, community organizations,
individuals, and active community members more enthusiasm for the approach than
others, but for the most part, it seems the potential is there for communities.
If there is a constraint, it usually stems from limitations of a potential organiza-
tional partner. What I generally look for and have found to be critical to the success
of a project is a group within the organization that is willing to take risks and has
enough flexibility in their thinking and resources to try out the approach in a com-
munity they work in. Organizations that have very little bandwidth or time to invest
in learning will often have too many competing demands to be involved in a reliable
way in the design and planning of a group model building workshop. This in turn
makes it very difficult to develop a culturally appropriate design with realistic
expectations and valued deliverables for participants. This lack of connection to the
design of a workshop is a caution and indication that one should do a little more
assessment or see if there are other organizations that can be involved in the effort.
Another issue that I try to look for is the potential of local or regional universities
to provide graduates with training in system dynamics. Most organizations, if they
are going to scale up this approach, will eventually need to be able to hire new staff
who already have some training and skills in CBSD or more generally system
dynamics modeling. Providing opportunities for students and faculty from local or
regional universities to attend and participate in workshops on CBSD can be an
excellent means to build capacity. Other possibilities include exchange programs
that provide opportunities to see CBSD projects in St. Louis and elsewhere.
What’s Next?
These past years, developing, refining, and teaching CBSD have been an exciting
period of innovation and discovery. Many more people than I could possibly name
have made contributions to the approach through questions, trying things out, and
What’s Next? 99
improvising. More often than not when I return to a community, I learn about what
they have tried, what worked, what didn’t, where the excitement was, and where
they encountered barriers. These lessons are incorporated into further refinements
and innovations that get shared. At home in St. Louis, I get to hear about workshops
that I did not participate in that students led as part of a project or an organization
that staff facilitated on their own. Periodically, I get an email from a former student
who has an opportunity to apply the methods and brought in some assistance from
other classmates in the area.
It is hard to imagine that the pace of learning and innovation in CBSD will slow
down anytime soon, so I expect the methods to improve and change, for the articu-
lation of CBSD to further refine, and advances in measurement and evaluation of
CBSD techniques to increase the evidence base of the approach. Advances in por-
table devices are likely to lead to explorations of electronically distributed CBSD,
a better understanding in how people at different skill levels interact and build
models, and advances in our use of boundary objects. There will also be a need to
push the costs down further to increase the reach of the methods. And, I expect
there to be a growing collection tools (see www.tools.systemdynamics.org) and
case studies in group model building and system dynamics to draw from (see cases.
systemdynamics.org).
But most of all, I expect to see how positive impact unfolds in communities over
time, building capacity through education and developing insights through system
dynamics models and finding the leverage to solve problems.
Index
A definition, 7–8
Analysis, 88 marginalized, 7
Analysis problems, 45, 47, 48, 50 participation, 10–11
speech act, 7
Community-based system
B dynamics (CBSD)
Boundary objects causal maps and formal models, 2–5
characteristics, 22 complex problems, 8–10
failure modes, 22–23 defining community, 7–8
informal causal maps and formal models, 23 description, 1
management engaging communities
core modeling team, 68 (see Community engagement)
failure, visual representations, 65–67 evaluation, 94
group process, 63, 64 foundation, 91
institutions, 66 group model building, 5–6, 12
participants, CBSD, 64, 65 mental models, 1–2
team roles, 64 modeling process, 13
visual representations, 23 multiple projects, 14
participation, 10–11
social networks, 12
C stages
Causal loop diagrams (CLDs) CMT and capacity building, 27–28
description, 2–3 phases and activities, 26, 27
feedback loops, 3 problem scoping and identification,
Causal maps 26–27
CLDs (see Causal loop diagrams (CLDs)) workshops, 28
description, 2 system dynamics modeling, 12, 13
informal, 2, 5 workshops and community, 93–94
SFDs (see Stock and flow diagrams (SFDs)) Community engagement
CBSD. See Community-based system concept model script, 36–37
dynamics (CBSD) description, 32
CLDs. See Causal loop diagrams (CLDs) first audition, 35
CMT. See Core modeling team (CMT) graphs over time script, 35–36
Community indigenous communities, 31
building cooperation, 10 initial community participants, 33–35
CBSD (see Community-based system longer-term goals, 32–33
dynamics (CBSD)) marginalized communities, 31, 33
P.S. Hovmand, Community Based System Dynamics, DOI 10.1007/978-1-4614-8763-0, 101

102 Index
Complex systems debriefing and reflection, 75

CBSD, 6 description, 68–69
dynamic complexity, 9, 10 dressing, workshop, 69
interacting parts, 8–9 LERT, 71–72
Coordination problems, 45–47, 50, 51 tips, 70–71
Core modeling team (CMT) visual representation, 65
common language development, 56 Facilitation manual, 58–59
description, 27–28 Formulation
facilitation team, 28 next-generation model development, 88
formation, 55 period design reviews, 88
group building scripts, adapting public talking, 87
and developing, 59 “road map”, 87
initial community participants, 34 subsystem models combination, 88
process maps, development, 56–58 team-based modeling, 87
rehearsal, 59–60 Future directions, 98–99
system dynamics and group model
building process, 55–56
training, 59 G
Gatekeepers
CBSD, 34
D community engagement, 33–35
Detail complexity, 8, 9 concept models, 37
Detailed agenda, 58–59 as leaders, 34
Dynamic complexity GMB. See Group model building (GMB)
CBSD, 10 Group model building (GMB)
description, 9 approaches
running simulation model, 5 “blank slate” approach, 19
Dynamic problem CBSD, 19
description, 42 informal causal maps, 19
lack of, 52 structured and unstructured group
reference modes, 42–44 process, 18
boundary objects, 22–23
communities, 6
E computer simulation models, 18
Educating, 91, 94 decision makers, 5
Evaluation definitions, 17
educating and empowerment, 94 description, 6, 17
facilitators, attitude and skills, 93 participants, 25–26
system dynamics models, 94 participatory systems modeling, 18
treatment effects, 93 policy implications, 5
workshops and community, CBSD, 93–94 scripts, 23–25
Expert modeler role stakeholder participation, 18
in CBSD, 79 STELLA icon-based system dynamics
communities, 78–79 software, 17
heuristics, 79 teamwork, 20–21
informal causal maps, 79–80 workshop and facilitation (see Workshop
ownership, 79 and facilitation, GMB)
short workshops, simulation modeling, 79
system dynamics, principles application, 79
I
Implementation
F CBSD foundation, 91
Facilitation. See also Workshop and educating and organizing, 91
facilitation, GMB initial engagement, 93
characteristics, facilitator, 68 innovation, 91
Index 103
low-risk innovation, 93 modeler-facilitator, 83

model building session, 92–93 transformations, 82–83
organizing times, 92 system management, 80
social movement, 92 verbal reasoning, 80
time and effort, 93 Model simplification
Improvisation causal maps, sharing, 87
improvised behavior, 73 “educational attainment”, 86
process coach, 73 goal, 86
rules, 73 “race”, 86
small teams, 73 team and participants, education, 86
visual representation failure, 73 variables naming, 86
L N
Learning problems, 45, 46, 48, 51 Nongovernmental organization (NGO), 10
LERT. See Listen and report back, edit with
transformation (LERT)
Listen and report back, edit with O
transformation (LERT), 71–72 Organizational partners, 98
Organizing
and educating, 91
M implement models, 92
Mental models
description, 1
and feed backs, 2 P
Model cleanup Participation
causal links, 83 CBSD, 33, 34
continuity, impact on, 84 vs. modeling, 77–78
core modeling team, 84 Participatory rural appraisal (PRA), 24–25
diagram editing, 84 Philosophy of language
diagrams, software package, 83 CBSD, 32, 33
model review session, 84 CLD, 35
participant, sharing risk, 83–84 engaging communities, 32
Modeling project description system dynamics, 32, 36, 37
description, 50–51 Power
dynamic problem, 51 differences, 31
potential interventions, 52 initial community participants, 34
Model integration relationships, 31–32
“implementation of evidence-based PRA. See Participatory rural
practices”, 84 appraisal (PRA)
marketing, 85 Problem framing, 44–45, 47
mechanics, 85–86 Problem scoping and identification
“targeted marketing”, 85 added value, model, 50
word selection, 85 analysis problems, 45
Model review coordination problems, 45–46
causal maps, 81 discontinuation, 52–53
and cleanup (see Model cleanup) dynamic problem (see Dynamic problem)
data systems, 81 feedback, 48
formal models, 82 framing, 44–45, 47
group model building workshops, 80 initial conversations
policy analysis, 82 complex system problems, 40
predictions accuracy, 80 meetings, 39
problem-solving modes, 80 questions, system dynamics
socially constructed systems, 81 project, 40, 41
specification and ownership interest/pressure, 42
levels, 82 learning problems, 46
104 Index
Problem scoping and identification (cont.) STELLA icon-based system dynamics

marginalized communities, 41 software, 17
modeling, 48–49 Stock and flow diagrams (SFDs)
problem definition, 41 accumulations/stocks, 4
project description, modeling (see advantages, 4
Modeling project description) Structure behavior relationship, 5, 9
system insights, 49–50
transformation problems, 46
Problem structuring, 39, 44, 46, 48 T
Process maps Team roles
group model building, 56–57 workshop, 58
main design constraint, 58 zones, 64
potential participant types, 57 Teamwork
script, 57–58 facilitation teams, 21
workshop sessions, 58 group model building, 72
roles, workshop, 20–21
and team learning, 21
R Time horizon, 43, 51
Readiness Training, 59, 68, 69, 72
CBSD possibilities, 98 Transformation problems, 45–47
communities potential, 98 Treatment effects, 93
local/regional universities, 98 Types of problems
organizational partner, 98 analysis problems, 45, 47, 48, 50
Recorders, 73–74 coordination problems, 45–47, 50, 51
Reference modes learning problems, 45, 46, 48, 51
definition, 42 transformation problems, 45–47
dynamic problem, 42, 43
mistake, 43
numeric data, 43
U
and time series, 43
Urban dynamics model, 5
verbal/graphical, 42
Room setup, 62–63
W
S Workshop and facilitation, GMB
Scriptapedia, 24, 25 consolidating deliverables, 74–75
Scripts debriefing and reflection, 75
CBSD, 24–25 group process, boundary objects
characteristic, 24 management, 63–68
concept model, 36–37 improvisation, 72–73
description, 23 LERT, 71–72
graphs over time script, 35–36 physical setting and layout, 62–63
“graphs over time” script, 24 principle, 68
principle, 24 recorders, 73–74
Scriptapedia, 24 setting frame, 61–62
ScriptsMap, 23, 24 setup and takedown, 63
SFDs. See Stock and flow diagrams (SFDs) teamwork, 72
Social movements, 92 tips, facilitation, 70–71
Speech acts, 7, 32 World model, 5

Community Based System Dynamics

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Community Based System Dynamics

Transféré par

Droits d'auteur :

Formats disponibles

Peter S.

Community Based System

ISBN 978-1-4614-8762-3 ISBN 978-1-4614-8763-0 (eBook)

Library of Congress Control Number: 2013949143

© Springer Science+Business Media New York 2014

Printed on acid-free paper

Springer is part of Springer Science+Business Media (www.springer.com)

This book is about describing community-based system dynamics (CBSD), an

St. Louis, MO, USA Peter S. Hovmand

Work that is community based is embedded in relationships, and many have

The relevance of this to system dynamics only became apparent during a

1 Introduction to Community-Based System Dynamics .......................... 1

The First Audition ................................................................................... 35

Consolidating Deliverables ......................................................................... 74

Index ................................................................................................................. 101

Logical pictures can depict the world.

Why Community-Based System Dynamics?

Community-based system dynamics (CBSD) is a participatory method for involving

A mental model of a dynamic system is a cognitive representation of the real system

P.S. Hovmand, Community Based System Dynamics, DOI 10.1007/978-1-4614-8763-0_1, 1

Causal Maps and Formal Models

– Vaccinating Vaccinated children

Fig. 1.1 Example of a causal loop diagram

Fig. 1.2 Example of a stock and flow diagram

The main role of computer simulation in system dynamics is to test hypotheses

Group Model Building

In CBSD, we therefore begin to understand what is meant by asking those who

If people in a community are to be involved in developing informal causal maps and

In CBSD, community participation varies over time, from being involved as a

Fig. 1.5 Overview of the

Fig. 1.6 Overview of multiple projects in a community in CBSD

Stave, K. A. (2002). Using system dynamics to improve public participation in environmental

Group Model Building

P.S. Hovmand, Community Based System Dynamics, DOI 10.1007/978-1-4614-8763-0_2, 17

Approaches to Group Model Building

• Production coordinator to handle the preparation of products generated by the

In system dynamics, boundary objects have three essential characteristics (Black

in relation to project outcomes, and eventually the systematic documentation of

Three Stages of a CBSD Project

Problem Scoping and Identification

Table 2.1 Three phases of community-based system dynamics projects

Core Modeling Team Planning and Capacity Building

Group Model Building Workshops

Evaluation, Reporting, and Next Steps

If the purpose is to solve the problem—then you don’t take the

P.S. Hovmand, Community Based System Dynamics, DOI 10.1007/978-1-4614-8763-0_3, 31

Initial Community Participants, Gatekeepers, and Organizations

It is important to distinguish the initial community participants from the role of

The First Audition

Demonstrating group model building to a prospective community is essentially an

Engaging with the Graphs over Time Script

Engaging with the Concept Model Script

The concept model script can be an especially efficient approach to introducing

Theory is not inherently healing, liberatory, or revolutionary.

An initial introduction from a colleague, a chance encounter at a meeting, a referral

P.S. Hovmand, Community Based System Dynamics, DOI 10.1007/978-1-4614-8763-0_4, 39

What Is the Problem?

Percent of Population with Number of Children

100% Desired 1 million Desired

A common mistake in drawing reference modes is to put some variable other

What Kind of Problem Is It?

Having a working hypothesis that the problem is dynamic, it is important to con-

ideographic approaches to science. Between them is a continuum of theories and