RRTF Golden Guardian Scenario Prep

Create multiple checklists of desirables

Before laying out the scenario, create lists of what you want included in the scenario, then as you create the scenario, mark off the items as they are included. As the scenario is iterated/refined, some items will be removed - temporarily or permanently - or moved to other sections of the scenario. Having separate checklists greatly facilitates this process.

You typically wind up with a fairly fine-grained listing of the desirables because, as you try to fix items from the list into various slots in the scenario, you wind up subdividing them into component parts - some which fit there and some which will have to go elsewhere or be omitted. You can start with only a high-level list of desirables, and let the scenario-creation process drive the enumeration of the components, or you can try to do a lot of the decomposition early in the process (understanding that there will be some changes later). The choice/balance depends upon the size and dynamics of the group.
Caveat: I have never done this in a group as large as the RRTF. My experience has been with a layered environment, where the scenario is primarily the work of 1-2 people taking comments from two larger groups: a interactive group of 5-10 in a conference room (lots of white boards), and a larger group

Some checklists for RRTF Golden Guardian:

• Functionality to be exercised/experimented with. Examples:
  • Notification via the new community alerting and notification system (many components)
  • Communication by handheld radio between Block Coordinators and Neighborhood Coordinators and CERTs (PANDAs)
• Situations/problems to be addressed: Examples:
  • Block Coordinators not available full-time
  • Parents are trapped at work (eg quarantined workplace) - how to handle their children?
• Results / Capabilities to be demonstrated: Demonstrate that you solve some important problem of theirs (Why they should bother to have anything to do with you).

Scenario elements have list of explicit slots

As you build the scenario, each element should have a list of slots to document what you are trying to do in that scenario element. This helps avoid the common problem during scenario refinement - You fail to take into account all the implications of a change.

A start at a scenario element block:

• Theme: What is the purpose of this scenario element?
• Action summary: high-level description of what happens
• Cast: who is involved (so that various players can see where they are involved)
• Locale: geographic/info-space location (to help id which elements are of concern to which players)
• Location in the scenario:
  • Prerequisites: what it requires to have already happened
  • Enables: what subsequent elements depend upon this as already having happened.
  The final scenario is linearly ordered, but early versions are partial-orderings - You often find it convenient to move an element forward or backward in time to accommodate additional components, but you want to avoid inadvertently breaking those dependencies.
• Checklist items addressed
• Evaluation: How do we determine how effective we have been. Example:
  • Notification by community and notification alerting system: part of message asks people to go to a web site and answer a few questions about the call they just received.
• Detailed actions within this scenario element. Notice that I put this as the last slot - My experience was that if I put this near the beginning, I often forgot to double-check what followed it for inconsistencies and out-of-date entries.
  Some of these actions fit into recurring categories, and those categories should have explicit slots or tags. Examples:
  • Information distribution/HA: Information injected into the RRTF portion of the exercise from "higher authorities" (HA), for example from the City of Palo Alto Emergency Operations Center (CPA EOC)
  • Information collection/HA: Information collected by the various players within the scenario at the request of "higher authorities".
  • Information distribution/Internal: Information distributed where the players are all/mostly part of the cast of this scenario.
  • Information collection/Internal: ditto
  • Information fusion: Correlating and summarizing the raw data.