Research Assignment

1

Wargaming In Support Of Program Management of Systems Engineering (Originally published as Chapter 17, Wargaming Simulations, “Modeling and Simulation in the Systems Engineering Life Cycle: Core Concepts and Accompanying Lectures”, 2015, edit. Margaret L. Loper)

Joseph Saur1

Introduction Simulations, models, Design of Experiments, and wargames are all decision-making aids: tools that help one to explore a problem space, to analyze potential alternative solutions (Air Force 2008), to postulate and assess the impact of possible courses of action (COA), and to validate theories related to the problem at hand. While all four are related, they are not identical, and we’ll start by looking at each individually in a military context before concentrating on the use of wargames for Systems Engineering applications.

Simulations

Warfare simulations are used to answer questions of the form, “What will be the impact of X on the outcome of a potential battle?” “X”, in this case, can be any one of the following:

• A new technology: night vision goggles, thermal imaging, GPS navigation and targeting, stealth technology, etc. By adding one of these to the forces of one side or the other, how does one change the outcome of the fight?

• A different mix of forces: more infantry and less cavalry; more special operations (SpecOps) forces; three rather than four Brigade Combat Teams (BCT), etc. Again, what is the impact of the proposed change?

• Unbalanced odds: what was the likelihood of NATO success vs. the Warsaw Pact in 1957? 1977? Could they win?

A classic military simulation used to answer these, and similar questions, was devised by Dr. George Gamow when he worked at the Los Alamos Scientific Laboratory after World War II. Labeled Tin Soldier (Hausrath 1971), the simulation is based on a 10x10 hex field, which can be completely open, or can include terrain effects in specific hexes, as shown in Figure 17.1. Two opposing forces are introduced (for now, we will use the standard convention of Blue and Red to denote the sides), and their movement is random. When units of the two opposing sides come into contact, a coin is flipped and one side or the other loses.

Joseph M. Saur, CMSP Georgia Tech Research Institute, Quantico, VA email: [email protected]

2

Fig. 17.1 Tin Soldier Game Board The simulation was originally automated using Fortran, I have used a Pascal version for many years to illustrate various points. For example, one can create armies with different troop types:

• Infantry units can move one hex per move, and fire only into an adjacent hex. • Cavalry units can move two hexes per move, and fire only into an adjacent hex. • Artillery units can move one hex per move, but can shoot at enemy units up to two hexes

away.

What results, then, can we obtain? First, a base case: each side has ten units, all are infantry, and there are no terrain effects. We run the simulation 1000 times, and look at the results (Figure 2).

Figure 2: Results of 1000 Runs; Even Odds A game ends when one side or the other runs out of units; at that point, we capture the number of units remaining on the winning side. If we plot the results to show the frequency with which a side wins with 1, 2, up to 10 units, we see an approximation of a Bell curve: in this case, Red has won 504 games; Blue has triumphed in 495 games, and one game was called for an excessive number of moves (i.e., a tie). This is our base case. Modifying the input values, we can show that altering the odds to 2:1 (10 Blue units, but only 5 Red units), Blue now wins 904 games; Red takes 93, and there are three ties (Figure 3). We still see a range of possible outcomes, and can identify those games where Red rolled well, while Blue did not. This ability to see the range of all possible outcomes is important to the military decision-maker, as it gives him an indication of both the best- and worst-possible results.

0

20

40

60

80

100

120

Tin Soldier Results

Red

Blue

3

Figure 3: Results of 1000 Runs; 2:1 Odds Another excursion: at the Battle of Karbala Gap (Figure 4), one American armored brigade was attacked by two Iraqi brigades; as the Americans were outnumbered roughly 2:1, the results should have been something like what we saw in the 2:1 case, but with the Americans (typically Blue) on the losing side. In this case, however, the Americans, using thermal imagers, were able to detect and target the Iraqi units without being seen, and the Iraqis, essentially blind at night, were unable to act effectively. This technology advantage is shown in the run results (904 Blue wins; 96 Red), which are in line with the prediction: every Iraqi tank was destroyed or disabled; the Americans suffered only minimal damage.

Figure 4: Results of 1000 Runs; 2:1 Odds; Blue Range Advantage This kind of predictive analysis is often used by the military when prioritizing their research investments, both long- and short-term. Of the X number of research projects that have been proposed, which one(s) are likely to have the largest long-term battlefield impact? To sum up, then, simulations aid the military by permitting the decision-maker to as “what-if” questions, and compare the results to a base case.

