Integration of RCAT with ABACUS and EXONAUT

The broad processes required to integrate RCAT into Ex IR 14 are at Figure 1. The detailed processes specific to RCAT integration are broken out at Figure 2 and explained below. Note that the principle underpinning the entire process was that all kinetic combat outcomes and non-kinetic soft events were to be pre-considered at least 24 hours before they actually occurred, allowing the Game Controller (HQ 3 Div SO2 CT6) to shape the exercise to ensure Training Objectives (TOs) were met. The agreed outline events were then coordinated and enacted in real time the following day using the ABACUS computer simulation and EXONAUT events and injects management system.

Figure 1. Outline RCAT integration process

Figure 2. Detailed RCAT integration processes used during Ex IR 14

The key points pertaining to each sub-process are:

RCAT Operational Analysis (OA) estimate. The RCAT team provided a classic ‘support to operations’ OA function, based on the brigade-level Lower Controller (Locon) plans. These were discussed with the Locons and key Excon personnel (primarily the Game Controller, Chief MEL/MIL and Chief Hicon), who deterministically decided the spread of outcomes that best suited the exercise TOs. The key outcomes of the OA estimate, moderated by the Game Controller, were:

1. The desired End State for X Day that Locons were to try to achieve.

2. Parameters within which Locons should try to fight engagements using ABACUS in real time on X Day. Should casualties exceed these parameters, Locons notified the Game Controller before declaring results to the Training Audience (TA) to ensure the exercise X Day End State would not be compromised.

3. A pre-considered ‘OA outcomes’ brief of the above to be delivered during the primary RCAT estimate of X Day tactical activity. This enabled a much faster RCAT X Day estimate, as opposed to trying to determine OA outcomes during that actual event.

Figure 3. RCAT OA estimate in progress

RCAT estimate of X Day events. This was the primary RCAT activity and took place in three distinct sub-turns: operational ‘flanks’ activity; tactical events; and a subsequent Consequence Management phase. The operational level Area of Operations-wide map allowed consideration of the flanks and wider picture in order to paint a rich context for divisional tactical-level operations at the detailed RCAT ‘bird table’. Both activities were based loosely on Course of Action (COA) Wargaming processes: Action-Reaction-Outcome Determination-Consequence Management.  Kinetic activity had been pre-considered during the OA estimate. All cells participated in the turn, which covered a 24 hour period. The RCAT turn order, which can be flexible, was: Blue (friendly forces) – Green (Host nation forces) – Red (conventional formed enemy) – Orange (Armed Non-State Actors) – Black (Organised Crime) – White (Humanitarian and other Human Terrain) – Grey (political and media). Key outputs were:

1. A rich ‘flanks’ context for the TA to operate within.

2. An estimate of the appropriate X Day events that would take the exercise towards the TOs, moderated and agreed by the Game Controller.

3. Outline injects for detailed scripting in EXONAUT.

Figure 4. RCAT operational- and tactical-level estimates in progress

Provisional Consequence Management (CM) X Day estimates. CM asks the ‘so what’ questions of the anticipated X Day events to identify the 2nd- and 3rd-order effects of in-turn activities at the military-strategic level. These effects were noted as provisional on the RCAT CM map table using ‘interim’ markers. They were continually reviewed during the next day (X Day) and refined as required. The CM process provided the majority of Commander’s Assessment Update (CUA) material and the points most likely to affect the TA commander (GOC 3 UK Div) at the military-strategic level.

Figure 5. RCAT CM phase in progress

Master Events/Injects List (MEL/MIL) Coordinating Conference (X-1 1700 hours). This followed the primary RCAT estimates at the operational, tactical and military strategic levels. The agreed MEL/MIL serials from all RCAT X Day events (including provisional CM) were discussed and coordinated. For example, any anticipated mass population movements that occurred in several Locon areas were synchronised and lead cells assigned to coordinate MEL/MIL serials.

EXONAUT scripting. The agreed and coordinated MEL/MIL serials were then scripted into the EXONAUT management system. EXONAUT prompts Locons and cells when to actually inject each serial.

MEL/MIL Coordinating Conference (X Day 0730 hours). Serials for the forthcoming day were confirmed, having been scripted the evening before. EXONAUT then automatically sends a ‘Task, Condition and Standard’ statement to the Mentors who observe serials being played out in real time by the TA during X Day. Although based on the RCAT estimate from the previous day, the predicted events proved sufficiently accurate to provide the basis for serials with only occasional and minor refinement at the point of injection.

