Policy Games for Strategic Management

Chapter 7 - Understanding the Policy Game Construct

by Richard D. Duke and Jac L.A. Geurts

7.2 Content

Webster’s definition of content, “that which is to be expressed through some medium, as speech, writing, or any of various arts,” is useful for game design. Content can be thought of as having three major components: substantive content (scenario and events), imagery (theme and analogy/metaphor), and the participants and their decisions (roles, perspectives, and decisions). These concepts are discussed below.

7.2.1 The Substantive Content

The substantive content providing context for the game is presented through the scenario and the events (and related materials such as workbooks, etc.). Serious games are typically presented in a real-world context (or hypothetical equivalent); this may be set in the past, the present, or the future. It is in this context that the payoff from the game will be achieved. It is essential that the substantive content be both accurate and relevant.

Scenario

The scenario (as used in conjunction with the policy exercise) is the story line (history, present situation, and appropriate speculations about the future) that all participants are given as the game begins. This provides a good background for the game and gets all participants off on an equal footing. It is normally lucid but brief; more detail will be presented to the participants as the game continues through the events and other material presented during each cycle of play (see the Conrail example, Section 3.4).

The exercise is typically presented to the players through a series of significant and relatively discrete problems that must be addressed in the context of the total system being studied. As the game proceeds, these problems follow one upon the next; and in complex games, several may be initiated simultaneously. Often referred to as “issues,” these become tangible handles that the player can use to enter into and explore the substantive problem. The facilitator must understand the sequence of messages that will be used to guide players into productive confrontation with the emergent realities of the problem. In developing the scenario, several questions must be addressed: How abstract or detailed should it be? Does the scenario have to mimic some existing source document? Can the participants modify it during play?

The use of the scenario parallels its use in a novel or in the performing arts. In each case, it becomes an integral part of the technique for conveying the plot. The scenario may be presented as a text, but frequently it will be supplemented with various devices to illustrate the present state of the system, including workbooks, functional interaction diagrams, flowcharts and other graphic materials. Frequently, brief role descriptions will be included for all participants to establish initial points of reference, and thereby establish a basis for discussion.

Events

Events are incidents presented to specific players, often in the form of a “newsletter,” at the beginning of each cycle of play to re-focus the attention of the player on a particular aspect of the problem. They are used to update the scenario as the game progresses; they initiate changes in the focus of the game and force players to make decisions. Events provide new information and this serves to make the game dynamic; they contribute information to the problems that players must solve. Events are very useful in helping the players to stay focused; they serve as a guide to program the discussion and keep the participants on track as real time passes during play.

Events can be of three types: programmed, triggered, and random. Programmed events are pre-designed to happen automatically during specific cycles of the game. Triggered events happen in response to some action of the players; they are precipitated automatically by the accounting system. Random issues represent a set of typical problems that might be productively explored, but their presentation to the players will depend on chance; the facilitator can also employ them if the discussion or play of the game lags.

7.2.2 The Image

The game designer must develop a mental image of the subject matter that the exercise is intended to mimic. The image refers to the primary impression to be conveyed by the game. Because games are used to address complex issues, the substantive content can be extensive (see Section 8.2.2, Clarifying the Problem). Two devices that can be employed to maintain focus for the discussion during a game are the “theme” and the “analogy or metaphor.”

Theme

The theme is defined as the substantive focus to be addressed by the game; it may be manifest as a major theme and/or as appropriate sub-themes. A major theme may be so all-encompassing that the game will not be useful unless specific sub-themes are employed for different stages of the exercise (for example, see Section 3.3.8, the Pharmaceutical Exercise). A game that is heavily loaded with situational content as a device to present a conceptual framework may be low on the cone of abstraction. As a consequence, the game may not convey a sharp sense of how the specific conceptual components are to be used.

Analogy/Metaphor

At some point in the design of every successful game, there comes a moment when purely technical constructs are transcended. It can be argued that games are part artistry, part technique; the key is to determine how best to inspire the “moment of magic” that brings the game alive! Through some combination of inspiration, experience and luck, a game construct is hit upon that conveys, as a lucid analogy, the heart of the problem being gamed. From this basic bedrock, various layers of technique can be added to meet client requirements.

An analogy/metaphor can be defined as one or more similes employed in a game to facilitate the gaining of insight. This can be thought of as imagery conveyed to the participants that increases motivation, enhances insight, improves communication, and adds a bit of fun. It increases the efficiency of idea transfer. An analogy may be represented by a series of small things or a single artifact or concept. In some cases, the initial artifact has limited capacity but is so designed that it can be increased in sophistication as play progresses (moving down the cone of abstraction).