Attrition Models

Attrition models, unlike warfare simulations, are deterministic mathematical models that attempt to answer questions in the form of, “Which side is likely to win this engagement?” In the late 1800’s, a number of researchers began to look at warfare from a scientific and mathematical point of view. At least four that I am aware of (Hembold & Rehm 1915) wrote to describe very similar models; only one of them caught on. A LT Chase (U.S. Navy) was first in 1902; Bradley Fiske (U.S. Naval War College) in 1905; M. Osipov (Voenniy Sbornik) in 1915. Chase’s was classified; Fiske was largely unknown outside the War College; Osipov wrote in Russian; it was Fred Lanchester’s Dawn of the Fourth Arm in 1916 that became well known. Basically, attrition models attempt to model the results of combat, and more to the point, the skewed losses suffered by one side when the odds are uneven. Consider the case:

X X X X X X X X X X X X

0

20

40

60

80

100

120

140

Tin Soldier Results - 2:1 Odds

0 20 40 60 80

100 120 140 160

Tin Soldier Results: Blue Shoots Twice As Far

4

O O O O O O O O O

Here we have 12 X’s opposing 9 O’s; the difference between the two sides is three. At first glance, one might assume that each side would lose nine units, and Blue would be left with three units at the end.2 For better or for worse, this is not the case. Assume all have guns; all shoot simultaneously for each turn (also called a time step), and all have a 1 in 3 chance of hitting. At the end of turn one, Blue has scored 4 hits; Red, 3; and the situation looks like this:

X X _ X X _ X X _ X X X O _ O _ O _ O _ O

Blue is now down to nine units, Red has five, and the difference is now four. After turn two, we get to:

X X _ X X _ x X _ X X _ _ _ O _ _ _ O _ _

Blue now has 7+ (we’ve given Red partial credit for the two leftover shots); Red has two; and the difference is now five. It’s easy to see that Red will not survive the next round, that Blue may suffer another partial hit, but will end up with a minimum of six units. Contrast this with the original assumption that each side would lose nine, and Blue would end up with three. Fred Lanchester (Lanchester 1996) described this phenomenon in a pair of equations3: a Linear Law, and a Square Law. The Linear Law can be expressed as follows: the number of Blue units at the end of a timestep or turn is equal to the number of Blue units at the beginning of the turn, minus the number of Red units at the beginning of the timestep times the effectiveness of Red against Blue. The formula for Red is similar:

BT+1 = BT – (RT * KRB) RT+1 = RT – (BT * KBR)

In these examples: BT+1 is defined as the number of Blue units at the end of a timestep BT is the number of Blue units at the beginning of a timestep RT is the number of Red units at the beginning of a timestep KRB is the effectiveness of Red against Blue

Similarly,

RT+1 is defined as the number of Red units at the end of a timestep RT is the number of Red units at the beginning of a timestep BT is the number of Blue units at the beginning of a timestep KBR is the effectiveness of Blue against Red

This version of Lanchester’s Law describes the attrition expected in cases where, for example, everyone has swords and shields. If Blue has 100 troops, and Red 80, then twenty of Blue’s men are essentially idle until one of their compatriots is killed and they can join in the fray. If, however, both sides are equipped with rifles, the extra Blue units can also fire at Red; in this case, the Square version of the law is used:

2 This is, in fact, the assumption made by H.G. Wells in his book “Little Wars”, and his mechanistic attrition results tended to be very “bloody” as a result. 3 LT Chase and Bradley Fiske described formulas that produced results akin to those resulting from the application of the Linear Law; Osipov’s results were similar to the Square Law.

5

(BT+1)2 = (BT)2 – ((RT)2 * KRB) (RT+1)2 = (RT)2 – ((BT)2 * KBR)

In this If we try our same 12 vs. 9 experiment, the results can be seen to the right: Blue ends up with 7.95 units; Red has zero, and this took 17 timesteps (Figure 5). Unfortunately, it turns out that K, the effectiveness of one side or the other, is not a constant, and is affected by a variety of factors: heat, fatigue, hunger and thirst, morale, weather, the presence of air support, etc., and over the years, researchers have attempted to identify and quantify many of these factors. While many of these efforts have been classified, a public version of at least one, the Dupuy Institute’s Operational Judgment Model, has been described, and it involves the use of some 73 factors. (Dupuy 1979) version, each of the “number of units” variables are squared.