X Day ABACUS simulation. ABACUS is a real-time computer simulation that was used for movement and to resolve kinetic combat activity. It does not model, but can represent, non-kinetic activity. For example, refugee flows were determined during the RCAT estimate and an icon placed in ABACUS that would show on the TA Common Operations Picture (COP). Locons would ‘fight’ ABACUS in line with the agreed RCAT estimate OA outcomes. Where these differed markedly, the Locon would inform the Game Controller who would adjudicate the results or allow them to stand (but understanding the effects of this in the anticipated End State). Hence RCAT was used to shape ABACUS outcomes, but not dictate them.

RCAT CM confirmation. At about X Day 1430 the provisional CM ‘interim’ movements estimated the day before were reviewed, refined if necessary, and then confirmed. These provided:

1. The initial brief for the following RCAT operational level context event; and

2. Key points for the following morning’s CUA.

Recording. SO2 Excon Coord provided the scribe function for all RCAT turns and events and, from these, produced the key MEL/MIL agenda that enabled population of EXONAUT. A separate photo record was taken of all RCAT turn start and end positions.

Benefits delivered by RCAT

The principal remit of the RCAT team was to provide the non-kinetic ‘wrap-around’ context and game play for the ABACUS-delivered Ex IR 14 kinetic events. RCAT went beyond this by providing or enabling the capabilities listed below:

Adversarial and oppositional game play. The RCAT process demands that all cells play the represented factions and actors in an adversarial manner. Where appropriate, oppositional factors are introduced e.g. Clausewitzian ‘friction’.

Dynamic and imaginative scenario development. While pre-scripting major events and injects can sometimes work well, the RCAT method of dynamically determining the scenario story-line adds significant depth and richness to the context. Key TOs are ‘way points’ along the dynamic route delivered by RCAT. Most major Ex IR 14 events arose from unforeseen free-play actions e.g. the key ‘state within a state’ situation arose from the Orange Cell taking advantage of Red abandoning a city and then operating using a combination of ISIS and Hezbollah tactics. Figure 6 shows examples of products developed to support and visualise this story line in one province and city.

Figure 6. Trend Analysis Output and Population Consent and Threat Chart

Military-strategic consequences. The RCAT CM phase translated tactical actions taken by the TA into operational- and strategic-level ramifications. These formed the basis of most days’ CUA.  Three of the four final CUA bullets were derived from dynamic RCAT mechanisms: the ‘state within a state’; an Internally Displaced Persons camp in close proximity to a kinetic engagement; and Collateral Damage to a major oil pipeline.

The ability to pre-consider events 24 hours in advance and thereby shape the exercise to best achieve the TOs. The RCAT ‘estimates’ proved sufficiently accurate to allow the Game Controller to adjust game play and identify and carefully monitor real-time outcomes that might have adversely affected the exercise.

ABACUS parameters provided by RCAT OA estimates. The 1100 RCAT OA meeting with the Game Controller, Chief Hicon and Locons enabled an informed discussion of likely combat results 24 hours before they occurred. This provided an agreed End State that Locons and ABACUS operators were to try to achieve and casualty parameters to work within. All were flexible, and Locon Mission Command was enabled. However, if a casualty parameter was breached, the Locon informed the Game Controller. He could then moderate results or allow them to go ahead in the full knowledge of how this might affect the End State and achievement of the TOs.

Non-kinetic ‘soft’ effects and Human Terrain. The RCAT mechanisms, combined with fully staffed and imaginative White, Orange, Black and Grey Cells, delivered the primary remit of a rich non-kinetic exercise context ‘wrap around’.

Fun. RCAT is fun. Wargaming and manual simulations are fun. There should be no embarrassment in making this statement. Fun equals engagement equals more work (work is fun, too!), and hence a better and deeper context provided by Excon.

Issues arising from the use of RCAT

No issues arose using RCAT that were not quickly resolved during the exercise by making minor modifications to the process and timings. The concern that RCAT was unproven and an unknown quantity was quickly laid to rest. The only – unfounded – potential issue that had not been comprehensively addressed by Endex was the possible discrepancy between RCAT OA estimates and ABACUS outcomes. Although the RCAT team was confident throughout that RCAT and ABACUS outcomes would be broadly similar, quantitative analysis was not available during the exercise to prove this. Subsequent analysis showed that the RCAT and ABACUS outcomes were close enough to satisfy the exercise requirement.

Recommendations for the future use of manual simulations

Manual sims could be used to support future exercises in a number of ways:

