Download Scripts for Group Model Building and more Lecture notes Dynamics in PDF only on Docsity!
Scripts for Group Model Building
David F. Andersen Center for Technology in Government George P. Richardson Graduate School of Public Affairs University at Albany — State University of New York Albany, NY 12222, U.S.A.
Abstract
For the past seven years, the modeling group at the University at Albany has been experimenting with techniques for building system dynamics models directly with groups. This paper extends the previously reported work by discussing specific scripted techniques used to implement the group modeling building approach.
Our purpose is to initiate a larger discussion of shared scripts and techniques for group model building. The discussion is divided into planning for a group model building conference, scheduling the day, particular scripts and techniques for various group model building tasks, and closing a group modeling conference.
April 1994
Prepared for the 1994 International System Dynamics Conference Stirling, Scotland, July 11-15, 1994.
Scripts for Group Model Building^1
David F. Andersen Center for Technology in Government George P. Richardson Nelson A. Rockefeller College of Public Affairs and Policy University at Albany — State University of New York Albany, New York USA
For the past seven years, the modeling group at the Rockefeller has been experimenting with techniques for building system dynamics models directly with groups. This work has included theoretical development, an attempt to teach our students group model building techniques, and a limited number of client-centered group modeling projects. Previous work has presented a general review of elicitation approaches (Vennix, Andersen, Richardson, and Rohrbaugh 1992) as well as a review of the roles involved in group model building (Richardson, Andersen, Rohrbaugh, and Steinhurst 1992). Our most developed statement of teamwork in group modeling building is contained in Richardson and Andersen (1994).
This paper extends the work by discussing specific scripted techniques used to implement the group modeling building approach. Many of these scripts draw on established wisdom in the system dynamics literature, e.g., Roberts (1973), Randers (1980), Wolstenholme and Coyle ( 1983), Richmond (1987), and Saeed (1992). The discussion centers on what we have experimented with, knowing that others have done more with other techniques; our purpose is to initiate a larger discussion of shared scripts and techniques for group model building. We divide the discussion into planning for a group model building conference, scheduling the day, particular scripts and techniques for various group model building tasks, and closing a group modeling conference.
Planning for the Modeling Conference The image for the planning phase is the preparation of a theatrical performance or concert. Every phase is carefully scripted in detail. We group the issues under goal setting, logistics, thinking through group tasks and structure, and developing a detailed time structure for the day.
Goal Setting/Managing the Scope of Work INTERVIEWS WITH KEY MANAGERS. In our work we have identified the key role played by a contact person within the target organization, a role we have labeled the gatekeeper (Richardson, Andersen, Rohrbaugh, and Steinhurst 1992; Richardson and Andersen 1994). The gatekeeper (^1) We wish to acknowledge that our efforts at group model building are indebted to and build on over a decade of experience with computer supported and group facilitated group model building by the Decision Tectronics Group under the direction of John Rohrbaugh at the University at Albany. See, e.g., Milter and Rohrbaugh (1985), Phillips (1988), Carper and Bresnick (1989), Rohrbaugh (1992), and Vari and Vecsenyi (1992). See Vennix et al. (1992) for further references.
Richardson, Andersen, Rohrbaugh, and Steinhurst (1992) and Richardson and Andersen (1994).
Figure 1: Typical room layout for a group model building workshop, showing large white boards, flip chart, swivel chairs in groups of three arranged in a semicircle, overhead projector with projection pad linked to computer in the background.
Types of Group Task Structure In a given day, the whole modeling group moves rapidly and often from individual work to small group work to plenary group work. Furthermore, tasks can vary from divergent (brainstorming) tasks to ranking and evaluating tasks to integrative or design-oriented tasks A key to a successful group modeling session is selecting the most appropriate type of group structure and group task for each point in time in the modeling conference (Vennix et al. 1992). Selecting sequences of elicitation exercises that yield fruitful, focused, and maturing group discussions is the never-ending challenge of group model building.
DIVERGENT TASKS. Divergent thinking tasks (such as getting as many ideas as possible out on the table concerning reference mode or model boundary) are best supported by nominal group techniques. We often use a technique that requires either individuals or small subgroups of two or three to generate lists of ideas or concepts. We then form a nominal group of the whole by moving from subgroup to subgroup asking each person or subgroup to contribute only one idea (presumably their best remaining one) to the growing list of plenary group ideas. We go around the plenary group as many times as is necessary to allow all the ideas to emerge. This nominal group approach is far more effective in divergent thinking tasks than, say, inviting the entire group together to brainstorm ideas together. The nominal group approach enables each subgroup to contribute and comment before any subgroup has given its all, no subgroup dominates, no subgroup is left with little to contribute, and ideas tend to emerge in order of importance.
CONVERGENT TASKS. Ranking of important ideas can be accomplished by simple voting tasks. Each member of the group can be given a fixed number of "importance votes" that are cast in favor of ideas, concepts, and tasks on the plenary group list. Alternatively, each participant or
subgroup can be given a sheet with peelable colored "sticky dots" and allowed to place these stickers as votes on important ideas on flip charts.
PRESENTATIONS. At key points in our sessions, the modeler/reflector gives the whole group structured reflections on their work to date. These one-to-many discussions with the client team sitting and listening are done at infrequent but critical times during the day. These are important opportunities for the modeling team to recap dynamic insights, capture and hold ideas, or simply clarify fuzzy thinking during the day. In our experience, these sessions go best after a break when the group is fresh. They often rely on written or projected material that both summarizes and moves forward the work done thus far.
Scheduling the Day The schedule is typically planned out in fifteen minute blocks with the task and group technology specified in overview and detail. The public agenda for the day is usually much more aggregated with one- or two-hour topics such as "stock and flow elicitation" or "feedback elicitation." Figure 2 shows a plan that was used for a one day modeling conference with the public agenda shown in the first column and the more detailed task and sub-group structure shown in the second column. We should stress that a wide variety of time plans are possible depending on time available, who is present, and the purpose (e.g., what are final products) of the meeting.
Whereas the guiding image for the planning phase of group modeling may be preparing for a theatrical show, the appropriate image for the execution phase is a chess player, jazz musician in concert, or coach executing a game. All three of these examples have in common the notion of flexible improvisation after compulsively detailed advance planning.
Guiding Principles for the Day Plan Before we discuss specific techniques that we have found to work well at various stages of the modeling conference, we first discuss some general principles that guide most all of our work.
BREAK TASK/GROUP STRUCTURE SEVERAL TIMES EACH HOUR. As shown in Figure 2, we typically envision the activities to change as frequently as every fifteen minutes. This type of detailed advance planning keeps the group alert, on task, and making progress. Groups that stay in a single mode for too long frequently become bogged down in a single issue, threatening the scope of the entire day or modeling conference.
START WITH A BANG. Our rule of thumb is that the whole group must be involved actively within 20 to 30 minutes of the opening on the first day. This means that the modeling team has no more than a half hour to explain what system dynamics is and what the group will be doing for the day. As discussed below, we have come to rely on "concept" models (Richardson and Andersen 1994; Richardson, Andersen, Rohrbaugh, and Steinhurst 1992) to facilitate this first critical half hour.
STRIVE FOR VISUAL SIMPLICITY. Even with a single set of icons set as a standard for the conference, the level of visual complexity that often emerges in modeling conferences is troubling. We use several techniques for dealing with this visual complexity. Often during the middle of a complex design task when the white boards or flip charts are getting very dense, over-marked, and visually confusing, the model/reflector will step in for a few minutes and provide a simplified and cleaned up version for the group. We note with some emphasis that this step must be done just as the group is ready to leave that chard of structure and move on. It is dangerous to have the model/reflector "clarify" a point and then turn it back over to the facilitator who then might get confused over the clarification and be put in a difficult situation. Visual complexity can also be fought by piece-wise construction of a complex diagram, in sectors. Discipline in diagraming is crucial: we have found it essential to maintain the relative positions of sectors on the white board as the group explodes the detail in one.
AVOID TALKING HEADS. Avoid having the facilitator, modeler/reflector, client leader, or anyone stand up for more than a few minutes delivering one-to-many information. There are important exceptions to this rule, but they invariably involve giving structured insight and feedback to the whole group near the end of the conference--wrapping up, summarizing, and clarifying points that the group has already agreed upon. We assiduously avoid explaining anything to the group that can't be discovered first by some other form of group process. Whenever we speak to the group, we strive to be in the mode of reflecting back to the group thoughts about points and insights that they themselves have already raised.
REFLECT AFTER EACH MAJOR PIECE. Brief and focused description and summary of what the group has completed and decided is the important exception to the "no talking heads" rule. We also believe and have empirically demonstrated in controlled experimental settings (Andersen, Richardson, Maxwell, and Stewart, 1994) that a conference will not succeed unless someone can stand up at the end of the conference and articulate easy to digest cognitive "chunks" (Simon 1969,1981) that summarize the insights of the day. If the group is left to grapple with the detailed complexity that invariably arises from system elicitation exercises, the whole enterprise will fail.
WIELD THE POWER OF THE PEN (AND ERASER!). The facilitator must always respond to the concerns being raised by the group but place on the projection screen, white board, or flip charts important insights that the modeler can use to structure dynamic insights. These are tricky roles. The editing power that comes from split-second decisions about what to write down and what not to write down shapes emerging conversations. Important comments that do not contribute to the modeling task need a place to be noted (a corner of the white board, a page on a flip chart) and processed by the group. Often times they can be erased later or typed up and given back to the group. The modeling effort is always under threat of being derailed by these important discussions.
MANAGE/PLAN FOR GROUP FORMATION. In conferences where participants are not already part of a management team, time must be allocated for the members to develop a group sense and arrive at internal group roles. "Ice breaker" exercises at the front end of the conference can help to speed and facilitate these processes. The modeling team has to be alert for the formation of counterproductive camps within the working group and rearrange tasks and groupings accordingly.
Clarifying Expectations and Products--Concept Models Since our intention is usually to move as close as possible to creating full simulation models, a problem that we typically encounter is how to clarify this as an expectation early on in the model conference. Typically, clients may have had no experience either with systems concepts nor with simulation as a tool. We use the technique of presenting a very stripped down "concept" model during the first 20 minutes or so of a modeling conference both the engage participants in the problem and to describe to them what a simulation model is. Figure 3 is an example; see Richardson, Andersen, Rohrbaugh, and Steinhurst (1992) and Richardson and Andersen (1994).
The purposes of the concept model are to introduce the stock, flow, and causal link icons to be used throughout the workshop, to demonstrate there are links between feedback structure and dynamic behavior, and to initiate discussion about the structure and behavior of the real system. The models must be visually very simple and contain, if possible, nothing but friendly algebra that can be shown if participants ask to see it. Because of these constraints and the sharply defined pedagogical purposes of these concept models, they are typically rather bad first cuts at system dynamics models. They are initially mostly open loop and constructed to hide as much diagrammatic complexity as possible by eliminating most parameter icons and being clever (but clear) in equation formulation. Yet they must lead the group in the direction of robust and appropriate formulations for the problem at hand.
Selecting scripts The main work in planning for a group model building conference is selecting the routines the team will use. Some scripts will be developed anew for the particular circumstances of the workshop at hand. But over time a number of scripts can become familiar frameworks with well-understood, predictable elements and known possibilities for real-time improvisation.
Scripted techniques for group model building Scripts for Defining the Problem Numerous approaches exist within the systems thinking, soft systems, and system dynamics literatures for eliciting problem statements from groups (see e.g., Lane 1993; "Modelling for Learning," special issue of the European Journal of Operational Research 59(1); "Systems
Thinkers, Systems Thinking," special issue of the System Dynamics Review 10(2-3)). We have tended to focus on the classical tool of reference modes sketched as graphs over time of problematic behavior and preferred behavior (Randers 1980; Richardson and Pugh 1981).
elicit ranked lists of the audiences for the study as well as what are some of our best guesses of the policy levers that might address the problems being studied. The ideas are classic system dynamics conceptualization issues (e.g., Richardson and Pugh 1981), addressed with facilitation by the group. The role of the modeler/reflector is often valuable in focusing the group on hidden or underlying issues as the problem is being defined by the group.
Scripts for Conceptualizing Model Structure Conceptualizing the structure of the system under study is perhaps the key group task in our work. We begin with a very simple picture of the system and add successive layers of complexity. As we add additional layers of complexity, we strive not to change the iconography of any of the previous work (for example, we would not shift from causal loops to STELLA diagrams). This implies that the first system visualization must use the same style and icons as the finished product. The concept model, often projected in the first 20 to 30 minutes of the modeling conference is a very simplified form of what the much more elaborated structure will look like at the end of the day.
SECTORS, A TOP-DOWN APPROACH. A first task will typically to ask the group to think through what might we the key sectors of the system to be conceptualized. Using diagraming methods first proposed by Morecroft (1982) and now embedded in STELLA and iThink (High Performance Systems 1994), we use these sector diagrams to start the group thinking systemically and to enable participants to maintain a systems perspective while developing the structure of a single sector.
MAINTAIN THE SECTOR OVERVIEW WHILE WORKING WITHIN A SECTOR. Careful planning of the sector overview will allow the sectors to be always present on the board as the group and the facilitator are working on details within a particular sector. Effects that emanate from the sector in process to one of the others off on the side can then be consistently drawn in the right directions. Visual chaos is reduced and participants can hold onto a consistent overview map as they work on details.
STOCKS AND FLOWS, BY SECTOR. Before adding full feedback complexity to the system diagram, we typically try to sketch in the key stock and flow structure for the system under study. When there is a clear flow structure this task is not difficult for client groups and generates good insight if the stock-and-flow structure is intricate. Typically, various members of the client group are expert in only one portion of the system and they take the lead when their portion of the system is under discussion. They learn quite a bit when other sectors of the system are under discussion. Eliciting the stock-and-flow plumbing works best when there is something like a vivid client flow structure and works worst when the stocks are not clear (e.g., modeling alcoholism or depression).
Scripts for eliciting feedback structure The last and most difficult task in conceptualizing model structure is getting the client team to think
in detail about the causal linkages that form the key feedback loops controlling the system. We have experimented with a number of tasks to assign to subgroups and plenary groups to accomplish this task, such as having groups tell verbal stories about what controls key levels or rates while the facilitator tries to translate these verbal protocols into causal loops of some sort. This has turned out to be a bad elicitation script for us because it tends to generate rather arbitrary closed-loop stories that often miss the most important feedback structures the modeling team needs to learn about. We have turned to less direct methods of eliciting feedback loop structure.
SYSTEM ARCHETYPE TEMPLATES. Some situations may be facilitated by providing participants with templates in the form of appropriate systems archetypes (Senge 1990). With sufficient preparation, participants in small groups may be able to identify structures within their organization that fit the pattern of a fix that fails, or a shifting the burden to the intervener, or a tragedy of the commons. In practice, we have found this technique less valuable as a conceptualization script than as a summarizing script toward then end of a group modeling conference.
CAPACITY UTILIZATION SCRIPT. The best technique that we have hit upon thus far involves comparing two key levels and asking the group to name this comparison. We then ask the group to describe what will happen when these two key levels get far out of alignment. This simple question naturally elicits feedback stories from client groups. Figure 4 shows one such elicitation exercise for a two such comparisons in a group modeling workshop on homeless policy in New York City. This script is extremely powerful, as it generates feedback structure without any teaching of circular causality. Positive and negative loops, self-reinforcing and self-correcting processes, and their implications emerge naturally, without teaching.
Scripts supporting equation writing and parametrization We tend not to do extensive equation writing "live" in front of a group because there is rarely enough time for this when the whole team is assembled and usually only a subset of the whole client team is interested in formulation details. However, we do use two simple techniques to elicit valuable formulation information from groups.
DATA ESTIMATION SCRIPT. If a two-day conference is going well, near the end of the first day there is probably enough detailed structure on the white boards to begin building a formal simulation model. Using a marker pen, we code the major stocks, flows, and parameters on the structure diagram(s) with which the group has been working. We then type up a list of all of these key variables and hand it out to the whole team. Using a nominal group technique, we ask the participants to fill in the numerical values for each major variable that they have been discussing for the day. Then all of the estimates from all of the participants are collected and shown.
In our experience, there is tight consensus on the numerical values for about three quarters of the variables under discussion. For the other quarter, the team may disagree by an order of magnitude
Families in income support or EAU
Families in assessment
Families in Tier II housing
EAU or IS capacity
Assessment capacity
Rate of placement in permanent housing
Perceived permanent housing available
Long-term entrance
Intake
Load Density
Short term entrants
Entry to assessment
Figure 4: A typical diagram from the New York City homelessness group model building workshop, showing the use of density ratios or vacancies to elicit from the group system pressures that close feedback loops.
Closing a group model building conference — End with a Bang We always feel best about our work when the last hour or half hour has a building climax to it-- when the team makes a clear and consistent effort to bring together all of the points made thus far in summary form. We believe that this is related to the notion of operator versus designer logic (Richardson, Andersen, Maxwell, Stewart 1994). At the close of a group modeling conference we need to move from the detailed design work of the day into policy chunks. But participants are tired; they are not ready for more work. Thus, our approach has tended to rely on modeler/reflector feedback, with different emphases depending on the situation.
One potentially powerful approach involves an overview of the model developed during the conference, moving from transparencies of sectors and structural details backwards to more and more aggregate overviews in order to leave participants with structural "chunks" they can carry away. A variant of this approach links model sketches to system principles or system archetypes to capture insights embedded in the work of the conference.
It is important to note what tends not to be successful at the close of a group model building conference. Written evaluations, while desirable and useful for team learning, are not the sort of "bang" that leaves participants excited and empowered. Consensus about policy is unlikely, unless the conference has progressed to a working model and had time to digest the dynamic implications of the structures formulated. Even then, consensus is unlikely unless the conference has targeted it from the beginning, developing the policy evaluative tools required by the situation.
The real end of a group model building conference is the list of next steps the group wants to take to benefit most from the intense work they have engaged in for one or two days, but again the
process must be managed to leave on an upbeat note.
Next steps in group model building research We believe the modeling community needs to share its various scripts for modeling in groups. Our work is only a beginning and only a small fraction of the existing group modeling wisdom. In addition to more scripts that modelers can learn, adapt, and adopt, we are interested in how the members of the group model building team improvise. How do they interact with one another and with the client group as the game plan evolves? A key process to learn to manage is the improvised interruption by the modeler/reflector to help the facilitator out of a problem or to move the group over a stumbling block or to fix an insight.
We have tried to train PhD students with solid modeling skills to take on the several roles that we have been discussed in our earlier work. In these apprentice-like sessions, senior modelers or facilitators tutor would-be group modelers in how to handle the minute-to-minute interactions that create enhance group modeling efforts. However, we have not yet been able to write down what is learned during these apprentice sessions and how it might be best learned.
References Carper, W.B. and T.A. Bresnick. 1989. Strategic planning conferences. Business Horizons (September-October 1989): 34-40. High Performance Systems. 1994. iThink™ 3.0, simulation language. Hanover, NH. Milter, R. G. and J. Rohrbaugh. 1985. Microcomputers and strategic decision making. Public
Productivity Review 9: 175-189.
Modelling as Learning. 1992. European Journal of Operational Research 59(1). Morecroft, J. D. W. 1982. A Critical Review of Diagraming Tools for Conceptualizing Feedback System Models. Dynamica 8(1): 20-29.
Randers, J. 1980. Guidelines for Model Conceptualization. In J. Randers (Ed.), Elements of the
System Dynamics Method (pp. 117-138). Cambridge MA: Productivity Press. Reagan-Cirincione, P. S. Schuman, and G. P. Richardson. 1991. Decision Modeling: Tools for Strategic Thinking. Interfaces 21,6.
Richardson, G.P. and A.L. Pugh III. 1981. Introduction to System Dynamics Modeling with
Dynamo. Portland, Oregon: Productivity Press. Richardson, G. P., D. F. Andersen, J. W. Rohrbaugh, and W. Steinhurst. 1992. Group Model Building. System Dynamics 1992: Proceedings of the 1992 International System Dynamics Conference, Utrecht. Lincoln, MA: System Dynamics Society. Richardson, G.P. and D.F. Andersen. 1994. Teamwork in Group Model Building. Working paper submitted to the System Dynamics Review. Richardson, G.P., D. F. Andersen, T. A. Maxwell, T. R. Stewart. 1994. Foundations of Mental Model Research. Proceedings of the 1994 International System Dynamics Conference,