Figure 5: Lanchester Example; 12:9 Odds

In fact, at this point, we should point out that all of the numbers we have used so far may be difficult (if not impossible) to quantify with any precision. For any battle earlier than the American Civil War, muster reports are generally non-existent, and estimates of troop strength can be exaggerated for either political purposes, or to enhance the story. For more recent conflicts, it has proven impossible, when analyzing the results of multiple battles, to determine a consistent level of effectiveness (used in both the Tin Soldier simulation when adjudicating results of a meeting between two units of different sides, and in Lanchester as K), even when looking at the same forces in a multi-day battle. (Bracken 1995) Finally, there are historical battles (Rorke’s Drift, Watling Street, Leyte Gulf) where the side that is outnumbered 10:1 survives, or even wins the battle! Thus, while an attrition model can give some indication of what might happen, there is certainly no guarantee. Assuming, however, that one uses average numbers for the various variables in an attrition model, the results should be somewhere in the middle of the “hump” of the simulation of the same battle. Bottom line: the results of an attrition model should not be taken as gospel!

Design of Experiments (DOE)

While a DOE run appears similar to many simulations, the basic goal is different. In a simulation, we know the variables, we know the approximate values, and we use computerized “dice rolls” to identify the range of all possible outcomes (assuming our variable values are valid). For DOE, on the

effect (b) number (x) number (y ) effect (a) 0.3 12.00 9.00 0.3

11.48 8.30 11.00 7.62 10.57 6.97 10.17 6.35 9.80 5.75 9.48 5.18 9.18 4.62 8.92 4.07 8.69 3.54 8.50 3.03 8.33 2.52 8.19 2.03 8.09 1.54 8.01 1.06 7.96 0.58 7.94 0.10 7.95 0.00

6

other hand, while we may know which variables are involved, and what the range of possible values for each are appropriate, we don’t know which have the most impact on the outcome of the simulation, and so our question is in the form of, “Given simulation ABC, with variables U, V, W, X, Y and Z, which variable, or which set of variables, has the biggest impact on the outcome of the simulation, and should have the most impact on, and consideration in, system design?”. In order to determine this, we wrap the simulation within a larger program, and then randomly change the values assigned to the various variables, and run large numbers (10,000+) of run, tracking the values of all variables for each run. At the end, we can determine whether it is weapons range, or weather, or whatever, that has the greatest impact on the outcome. If that variable can be manipulated and/or used by the military commander to gain an edge over his or her opponent, he or she will certainly attempt to do so.

The Use of Wargames for Systems Engineering

Finally wargames. As stated at the beginning, wargames are related to warfare simulations, attrition models, and occasionally, DOE runs, but only indirectly in that each of these three can be used to support a wargame, but none is actually necessary. Wargames are interactions between two or more thinking, reactive, human opponents, and are used to explore the possible reactions of an opposing force in a situation where the military commander is not sure he or she has considered all sides of the situation.4 In Systems Engineering, wargaming can be used at a number of decision points in the overall process. For example, some potential usages:

• During Requirements Definition to ensure that all aspects of the project are understood by all participants (including both customers, sponsors, and members of the development team(s)).

• During the Analysis of Alternatives phase to ensure that all possible approaches are considered. While the possible introduction of a new system may be the focus of the project, one must not ignore changes to any or all of the other aspects of DOTMLPF: doctrine, operations, training, leadership, personnel, and facilities.

• During High-Level Design to ensure that all participants understand implications of design decisions, that potential risks are identified and addressed, and that the project schedule is both complete and correct.

• During Test Design to ensure that all potential users, use-cases, and use conditions are considered, and that sufficient resources (including time, people and systems) are available.

For this section on the possible use of wargames, then, we will cover:

• Some quick definitions: what do we mean by wargames and/or wargaming? • The application of wargaming within the systems engineering lifecycle: how would I use one?

What should I expect to learn from wargames? And finally, • The construction (pieces & parts) of a wargame: what do I need to run one?

Some definitions.

Game: A physical or mental competition in which participants, called players, seek to achieve some objective within a given set of rules. (DMSO 1998)

A game is different. It may be based on a model of play, and simulate the behavior of the model as the game progresses, but at its core, a game is a contest between players. Even a video game meets this definition, although in that case, one of the players (i.e., the designer) happens not to be present, and his reactions are (often poorly) reflected in the behavior of one or more avatars or objects on the screen. Games have certain characteristics:

4 Schelling’s Impossibility Theorem: “One thing a person cannot do, no matter how rigorous his analysis or heroic his imagination, is to draw up a list of things that would not occur to him.”

7

• Conflict: each player has a goal; these are not always the same, nor are they necessarily mirror images. There are always obstacles to make the game “challenging”. Games that are easy quickly bore us. (Thiagarajan 2007)

• Control: there are rules that must be followed. Even in something like “Tag”, or “Hide and Seek”, there a rules (albeit unwritten), which, if ignored, will bring the accusation, “You cheated!”

• Closure: the game will end; how it ends is defined in the rules. Again, because in some games the “winning conditions” are not mirror images, defining what it means to win can be important.

• Contrivance: games have built-in inefficiencies that help to make it a challenge, but which also help us to keep from getting too emotionally wrapped up in the game: (“It’s only a game”) Or as one of my Dutch colleagues puts it, “Playing a game is a voluntary attempt to overcome involuntary obstacles.” (Eliens 2008)

• Half-belief: At the same time, many games exist in an imaginary world in which we are “saving mankind”! (DeKovan 2007) Video games, for example, are good at this, as are many other role-playing games. We need to take them seriously, at least for the moment, to play well.

• Nature: Some are “true games”, based on physical configurations, statistics (chess, etc.); others are “real games”, where a knowledge of the Real World is important (“Axis & Allies”, etc.) (Schmidt 2008)

Finally, from the DoD Dictionary of Military Terms:

Wargame: A simulation, by whatever means, of a military operation involving two or more opposing forces using rules, data, and procedures designed to depict an actual or assumed real life situation.

This would imply that wargames are restricted to the simulation of military conflict; in reality, the wargame model (i.e., a conflict between two or more players) can be applied to any number of situations where there is no single, objective answer to the question, and where multiple approaches to the problem are possible. Some examples:

• Politics / Military (PolMil): Starting in 1987, the Pentagon ran a series of wargames that attempted to look beyond the bipolar US/USSR conflict to a more multipolar world where Western Europe, Japan and China would play a larger economic role. Because of the drag on its economy, in the game, Russia began to invest less in armament, and more in education and technology. This led the Europeans, Japanese, and even Chinese to do the same. The results of the game predicted:

– The opening of Eastern Europe to the West. This occurred in the 1990’s. – East and West Germany would unite. Happened in October 1990. – The Warsaw Pact would collapse. June 1991. – The USSR would fail within two years, and implode politically. August – December 1991.

(Herman et al. 2009)

• Grand Strategy: When President Reagan announced the Strategic Defense Initiative in 1983, the intent was to provide an umbrella of protection for the Continental United States (CONUS), an umbrella against Soviet ballistic missiles. No one understood the potential impact of this effort. In a Pentagon wargame held in 1987, the questions were asked, “How much defense is necessary to make a difference in the enemy’s offensive planning? How would the enemy respond?” (Ibid)

The teams started by assuming that the SDI could take out 15% of the Soviet missiles. The Red team responded that, in order to meet their strategic goals in launching a nuclear strike, they would need to increase their missile inventory by a minimum of roughly 60% (four times whatever the effectiveness of SDI). When we started to actually work on building SDI, their economy could not respond, and this, in large part, triggered the collapse outlined above.

8

• Business: Business games, and specifically business games based on the wargaming model, were adapted by the American Management Association starting in 1959. These were intended to be used for a variety of purposes:

– Understanding management problems – Familiarizing managers in the use of specific business systems – Education in management principles and techniques (Hausrath 1971)

As with more conventional wargames, business games can be computer-assisted or not, can be one-person, one sitting games, or can be multi-team endeavors over an extended period of time.

• Engineering: One program with which I’ve been associated has developed a fairly formal and complex methodology for looking at emerging battlefield issues. When a new potential technology shortfall is identified, the process works like this:

– Team A analyzes the issue, and develops a potential response. This solution can be technical, procedural, or a combination of the two.

– The proposed solution set is then sent to Team B, who represents, in this case, our good friend, Murphy. The team examines the behavior of the proposed solution, and the predicted and projected impact of the proposed solution on the problem. They then attempt to identify holes in the solution; conditions that could, in some way, overcome the impact of Team A’s solution.

– At this point, all three documents (description of the problem, the proposed solution, and the proposed arguments counter to the solution) are sent to Team C, which looks at all three, and attempts to judge:

o Whether Team A’s solution would work o Whether Team B’s conditions would make the solution ineffective o Finally, how Team A’s solution might be modified to make Team B’s job more

difficult.

Certainly, this could go round and round, but keep in mind that in many instances, the cost of actually building a technological response is likely to be wasted if the problem is not clearly understood. And here is one more definitions, but if you look carefully, one could substitute “politics”, or “business”, or “engineering solution” where it reads “military”, and still retain the same sense of a conflict between two or more players seeking dominance in some sphere of endeavor:

Wargame: An artificial vehicle made up of a field of variables that replicates conflict and allows human intellect to consider a real problem. (Lademan 2013)

Constructing A Wargame To Support Analysis This section focuses on the construction of a systems engineering wargame: the various parts, their interaction, and the types of research and analysis needed to create this wargame. An engineering wargame can be used to explore the various options available, to recognize and deal with political, economic and structural pressures on the project, perhaps to attempt to recreate past failures so as to understand the pressures, options, and decisions made by past engineers, to analyze options available but not followed, and to pit one’s own ability given a known set of restrictions, conditions and opportunities. For this discussion, I will occasionally use terminology from the U.S. Department of Defense (DoD) Joint Capabilities Integration and Development System (JCIDS), which is the formal process governing the acquisition of large material systems used by DoD: tanks, ships, aircraft, missiles, Command and Control (C2) systems, etc. As Systems Engineering is not, however, the exclusive purview of DoD, I will not limit myself to this framework.

9

In creating an engineering wargame, I plan to use the imagery of a video wargame (with which I assume you all have some familiarity) to illustrate the various points (Figure 6). The issue here is that one must recognize the relationship between the different parts; we will explore each in turn:

• The map • The player interface • The various orders of battle • Turn mechanics and movement models • The combat model(s) • The backstory

Figure 6: Wargame Construction

The Map, aka “Project Scope”

For military wargames, regardless of the size of the conflict (Little Round Top, or Gettysburg, or the entire Civil War), the map that fits in our game box is still 32”x40”, and so we need to scope and compress our game to fit. In engineering, while we’d all like to “solve world hunger”, the problem the customer wants solved may be slightly smaller, and his or her budget may not be unlimited. Our first task, then, is to scope the problem: how much can we reasonably accomplish given the budget available? Some obvious questions:

• How “high-level” are the requirements? Are they sufficiently developed that members of the project management team (including the sponsor, the potential users, and representatives of the different technical development teams) can understand the implications for size, complexity, and risk involved in the project?

• Are the requirements consistent internally, or do some contradict others? • For military projects, has a System Threat Assessment (STA), predicting the threat

environment in which the final system is intended to operate, been prepared? Is a draft Concept of Operations (CONOPS) available? (DAG 2014)

Why, you might ask, is this important? I would invite you to take a look at any one of the following large systems engineering (or systems re-engineering) projects undertaken by the Federal government within the last twenty years:

• Modernization for the FAA’s national air traffic control system • Modernization of the FBI case file system • Modernization of the IRS tax return management system • Introduction of the Affordable Health Care enrollment system

Player Interface

Player Interface

OOB Blue

Player Interfaces

OOB Red OOB

Green

Admin Interface

Combat Model

o o o o o

o o o o o

x x x x x

The Map and the Movement Model

Turn Mechanics Model • IGO/UGO • Simultaneous • Other

The Story

10

Each has been very large; each has been characterized (at least in their briefings) by promises of adherence to some version of a systematic approach, whether that be the use of the Project Management Body of Knowledge, the Software Engineering Institute’s Capability Maturity Model, Six Sigma, or the INCOSE Systems Engineering Handbook, and each has been a dramatically public failure. In each case, I would suggest that a degree of overreach, and of hubris, had something to do with that failure. And I would further suggest that the use of a method of wargame analysis at the beginning of the project might have helped to keep the project on track. And when you assume, at the beginning of the project, that you “fully understand” what’s being asked, you might want to recall Schelling’s Impossibility Theorem: “One thing a person cannot do, no matter how rigorous his analysis or heroic his imagination, is to draw up a list of things that would not occur to him.” For this reason, it has been my experience that having multiple engineers, individually and separately, define their understanding of the scope of the project, and of the tasks to be accomplished, and then comparing all of the separate definitions will help to identify components that a single analyst might have overlooked.

The Player or User Interface, aka “Project Reporting”