1. MEL/MIL EXONAUT scripting week. A two- to three-hour facilitated play-through of the likely scenario(s) would enable MEL/MIL scripters to gain rapid situational awareness of the geography, ORBATs and likely ‘shape’ of the overall exercise. Armed with this understanding of the exercise context they could better prepare EXONAUT injects.

2. Exercise design. A good manual simulation enables consideration during exercise design of aspects such as balance of forces and the identification of key factors, factions and actors to be played into the exercise.

3. Execution. Little preparation is required to use manual sims to support brigade- and divisional-level exercises. The processes described above provide the starting point for future events.

A Complementary Approach

None of the above recommendations imply that a manual simulation can deliver an event like Ex IR 14 without an exercise management system such as EXONAUT (or the NATO JEMS) or a computer simulation such as ABACUS (or any of the many alternatives). An entirely complementary approach is required. For example, EXONAUT provided the detailed injects management, recording and distribution to mentors functions, while ABACUS delivered combat outcomes, movement, logistic ‘bean counting’ and a distributed COP; manual simulations do little of this.

Designing, developing and delivering a computer assisted training wargame working from a completely blank piece of paper is a rare opportunity. The following ‘worked example’ takes you from that blank piece of paper to the delivered Simulation-Supported Exercise (SIMEx). An overview of the complete process is below.

Design

The training wargame design steps are shown below. This is predicated well-considered Training Objectives (TOs) available. It is amazing how often I ask for these to find that no-one knows what they are!

Training Wargame Design Steps:

1. Specify the exercise Aim and TOs.

2. Identify the people to be trained, their roles and the decisions they will be expected to make.

3. Determine the desired effects on the players, and the exercise activities required to achieve these.

4, Determine the setting, scenario and types, level and sources of information the players will need to make their decisions and to enable the TOs to be achieved.

5. Identify the structures and processes required to achieve Steps 3 & 4.

6. Identify or design the tools, technology and SMEs needed to populate and enable these structures and processes.

7. Create an audit trail by documenting all decisions taken and the reasons for them.

The steps are self-explanatory. Apparently simple, it is important to consider each comprehensively. We did this in a week-long ‘Design Workshop’ in Qatar in July 2013. An example of the output, using a Staff College-style 3-colum format, is below. Done properly, do not expect a design workshop to take less than a day – plus the write-up.

Note:

Along with significant project management outputs, the Design Workshop write-up formed the basis of Step 7. This shaped all subsequent development and the actions must be extracted and managed. Among other things, the Design Workshop identified the setting and scenario parameters, and these were then written during the development phase.

Training wargame development steps are:

1. Validate the scenario, simulation model(s) and data to ensure these support the exercise aim and TOs. If fictionalised, these must also be sufficiently realistic to allow participants to ‘suspend disbelief’ and become immersed in the environment.

2. Play-test the technology, especially the simulation(s); try to break them. Ensure that the simulations contain the correct level of detail and are playable in accordance with the exercise level, timeline etc. Capture all Lessons Learned (LL).

3. Play-test the exercise processes. This is the principal testing of the procedures that will make or break the exercise. Rehearse the staff in their game roles, preferably in a mini game. Capture all LL.

4. Prepare the final rules and exercise instructions, incorporating any LL from steps 2 and 3 of the development stage.

5. Create an audit trail by documenting all decisions taken and the reasons for them.

Scenario development was enabled using a process described in detail here. A photo of this being developed is shown below:

Fictionalised setting and scenario development process

We used the NATO guidance on scenario content as a baseline to ensure we had covered everything. For reference, the six NATO scenario modules are:

1. Geo-strategic situation.

2. Theatre of operations info.

3. Strategic Initiation documents, including a ‘Road to Crisis’.

4. Crisis Response Planning information.

5. Force Activation and Deployment orders and information.

6. Execution and Startex documents and MEL/MIL.

All material was uploaded to an NSC-hosted Collaborative Working Environment (CWE) to enable joint working between us (UK) and Serco (Qatar).

Note step 10 on the white board photo: ‘identify real-world parallels as a start point’. Although fictionalised to avoid sensitivities, the closer the setting and scenario can comfortably be made to the real world the better. This helps TA understanding and assimilation, makes everything more believable and eases production of Excon injects. An example is below: oil was the underlying causus belli and so real-world fields were exclusively used. Country and tribe names were changed, but not town or provinces; to do so would require major geo-data manipulation.

