Working for and at IDL is always a pleasure. The Directing Staff (DISTAFF) are always determined to deliver the most effective educational wargame possible, but they are also prepared to listen to and act on advice. In contrast to many other institutions with a high staff turnover, continuity is maintained and lessons learned carried forward. Hence the full wargame cycle described on the How we do it page (design – develop – execute – validate – refine) is enacted. The result is a first class educational CAX with all elements of the wargame combining to deliver well defined Training Objectives (TOs).

A full wargame design workshop was run for the first iteration of JOINT CHALLENGE in its current form. This lasted a day and was based around the ‘design’ steps outlined on the How we do it page and detailed in the ‘Avoiding Common Errors in CAX’ article on the Resources page. The start point was, of course, the anticipated TOs.

Each step was worked through using a three-column format mechanism adapted from that used by the UK Armed Forces for conducting estimates. The columns are: Fact (or) – Consideration (‘so what’) – Output (Decision or Action). The outcomes of the third column will be one of:

• Real-world (pre-exercise) action
• Exercise task
• Requires briefing
• Include in Master Events/Injects Lists
• Tool-set related action
• Process related action

Is this obvious? Yes. It is also just a variation on an existing problem solving mechanism. But such workshops are seldom held. It is amazing how often Step 1 results in a frenzied scrabble to try and find the TOs, which either don’t exist or have not been re-visited in the recent past.

An extract from the full document produced for IDL as a Record of a Meeting (the audit trail required in Step 7 of the design process) is shown below by way of example.

This logical and thorough design process – involving the military, operational analysts, software engineers and a wargame designer – ensures a sound basis from which all elements of the wargame are derived. These are then developed in a distributed but collaborative manner. Examples are the development of the scenario, including MEL/MIL serials and any software changes to enable features of the COE to be modelled, or at least represented on the JOP. The outcomes of the design process directly feed in to, and are briefed at, the Initial Planning Conference. All key stakeholders attend. Briefing the design outcomes allows these to be discussed, confirmed or refined, and so ensures stakeholder buy-in. Work then continues in a distributed fashion.

Final confirmation of the developing exercise occurs during the 3-day Main Planning Conference (MPC), and is the Test Exercise (Testex). The Testex is a key activity. It is a full test of 24 hours worth of Excon battle rhythm, involving as many of the final Excon staff as possible. These personnel attend the MPC or are IDL DISTAFF. The aim of the Testex is to try to break all Excon and exercise processes; to stress the game mechanics, including the simulation, to identify areas of weaknesses. Any that are found are remedied immediately or, in the case of software issues, subsequently.

Because the Testex runs concurrently with the MPC, outcomes can be briefed back in central plenary. Testing 24 hours of Excon battle rhythm does not mean personnel staffing Excon for 24 hours! Meetings are held at the times they would be during the actual exercise, processes are discussed and adjustments made. The simulation used to support the exercise (the Joint Operational Command and Staff Training System – JOCASTS) runs throughout so simulation outcomes are fed into the Testex. This allows both the simulation and Excon processes to be tested. It is usually difficult to define in advance what problems will be identified during the Testex. What is certain, however, is that it is always considered an essential activity once it has taken place!

Exercise development is finalised at, and immediately after, the MPC. Activity at the Final Planning Conference concentrates on administrative matters. The only elements of the exercise that continue to be refined are MEL/MIL serials and any Blue Hicon documents such as Initiating Directives. These are produced immediately prior to Startex by small writing teams that come together a day or so before the students start reading in.

The ABCA Interoperability Gap Analysis Study (IGAS) was an analytical event held in Australia during 2006.

The approach taken was based on Seminar Wargaming (SWG). The aim of a SWG is defined by the UK’s Dstl as being ‘to promote structured discussion between experts in several fields and to elicit opinions and judgements from them, and to increase understanding.’

The ABCA IGAS used the following method:

1. Introduction. The facilitator explained the scenario, methodology and scoring system. The scenario was based on events during the Iraq war and the 2nd battle of Fallujah.
2. Vignette brief. A specific vignette, derived from the scenario, was briefed. Each vignette was designed to draw out as many interoperability issues as possible e.g. cross boundary casevac, the forward passage of lines of a reserve, coordination of fires etc.
3. Discussion. Syndicates discussed pre-determined questions, based on the vignette just briefed. There were 6 syndicates, each facilitated by analysis staff intimately familiar with each vignette, its branches and sequels, and the potential interoperability gaps arising from it. Discussions were encouraged to be wide ranging so as to capture as many issues as possible. Participants were drawn from all nations and military arms. They were expected to lead on their own area of expertise and to introduce as many interoperability gaps as possible, explaining the significance of each. Each syndicate would then draw up their list of top 10 interoperability gaps, and their significance.
4. Plenary. Central plenary sessions were held, chaired by the lead facilitator. Each syndicate briefed the others on their findings and reasoning. This was designed to give individuals as great an insight as possible into each potential interoperability gap.
5. Formal data capture. All participants were asked to subjectively score each identified interoperability gap in categories including: impact; likelihood of occurrence; and ease of mitigation.
6. Repetition of steps 2- 5 for each vignette. There were 10 separate vignettes. Each cycle took approximately 3 hours, so 3 vignettes were analysed each day.
7. Analysis and recording. Various analytical methods were used to sift and rank the identified operability gaps. This took the entire second week. The output was a table showing 50 well defined interoperability gaps, their significance and ranking according to the judgement of expert participants. This formed the basis of ABCA interoperability activities for the next 2 years.

Observations and lessons arising:

1. SWG is a qualitative technique. It is therefore useful for conducting a preliminary sift of options but lacks the resolution to compare generally similar options. However, a well run SWG increases the chances of getting the subsequent analysis right.
2. SWGs can:
- Identify key issues in a plan or operating model, promote understanding, confirm assumptions and stimulate potential collaboration between stakeholders;
- Prompt discussion of concepts of operation of novel systems;
- Elicit opinions on the relative merits of widely differing system concepts;
- Focus and narrow the scope of a study;
- Suggest measures of effectiveness for subsequent quantitative analysis;
3. SWGs are not suitable for:
- Providing any form of quantitative measure of effectiveness;
- Comparing generally similar systems (e.g. one type of tank vs another);
- Representing C4ISR systems;
4. Because they lack a combat simulation system, operational CIS and structured battle rhythm, most people think that it is possible to ‘make things up as they go’ during a SWG, and that they are no more than a BOGSAT (Bunch of Guys Sat Around a Table). This is absolutely wrong; SWGs often need more rigorous preparation and planning than other types of wargame precisely because there are few external stimuli other than peoples’ imaginations. During IGAS the selection of the scenario and preparation of vignettes was key to drawing out interoperability gaps.
5. This prior preparation and planning must include rehearsals with all facilitators and analysts.
6. Success depends on having the right people participate. This includes a strong Red and White Cell; they are often overlooked. The Red cell ensured that frictions are introduced that drew out interoperability gaps.
7. SWG strengths are:
- They are rapid.
- They are relatively inexpensive.
- They are relatively few resources required.
- They are good at capturing knowledge from a wide variety of sources.
- Ideas from ‘outside the box’ can be considered.
- Real-time statistical testing can examine the alignment of SME sub-groups, thus allowing differences of opinion to be investigated immediately.
8. SWG weaknesses are:
- Results are totally panel dependent; people think they know how events will unfold – but are they right?
- They are open to abuse through misconceptions.
- Perceptions can be formed that prove difficult to change.
- They can be anti-innovation, since they are based upon knowledge and past experience of panel members.
- They are open to the panel being ‘led’ by poor questioning and preparation (including items such as scenarios, ORBATs, timeframe selection etc).

Apparently obvious, achieving a common understanding is not always as easy as it might first appear. Talking the same language is an important first step in any project related to wargaming. This was exactly what we suggested on becoming involved in the NATO Allied Command Transformation (ACT) Shared Scenarios Project. The resulting set of key definitions were a major contributor to the success of the Project and the establishment of a NATO portal via which scenario material can be used and re-used by NATO and national exercise designers and across the modelling & simulation industry.

Although people think they are talking the same language, our observations showed that they don’t. This often results in them talking at cross-purposes and thinking that they have agreed something when they haven’t!

One example: the term ‘scenario’. Anyone from the US Joint Force Command (JFCOM) referring to ‘scenario’ is talking about the entities that constitute the force elements in a simulation; essentially all components of the order of battle (ORBAT) of friendly, enemy (Situational Forces or SITFOR) and neutral forces. This might include equipment, ammunition, characteristics etc, their relationships and so forth. This information is usually held in one or more data bases. On the other hand, personnel from NATO’s Allied Command Operations (ACO) and Joint Warfare Centre define ‘scenario’ as ‘the background story that describes the historical, political, military, economic, cultural, humanitarian and legal events and circumstances that have led to the specific current exercise crisis or conflict’. These are completely different things. So what do you think people from these respective organisations would think is meant by ‘Rapid Scenario Generation’? To someone from US JFCOM it will concern the timely exchange of ORBAT- and SITFOR related data; to someone from NATO it will concern the correct identification of the required elements of a scenario and the efficient production of scenario – a process measured in years.