Both the customer (the user organization), and the provider (project organization) will be interested in your progress. Both will have had past experience (some good, some bad) with similar projects (or at least with projects they perceive as being similar), and both will want some assurance that your effort is on the right track. How will you keep their anxiety down without overburdening your team with excessive reporting requirements? Will you report weekly? Monthly? Electronically, or in person? How much time will be data reporting, analysis, and reporting involve, and has this been included in the schedule? Especially for government and/or defense projects, some of this will already be specified in the contract, but the implications of the reporting cycle on the project schedule must be considered.

The Orders of Battle, aka “Project Players”

Who are the entities who need to be represented in our engineering wargame? For government and/or defense projects, this group might be termed an Integrated Project Team (IPT) or High-Level Project Team (HPT), but the idea is the same: who are the people who best understand the nuts and bolts of the various parts of the effort needed to build our system. Let’s look at some possibilities:

• The interface developers – how will the user “see” the system? • The database team – what has to be stored? How much? Where? • The network engineers – where will the various parts reside? How will they connect? • The security engineers – will this be a closed or open system? How much risk is OK? • The system architects – software only? Hardware and software? • The user community – who are they? Where are they? How many types of user? • The sponsor(s) – how big is the budget? What is inside/outside of scope? • Your chain of command – how much reporting? • Murphy – he never sleeps! • and one could go on…

Each will have a distinct point of view regarding the possible direction of the project, what should be included (and what should be deliberately excluded!), what is within the realm of the possible given the resources (both number of hours, and the skill level of the team members) available. These need to be hashed out BEFORE the project starts. Individuals from each of the different groups would be best, but this is not always possible or politically acceptable, but each should be represented by someone with sufficient understanding of that groups concerns and/or point of view is critical to overall success. As for Murphy, one would be well advised to assign this to the most experienced developer on the team, as discovering potential issues at this stage is much cheaper than finding them later…

11

Turn Mechanics and Movement Models, aka “The Rules Of The Game”

This step concerns the actual gameplay mechanics, and I would suggest something along the following lines: plan and then propose. Each player representative considers the current state of the project, and outlines his/her team’s approach, concerns, issues, and proposed solutions. After all points of view have been presented, a facilitated discussion is used to identify the composite solution set adopted, and to describe the anticipated state of the project at the end of some increment of time. This is iterated enough times to get to the project end state. Within each turn, any development process (Waterfall, SCRUM, Agile, JCIDS) can be used because, in the last analysis, all are very similar: we start in a position of knowing very little about the final system, and through a series of iterative processes, expand our understanding of the problem, and our potential solution until, at the end, we deliver a(n almost) finished product. What is learned in each turn, you might ask. Some of the issues that could be uncovered:

• Misunderstanding of, or misidentification of, the critical path. In estimating the work that needs to be accomplished without discussion between the groups, each may make assumptions about what the other(s) may do that might not be apparent, and may not be accurate. The user community, for example, may not be prepared to provide individuals to assist the interface group to design the user screens until well after the latter group needs to have these completed.

• Misunderstanding of, or misidentification of, the processes to be automated. Many times, the words used by the customer, and the words used by the development team, may sound similar, but each side may have a very different understanding of the implications or definitions of those words. Again, better to find out early. “I know you built what I said I needed, but that’s not what I want…”

• Conflicts within the sponsor’s description of the issue. In some cases, two or more groups within the sponsoring organization have differing opinions as to what is needed to solve the problem, and this will be manifested in conflicting requirements within the Request for Proposal (RFP) or Statement of Work (SOW). Better to sort these out (with an understanding of the potential impacts of opting for one or the other) before starting to design a solution. And if they are not willing to make a choice, the issue needs to be promoted further up their chain of command for a decision.

• Underestimation of the degree of difficulty. This is where the player representing Murphy is important. He/she needs to be able to identify areas where complexity, speed, security, and or the sheer size of the effort may be a risk issue, and bring these to light early in the game. Waiting until the end to discover that one cannot possibly estimate the risk of a transaction in time to make a timely stock purchase is not a good strategy. (Ask Wall Street c.2008 about that one!)

What? No dice rolls? It’s a game, isn’t it? Yes, it is a game, but no, no dice rolls. And why not? The issue is quantification. The creation of a combat results table, against which the dice rolls are compared, is based on the analysis of past instances of the issue at hand: for military wargames, past fights between units of a given size. When examining a project that will take place in the future, any effort to quantify, in integer terms, the impact of a given effect, may give greater precision, but lesser accuracy. In most cases, “large”, “small”, or “minimal” are more easily agreed to than “one week”, or “two FTEs”.