The SIMEx would ultimately be delivered using constructive and virtual computer simulations over a distributed network, with media broadcasts etc. However, manual prototyping was used extensively in developing the scenario (particularly to determine the balance of forces and storyboarding). A traditional birdtable featured throughout. Manual prototyping photos are shown below.

Manual prototyping and storyboarding in progress. Counters show factors for force ratio calculations and computer simulation-generated CE reductions

The ‘End of Thrumrait battle’ photograph shows counters annotated with combat factors top left and Combat Effectiveness (CE) top right. The combat factors were used to conduct OA-style force ratio calculation to give an initial balance of forces overview. This was then cycled through the Joint Operations Command and Staff Training System (JOCASTS) computer simulation to provide an indication of likely combat outcomes. The CE numbers top right show the JOCASTS outcomes after 12 hours of combat.

It is much faster to conduct initial development using physical prototyping rather than building and re-building endless computer ORBATs and data bases. Similarly, storyboarding is best done using a traditional birdtable and whiteboards.

None of this implies that the exercise narrative is pre-determined. The Training Audience (TA) must see their decisions being enacted and face the consequences of these. Hence the scenario development must deliver a situation in which TA decisions and plans can be executed within certain parameters; a ‘possibility space’ within which the TA are free to make their own decisions. If the TA think they are bystanders watching a pre-determined situation unfolding then they will not engage with the exercise and the massive benefits of active learning will not be realised.

Play-testing is critical, and culminated in a Test Exercise (Testex). The aim of play-testing is to stress everything to destruction! Try to break things, identify weaknesses, and then put everything back together again. The ‘so what’ is that, in order to test them, all aspects of the exercise should be as complete as possible prior to play-testing. Furthermore, the Testex must take place in situ in the actual exercise location; otherwise it s a planning meeting, not a Testex. We conducted a two-week Testex in Qatar, testing the setting and scenario and all aspects of the technology, including information flows such as e-mail and Requests for Information(RFIs). One week can suffice, but never less for a major staff college-style wargame.

Angus Welch, NSC Project Manager, usefully pointing out the IT equipment!

One aspect often overlooked during Testex is TA HQ and Exercise Control (Excon) battle rhythms. During Testex these should be run in parallel over the busiest 24-hour exercise period to ensure they dovetail. You do not have to run through every board and meeting in detail, but key events should be talked through to confirm timings, attendees, terms of reference, agendas, outputs and so forth. The TA battle rhythm takes priority; Excon must fit around this.

Expect to find faults during Testex; that is its purpose. However, while refinements will be made to all aspects of the final wargame, ‘show-stoppers’ will only arise if the previous design and development steps have not be conducted properly.

Execution

Where the rubber hits the road! Execution steps are:

1. Conduct simulation and systems set-up.

2. Conduct user training as required.

3. Conduct pre-exercise and STARTEX briefs for Excon staff and TA.

4. Conduct the exercise.

5. Conduct the After Action Review (AAR).

6. Collect and collate LL throughout for the validation and refinement phases.

Startex briefs play a critical role in ensuring all participants have sufficient situational awareness to launch the exercise. Exercise paperwork should be issued in sufficient time to allow the TA to read in. Ours included an aide-memoire with a Glossary of Terms and map that had been used to hold a quiz night with the students by way of scenario assimilation a week before Startex.

An often-forgotten element of Startex briefs is the ‘invitation to play’, which encourages the TA to suspend disbelief and step inside the ‘magic circle’ of the exercise setting. Think of the invitation to play as the curtain going up at the theatre. Crown Media produced both a 60-second high-impact montage of video clips that we showed in conjunction with dates and (fictionalised) place names, highlighting the growing tensions in the Area of Operations (AO). The Startex brief followed, and concluded with a detailed 15-minute news round-up.

.

Excon was organised conventionally, as shown below. More details can be found here. The Ex Director was the British Army Loan Service (LS) Director of Studies, who also played the Combined Joint Task Force Commander and was able to steer the TA if required. The Game Controller is the ‘conductor of the orchestra’ and was the Serco DS Writing Team Leader (WTL). The remaining Serco DS acted in their normal role, tutoring the TA. The key After Action Review function was organised by the second British Army LS officer. Chief Excon and all other Excon staff and Subject Matter Experts (SMEs) were provided by NSC as a ‘Managed Service’, along with the simulations, e-mail and other IT elements.