The use of an analogy/metaphor assists with the ability to frame and retain concepts, (models, interactions, structures). These permit the mind to logically sort, store, and recall the significance of minutiae and to use these to create a new generic model that fits the situation at hand. Analogies permit the participant to look at a complex environment and develop a perspective (gestalt) that lets one assimilate the available knowledge and, as a consequence, to create a new operational model.

The primary objective of the game design team is to identify a powerful and appropriate analogy/metaphor (a “model of a model”) that the participants will recognize and endorse. This must capture the essence of the client’s problem. A prime benefit of the use of analogy/metaphor in games is that participants do not get sidetracked into working with trivial details. To illustrate, one client had a group attempting to redesign their physical workspace. They were working with detailed floor plans and there were endless arguments (because they knew too much about the specifics). A metaphorical game was designed that required the construction of an abstract space model; this distracted the staff from technical details and successfully focused their attention on interpersonal networking issues (the client’s primary concern).

The Rubber Windmill (Section 3.9) serves as another example. The simile employed mimicked the organization as a marketplace: there was supply and demand, payments and barter, market sharing of ideas and information, etc. Every design decision supported this metaphor, even the multi-colored T-shirts that the participants wore (which made the game room look like the floor of a stock exchange.) The Social Employment case (Section 3.7) also provides a metaphor, in the form of a decision tree with many branches. Each team had to select a path by collectively solving the puzzle.

The analogy/metaphor serves as a tool that can be used to encourage learners to transform information into new meanings for their own use. An analogy can enhance retention and make learning more memorable – participants often remember a game event of 20 or more years ago because the analogy used was simple and stayed with them. As a consequence, when the experience is debriefed, the questions relating to the transfer and application of insights gained from the analogy are the most important elements to be gleaned.

7.2.3 The Participants and Their Decisions

The essence of a policy game is the interaction of appropriate stakeholders (as roles in the game) through an appropriate model of the system being explored. The world frequently has too many interests (actors) to be represented in full detail in the game; as a consequence, some must be represented generically, while others must be excluded. During the development of the exercise, it is necessary to resolve which stakeholders will be represented, the needs and responsibilities of each role (task assignments, decisions, etc), and the level of personal experience required of each participant.

The concept report (see Chapter 8, Step 13) should include a detailed section specifying the characteristics of the intended participants; it should note any characteristic of the participant group that would have a bearing on game design. This should address: age, level of sophistication, prior training, previously shared experiences, professional status, educational background, the primary motivation for participation, etc. Other factors to be addressed would include group size (the number of participants expected to participate in the game), prerequisites (e.g. computer skills) required before being permitted to play the game, etc.

The design specifications should address the desired degree of participant involvement (this can range from an emotional emphasis to a more intellectual presentation). Design of a game requires a prior knowledge of the participant’s expectations. If players are highly motivated on arrival, the game need not be designed to entice them to participate. Other participants may require a more appealing design structure to achieve the suspension of disbelief necessary for full participation. A variety of incentives can be used to get participants to participate actively and enthusiastically.

A policy game is more occasion-specific than many other forms of communication. It is imperative for the designer to understand the audience’s motivation for participation and the typical conditions for use of the exercise. The more precise the understanding of the intended audience’s characteristics and motivations, the more effectively can various design considerations be employed to ensure a successful game.

Roles

Roles provide the primary actors with an appetizer to suggest what is possible in the “real world.” They are an essential element in achieving the suspension of disbelief that is required for productive communication in a game. Roles describe a hypothetical set of interests, knowledge and responsibilities that are attributed to a given participant (or team). They serve as a device to minimize the injection of the personalities of the participants into the game and to provide some freedom of action to players. The identity of a given role may be a person, a corporate structure, a public entity, or some abstract phenomenon. The roles in the games interact with each other and with the game environment. Players interpret their roles through the model, the decision feedback mechanisms and through interaction with other roles. Many experienced game designers advise that players not be given specific instructions about playing a particular role as it is too easy for them to later deny responsibility for their actions (they may blame the constraints of the role). Similarly, it is generally accepted that assignment of attitudes and values along with the role should be avoided or minimized.

The game designer must give careful thought to role selection. Material that is being created from various components of the game (e.g. a simulation) must be directed to the proper role; conversely, information that is obtained from a given role must be processed rationally through the accounting systems. The output from all decision points must have a specific target(s). Roles will generally be limited in number to those most central to the system. Descriptions of roles should be predicated on known real-world counterparts. By deliberately structuring a role so that players are required to deal at a strategic level, or by placing the role under constraints not normally found, the occupant of the role can manipulate the system from a new perspective. Frequently, roles are incorporated into a game to permit the participant to experience the system from a context not available to the player in the day-to-day activities of the organization.