The Combat Model(s), aka “Who Flips The Coin?”

Yes, “the customer is always right”, but that doesn’t mean the development team shouldn’t be heard. And, at some point, one or the other side might decide to “pull the plug”. Better to do that early. If your team is convinced that there is no way the final product desired by the customer can be built within the time and budget constraints imposed, one must weigh the cost of trying (potential loss of key developers, impact to one’s corporate reputation) against the possible gain. Again, in a

12

government and/or defense project, various decision points (Milestones) and reviews are mandated by the formal JCIDS process, but this does not limit the project to only those opportunities.

The Backstory, aka “Why Should I Want To Play?”

In video games, this is all about establishing an emotional involvement in the outcome of the game, in “setting the hook”, as it were. For an engineering game, where the outcome will help shape your life (and the quality and quantity of non-work time you will enjoy over the next how many months or years!), this is somewhat easier to create. The issue, however, might be getting the sponsor to cooperate and participate: “I’ve already told you what I want; why should we waste time playing games? Get started!” In this case, an internal game, without customer participation may be answer, if somewhat less effective. The results, however, have potential value in that they may uncover hidden issues, and unidentified risks.

To Sum Up As we can see, then, putting together an engineering wargame is really a non-trivial but important task (Szirbik 2013), and the larger the project, the more impact the wargame can have. We have historical examples (most painfully bad) that would indicate that the earlier one identifies (and decides to correct!) an issue in an engineering project, the cheaper it is to fix it, and engineering wargames are one way to help to uncover problems early on. In creating an engineering wargame, the essential parts are as follows:

• A proposed statement of the overall scope of the project: what is within scope, and what is outside of scope.

• A proposed project reporting schema, • A proposed list of wargame players (including Murphy!) • A set of game mechanics and decision-making procedures, • (The emotional involvement of the players, who are, in a sense, deciding their own fate, can,

in this case, be assumed…)

As a final thought: wargaming is not immune to error, or to deliberate blindness, or to hubris. The Japanese preparation for the battle of Midway is often cited as the poster child of how not to run a wargame… Following a proven method does not always lead to success, but not following some sort of systems engineering methodology to understand the real limits of the project early on will almost always lead to pain.

References • Air Force “Analysis of Alternatives (AoA) Handbook”, Office of Aerospace Studies, 2008

• “Alfred H. Hausrath, “Venture Simulation in War, Business and Politics”, McGraw-Hill, 1971

• R.L. Helmbold and A.S. Rehm: Translation of Osipov, 1915; Jerome Bracken, Moshe Kress, Richard Rosenthal, “Warfare Modeling”, Military Operations Research Society, 1995

• F. W. Lanchester, “Aircraft in Warfare: The Dawn of the Fourth Arm”, Lanchester Press, 1996

• Colonel T. N. Dupuy, “Numbers, Predictions & War: Using History to Evaluate Combat Factors and Predict the Outcome of Battles”, Bobbs-Merrill, 1979

• Jerome Bracken: Lanchester Models of the Ardennes Campaign; Jerome Bracken, Moshe Kress, Richard Rosenthal, “Warfare Modeling”, Military Operations Research Society, 1995

• Defense Modeling and Simulation Office, “DMSO Glossary of Modeling and Simulation Terms”, DoD 5000.59-M, 1998

• Conflict, Control, Closure and Contrivance: Sivasailam Thiagarajan; NASAGA 2007

• Anton Eliens, VU University Amsterdam / University of Twente, The Netherlands

13

• Bernie DeKoven; NASAGA 2007

• Otto Schmidt, Fall-In 2008

• “Wargaming for Leaders: Strategic Decision Making From The Battlefield To The Boardroom”, Mark Herman, Mark Frost, Robert Kurz, McGraw-Hill, 2009, p. 34

• ”Venture Simulation In War, Business, And Politics”, Alfred H. Hausrath, McGraw-Hill, 1971, pg. 200.

• Dr. William Lademan, Wargaming Division, Marine Corps Warfighting Lab

• “Defense Acquisition Guidebook”, https://daq.dau.mil

• Experiencing the Systems Engineering Process as a Serious Game”, Nick Szirbik, PhD, De-partment of Operations, University of Groningen, The Netherlands, http://www.youtube.com/watch?v=0C- mMIrxqyA