Some key terms, and their definitions, identified as part of the NATO Shared Scenarios Project were:

Setting: ‘A geographic and strategic situation designed to provide all the conditions required to support the achievement of high level exercise aims and objectives. The setting, which can be real world, fictionalised or synthetic, is the framework on which the scenario can be developed.’
Scenario: ‘The background story that describes the historical, political, military, economic, cultural, humanitarian and legal events and circumstances that have led to the specific current exercise crisis or conflict. The scenario is designed to support exercise and training objectives and, like the setting, can be real, fictionalised or synthetic as is appropriate. A scenario will be composed of specific modules, event and inject serials and technical data essential to the accomplishment of the exercise objectives or of the seminar/academic/experiment objectives.’
Data Repository: ‘A logical (and sometimes physical) partitioning of data where multiple databases or data that apply to specific applications or sets of applications reside’.
Data Warehouse: ‘A facility for the storage of an organisation’s electronic data structured to facilitate active querying, manipulating, reporting and analysis. How the stored data is structured has nothing to do with whether something is a data warehouse’.
Library: ‘The portal through which the catalogue of material stored in a data warehouse can be viewed. The methods by which data is accessed are explained in the library, but the process of gaining permission to access the data is a separate function.’

The UK’s Land Warfare Centre (LWC) is investigating the potential to enhance mission specific training by deploying a mobile wargame to unit lines. This would be used by unit and sub-unit commanders and their staffs to practise, by way of example, operations room procedures and command and control at sub-unit level. The proposal was to deliver a ‘mini Command and Staff Trainer’ wargame with a small Excon to a Training Audience in their own unit lines. The wargame would have one or two simulations supporting it, providing situational awareness, combat outcomes and influence – or non-kinetic – outcomes. It would be delivered by a small team deploying all the kit they needed from a single transit van. They would have discussed the Training Objectives with the unit previously and would set up and conduct the wargame with the minimum of disruption to the host unit.

The wargame design team was presented with an opportunity to debrief personnel just returned from operations. This opportunity would be used to investigate the user requirement for the proposed training wargame, based on the experience of people who had just gone through mission specific training and then deployed on an operational tour; who better to ask whether such a training wargame would be of use? Participants ranged from several key brigade staff and augmentees (for example a Cultural Advisor) through a unit 2ic, company commander and down to a multiple commander.

The event was run as a seminar wargame. The UK Dstl definition of a seminar wargame is to ‘promote structured discussion between experts in several fields and to elicit opinions and judgements from them, and to increase understanding’. This was adapted and the event aim was to ‘elicit opinions and judgements from experts to shape the development of all elements of a mobile training wargame’. A seminar wargame is a qualitative technique and is therefore useful for conducting a preliminary sift of options; exactly what was required in the scoping study phase for the training wargame.

Note a key element from the Dstl definition, above: ‘…structured discussion…’ A well considered and controlled discussion is a key component for success; otherwise an event simply becomes a BOGSATT (bunch of guys sat around a table talking). A BOGSATT rarely delivers as much as a well structured seminar wargame.

The format selected to ensure a structured discussion was lifted directly from doctrinal Course of Action (COA) wargaming. The mechanics of a COA Wargame are discussed in detail in articles found on the Resources page; suffice to say that the fundamental Action-Reaction-Counteraction process between two teams guaranteed that the research topics were fully covered and the necessary opinions were elicited. One team was essentially ‘blue’ while the other was ‘rainbow’, covering all other actors.

A basic scenario was presented to the participants. They were then taken through a series of vignettes, designed to cover all aspects of operations in the contemporary operating environment. Plenty of thinking time was allowed. Whichever side was considered to have the initiative started with the ‘Action’ and presented their plan and the factors they had considered. The other team had the ‘Reaction’, detailing their pre-considered plan and the factors they had considered. The ‘Counteraction’ had two parts (after a suitable time for consideration): the classic response by the side with the initiative (as per a COA Wargame); but then – far more important – how the discussion affected the development of the proposed training wargame.

At the end of the event a final plenary was held to ensure that all research topics and specific questions had been covered, and to give everyone a chance to make any final points.

The fact that the approach adopted ensured that everyone remained engaged and took ‘ownership’ of the event outcomes is incidental. The main point of this case study is to highlight some of the differences between three types of wargame: the training wargame; a seminar wargame; and COA Wargame mechanics. Each of these has difference aims, objectives and mechanics. When these differences are well understood it is possible to harness the required aspects of each to deliver powerful benefits; in this case the successful shaping of a training wargame that will, it is hoped, better prepare troops for operations and possibly save lives in the process.