Dovetailing the Excon and TA battle rhythms was crucial. Excon coord meetings ensure the coherence and credibility of all products and injects presented to the TA, irrespective of the means or interface. Any inconsistencies or contradictions detract from the ‘reality’ of the situation and threaten the TA ‘suspension of disbelief’. This matters, and should be avoided if at all possible. We held two primary Excon Coord meetings each day, at 0700 and 1600 with a specific media/influence meeting to go into more detail in those areas. The aim of the 0700 Excon Direction and Guidance (D&G) Meeting is to allow the Ex Director, usually via the Game Controller, to provide Excon and support personnel with D&G for today’s and subsequent SIMEx progression and to confirm the detail of all scenario play, injects and media. The 0700 agenda was:

.

The aim of the 1600 Excon Adjudication Meeting is to review and adjudicate the output of the JOCASTS cycle prior to the Common Operating Picture (COP) being released to the players the following morning.

We used a simple whiteboard approach to manage MEL/MIL, supplemented by a spreadsheet on which all the events and injects were recorded in detail. This is a good example of combining a manual approach with IT: the whiteboard was used to brief at meetings and allowed everyone to quickly see what was coming up, while the spreadsheet contained event and inject detail. Having all MEL/MIL for the entire exercise available at a glance allowed people to see where we were in the storyboard and where each event and inject fitted into the whole.

The same complementary approach between manual and computer systems was applied. The photo below shows some of those used, which are briefly explained underneath:

So what sort of products did Excon produce? As well as standard RFI answers, Reports and Returns (R2) etc, we tried to stimulate the TA in as many ways as possible, using multi-sensory media. Hence the products that helped build the ‘magic circle’ and keep the TA within it included:

A Common Operations Picture (COP), adjudicated the day before and released every morning in time to be incorporated into the AM Update brief. This was distributed using iNet, NSC’s C2 look-alike system (see photo below). In an educational context (most Staff College wargames), a once- or twice-daily COP update is sufficient, especially with a TA working at the operational level. Using a real-time COP results in a ‘Nintendo effect’ whereby the TA become fixated with the unfolding picture at the tactical level, and do not maintain the correct planning horizon. The TA can interrogate COP (iNet) APP-6 icons for more detail, including textual information giving, for example, numbers of IDPs at a camp.

The iNet COP was sTimulated by JOCASTS, the computer simulation. JOCASTS outcomes were adjudicated by Excon and, where necessary, amendments made to ensure the resulting COP satisfied the TOs and the Game Controller’s D&G. As it transpired, no changes to the JOCASTS results were necessary because the balance of forces had been carefully considered and possible TA decisions anticipated.

TV media, planned 48 hours ahead and produced the day before for the AM Update plus various ad hoc injects.

Radio broadcasts, which could be produced quickly, ‘pushed’ centrally into TA HQ cells and reinforced by Open Source Intelligence (OSINT) Reports.

Virtual Battle Space (VBS) 3 virtual clips, primarily showing military products such as recce footage and UAS down-link. Some VBS 3 product was dropped into a YouTube ‘wrap-around’ as Red (enemy) messaging; some stills from this are below.

Role-play, conducted with KCL academics, support staff and anyone else we could drag in! This added yet another facet to the wargame and exercised the TA is other vital aspects of running a CJTFHQ. Initially scripted, people soon got into role and the Combined, Joint, Inter-governmental, Inter-agency and Multinational (CJIIM) meetings during the stabilisation part of the exercise developed a life of their own. The Karak Chief of Police played a central role, appearing on radio, TV and then in person – until he was brutally murdered, a fact reported in gory detail on YouTube.

SME feedback. We had a full complement of SMEs, for each environment and exercise theme (e.g. stabilisation, staff processes etc). Beyond tutoring the TA, these SMEs played a vital role in prompting the TA ‘as’ the Stabilisation Advisor, or whatever.

Media interviews. Another really beneficial aspect of active learning experiential wargaming is the chance to appear in front of the camera.

And that’s where the story ends, for the time being. We have just finished the SIMEx and validation has yet to take place. The Validation and Refinement steps are outlined below.

Validation

1. Analyse all LL and feedback for internal and external validation.

2. Produce the Post Exercise Report (PXR).

Refinement

1. Incorporate feedback from LL analysis and the PXR into subsequent exercise planning, preparation and development phases, as applicable.

2. Create an audit trail by documenting decisions taken and the reasons why.

Summary

A wargame such as the Qatar JBJJCSC SIMEx provides the TA with a wonderful active learning opportunity.

I hear and I forget;
I see and I remember;
I do and I understand.

The wargame experience allowed the TA to ‘do’. To see how well they engaged, and how much they gained, was a joy.

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.