There are three types of roles: gamed (real players making decisions), simulated (theoretical players), or pseudo (present, but their decisions do not enter into the accounting system):

Gamed Roles are personally present at the time of the gaming activity; they represent decision makers selected from the client’s environment. They are required to interact with the other players and to make decisions that are processed by the accounting system.

Simulated Roles are not represented by a human player; rather, they are represented in the mechanics of the game through a simulation, the model, the accounting system, and/or other mechanisms. They are used to generate output useful to gamed or pseudo roles. A simulated role can be more useful than a gamed role because it successfully avoids the idiosyncratic response of an individual player; it can also be used to represent a broad class or category of data.

Pseudo Roles are distinguished from gamed roles in that they interact with the participants as “experts”; their decisions may influence players but do not enter into the accounting system. Pseudo roles are frequently “on the spot” inventions (played by the facilitator or a guest) to assist in circumstances not provided for in the original design. They can be used as a tool to be used judiciously to solve unexpected game developments.

Players may be organized as individuals, coalitions, or teams, as appropriate. Roles present the viewpoint of a single individual; perspectives (roles structured as multiples) are designed to present the perspective of an interest group. The decisions, however represented, are the heart of the game – they must be explicit and systematically evaluated by the accounting system; their outcome establishes the ultimate value of the game.

The Rule of Three argues that individual decision makers (roles) should be used sparingly. When possible, three roles should form a team with a single perspective; this group must work together to make a single decision. This device requires a richer and more thoughtful investigation of the information at hand; the resulting decisions are inclined to be less arbitrary than those from an individual acting alone. These coalitions should be predetermined during the design of the game. Teams may be formed as parallel entities, identical in structure (whether competitive or cooperative), or teams may be distinct groups, each charged with a separate function. The success of a game is heavily influenced by player organization.

In addition to these roles of an operational nature, there are individuals present during the course of the game associated with the administration of the exercise. From an administrative standpoint, facilitator(s) will be needed; there may also be observers, role adviser(s), a bookkeeper, and other specialists (see Chapter 8, Step 18 – Facilitating the Exercise).

Role manuals must be available for each player type; these must give the participant a clear sense of the nature of the role, the activities they are to complete, their relationship to other players, etc. Some of the content of each manual can be duplicated (e.g. a drawing showing how all players relate to each other, steps of play, etc.). Role manuals range from a single sheet of rules to a volume; both extremes are uncommon and probably somewhat ill-advised. The role manual should present, in abstracted form, some of the central questions addressed in the concept report (See Chapter 8, Step 13). The role manual should include a statement of the game objectives and an overview of the big picture, using flowcharts, tables and overview schematics as appropriate. The role manual should also introduce the game-specific symbolic structure, the steps of play, an introductory scenario, and one completed cycle of decision forms (this helps participants understand the process and gives them a starting point for the exercise). Materials that will be used frequently for reference purposes throughout the game should be included as part of the Appendix. These may include maps, data tables, and charts or other graphics that help in maintaining a perspective of the total system.

Decisions

One key to a successful policy game is the requirement that all participants make and defend decisions. Decisions are defined as the irrevocable selection and/or allocation of actions required of roles during each cycle. The actual mechanisms for obtaining these decisions vary from role to role, but may include completing decision forms, negotiation, developing and implementing strategies, nominal group techniques, Delphi-like techniques, and/or voting (avoid voting whenever possible -strive for consensus instead).

A good game will require players to commit themselves to decisions at the earliest possible moment; this process of commitment should grow in complexity and precision as the game progresses. Decisions must relate logically to the roles/perspectives as well as to the model being investigated. The participant must be held “publicly” accountable for the decision(s); this serves as the trigger for an exchange of ideas. Decisions should be structured based on the system schematic (see Chapter 8, Step 7). When the specific decisions are being developed, it is important to focus on role-specific decisions (number, clarity, etc.); sequence of decisions (orderly progression from step to step); and the linkage of decisions (orderly progression from player to player).

Decision points may be simultaneous or in rotation. If decisions are presented as a series of player “turns,” the play is more sequential than if simultaneous decision making is used. Desirable practice involves simultaneous play, with all teams reaching decisions at about the same time. Nonetheless, there may be good reason for sequential decision making (e.g. having each team focus on the activity of other teams). After the initial cycle, as the players become more proficient with their own decision making process, they become increasingly aware of what other players are doing. This facilitates the conveyance of gestalt about the system. The real world rarely presents us with circumstances in which the players perform in turn, permitting the others to observe. Quite the contrary, things usually happen more or less simultaneously; it is only through a great deal of experience that we gain the “maturity” that permits us to understand complexity.