The fundamental assumption challenged is that the M&S industry is doing a good job. We are not! This PowerPoint presentation illustrates key areas where we are failing those we purport to support (Download here)

Course of Action (COA) Wargaming is an incredibly powerful technique in any commander’s military decision making process tool bag. A well run COA Wargame will identify risks in a forming plan better than any other doctrinal method. They can then be mitigated, greatly increasing the chances of success.

LBS has provided advice to, and observed on, countless COA Wargames. Common mistakes made by practitioners rarely change from year to year or event to event, irrespective of the level of warfare or the operational context. The Do’s and Don’ts of Course of Action Wargaming explains those errors and tells you how to avoid them. Following the advice in the article will ensure that your COA Wargames are effective and efficient, delivering maximum benefit for minimum effort. (Download here)

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.

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.’

A simple list of factors to be considered as part of a training wargame design (Download here). This does not constitute the outcome of a full design phase; it is just a list of example questions.