Help the Plan Survive Contact: Write Better Decisive Conditions

Help the Plan Survive Contact: Write Better Decisive Conditions

Ian Kippen

As operations planners, how many times do we hear our leaders quote Helmuth von Moltke, “No battle plan survives contact with the enemy” or Dwight Eisenhower’s “Plans are useless, but planning is indispensable”?  Robert Burns may have gotten there first when he wrote “The best-laid schemes o’ mice an’ men gang aft agley”.[i]  This is not to say that plans always fail, but that we rely more on the brilliance of our commanders and subsequent remedial action, rather than following the passage of the plan.  Over the last few years I have reviewed dozens of operational level[ii] plans, some the size of a telephone directory thanks to the sheer power of cut and paste, which is a problem in itself. What the bad plans, and I am afraid that there were many, had in common, was the way “Decisive Conditions”[iii] were written; they were all too often merely a catalogue of tasks.  Such a linear deterministic approach fails to recognise the dynamics of any operation as described by Clausewitz in his well quoted passage “war is more than a true chameleon”.[iv] If we have our decisive conditions wrong, we will construct the wrong effects and wrong measurements.  It doesn’t matter how good our actions may be, our plan will not survive contact with the enemy.

Stefan Lundqvist has argued that the planning methodology outlined in NATO’s Comprehensive Operations Planning Directive (COPD) is entirely based on systems theory and that such systems thinking is based on conceptually different principles than traditional military planning methods. He has called for military teachers and students to adapt accordingly so that plans can benefit from the insights that will come with a systems thinking approach.[v]  In this paper, I will propose a methodology for planners to apply systems thinking to this critical aspect of operational design, the development of Decisive Conditions.

First, Some Basics

To paraphrase NATO doctrine, we have a cascade effect of conditions: we describe the current state as the politically unacceptable condition; the end-state is the condition that is politically acceptable; objectives are themselves conditions of the end-state; to achieve an objective we need to create certain conditions that will be decisive in reaching the objective; to establish those decisive conditions, we create effects.  We define an effect as a change in the state of a system (or system element) that results from one or more actions.[vi]

Secondly, a plan is a written account of an intended future course of action aimed at achieving specific objectives within a specific timeframe. It explains in detail what needs to be done, when, how and by whom, and should include contingencies for changes in the environment. [vii]  In simple terms, a military plan deploys, employs and sustains a force.  At the heart of the plan is the Operational Design, which is “the Commander’s vision for the transformation of the unacceptable operational situation at the start … into a series of acceptable operational conditions at its end. This is done through establishing Decisive Conditions (DC) along Lines of Operation (LOO), leading to the achievement of operational objectives” as in Figure 1.[viii]  The design is also the means through which tactical commanders will understand their part in a joint operation and coherently develop their own designs.  For the strategic level, as the approving authority, the design is fundamental in understanding that the plan remains within political direction, that the demand for resources meets the minimum requirements, and that the rules of engagement (ROE) are appropriate.

Figure 1: Operational Design Basics

If we are going to write better DCs, we need to recognise some root causes of the problem, the start point of which is the identification of candidates for DCs.  This is closely followed by our failure to treat the operation as a complex, multi-sectoral system, compounded by interacting perspectives, interests and preferences.  A causal factor is certainly the cultural separation between the strategic and operational level (see my article on Centre of Gravity (COG)[ix]); the point is that operational design must be nested within the strategic framework rather than a wholly separate operational level activity.  Finally, a causal factor, or possibly a root cause, could be the tendency for planners to lock themselves away with wet towels over their heads when constructing the design; development of the design must be an inclusive activity.  I’ll start with the easy ones.

Deriving Decisive Condition Candidates

NATO’s definition for a DC is “a combination of circumstances, effects, or a specific key event, critical factor, or function that, when realised, allows commanders to gain a marked advantage over an opponent or contribute materially to achieving an operational objective”.[x]  For my money, this is not helpful; we can throw anything into the bucket and potentially end up with so many DCs that the design is overly crowded, incomprehensible and, to go to my point above, simply wrong.  NATO planning doctrine gets closer to the mark when stating DCs “are logically determined from the COG analysis process and are arranged along LOOs leading to the adversary’s COG. But a DC can be a place, a precise moment or a distinctive characteristic or quality upon which a COG depends to maintain its freedom of action and power”.[xi] The planners will conduct COG analysis on all actors to gain a full understanding of the requirements and vulnerabilities of the COG.  We must support the requirements and protect the vulnerabilities of our own forces, supported/ supporting actors (such as the host nation or the United Nations (UN) in a Peace Support Operation (PSO)) and possibly some neutral actors (such as a non-governmental organisation).  In good Clausewitzian fashion, we exploit our adversaries’ COG vulnerabilities by attacking its requirements.  In brief, a decisive condition is something that our Commander must have, and be denied to our enemy.

Nesting the Operational Design Within the Strategic Framework

In principle, basing the plan on the objectives, restraints and constraints received from the higher headquarters, the operational design will nest within the strategic framework.  In my paper on Centre of Gravity (COG), I advocated using a method for deriving COGs developed by the US academic Dale Eikmeier in which the Operational level analysis took its first step (the operational aim/ objective of the subject) from the Strategic level analysis of the subject’s strategic critical capabilities.  The idea is that the strategy synchronises the instruments of power; the military aim and objectives complement those of political, economic and civil instruments.  The Tactical level would start its analysis from the Operational level analysis of the subject’s joint critical capabilities, synchronised to achieve the operational aim.  By this means, we join the dots between the levels and nest our plans. 

Inclusive Analysis

To get full benefit from this analysis, the planning team should bring together the broadest range of expertise possible to enrich the debate.  If possible, external agencies that might be operating in the operations area should also be included with view to developing lines of engagement (LOE) and promote understanding of their objectives and activities.  An example would be a UN representative in a PSO who can speak with some authority on the aims, objectives and operations of the various UN bodies.  This inclusive team will be instrumental in the next step, which is when the DCs are fully developed.

A Systems Approach to Developing DCs

US Marine Corps doctrine: “Rather than pursuing the cumulative destruction of every component in the enemy arsenal, the goal is to attack the enemy ‘system’, to incapacitate the enemy systemically”.[xii]

Readers may be familiar with John Schmitt’s excellent paper “A Systemic Concept for Operational Design”[xiii] where he advocates a design process based on systems thinking that will “… build a systemic understanding of the situation, such that a course of action emerges intuitively”.  Systemic Operational Design (with the wonderful acronym SOD) emanated from an academic initiative that integrated systems thinking and human-centred design, with the intention of helping designers cope with complex design projects.  SOD has taken a beating in recent years and I have no intention of wrenching the nails from that particular coffin.  However, there are elements that we should take on board, not least of which is the notion that everything is a system and every system is part of a bigger system (General Systems Theory), the sum of the parts being greater than the whole. 

In Systems Engineering, the operational design would be considered as a project, with the design graphic akin to a Gant chart.  The project brings together the materials and skills necessary to create a complex object and the way it will be used, implying a combination of engineering and management skills. The approach selects an appropriate means to achieve an end, which is defined at the start and thereafter taken as given.  The plethora of project failures, especially technical computer-centric projects, led to the development of Systems Analysis by the RAND Corporation.  The approach assumes we have an objective we desire to achieve; there are alternative systems by which it can be achieved; we understand the costs or resources required by each system; we develop models showing the interdependencies of objectives, systems, resources, and the environment; we have clear criteria for choosing the preferred alternative.[xiv]  It all sounds familiar, which may explain why we see a great deal of academic writing (predominantly from the US) on a systems approach to the operational design[xv] and a simple search will uncover an abundance of papers for and against such an approach.  As I said earlier, we don’t need to go into that; the processes we have are well scripted and taught and need no further complication.  Instead, the focus is on how a systems approach will help in building elements of the design, especially DCs and effects. 

Dealing with Complex Systems

To start with, let’s take strategic uncertainty and the increasing complexity of modern military operations as given.[xvi]  The need to adopt a comprehensive approach has been well chewed over, as well as directed by our superiors, so that also goes into the mix.  During our Comprehensive Preparation of the Operational Environment (CPOE),[xvii] we discover how our problem situation comprises multiple interconnected human systems that are autonomous and therefore prone to chance as much as probability; entity behaviour is almost impossible to predict.[xviii]  Mathematically, these are complex systems and "to make sense of a complex system, humans instinctively attempt to categorize information through descriptive monikers and reductive classifications."[xix] We mistake such monikers and classifications as DCs and arrange them along lines of operation so that we can move on to the next phase of the planning process.

Systems engineering would define such an array as a hard system: achieve A, then B, make a choice at C and then either D or E etc. This assumes a relatively well-structured problem situation where there is virtual agreement on what constitutes the problem and the behaviour of the components are predictable.  Soft Systems Methodology (SSM) was very popular with the British Army in the mid-90s and early noughties, used to model its multiple interconnected systems as the organisation entered the new computer age.  Unfortunately, its use of “fluffy clouds” in diagrams became a red rag to our bullish senior officers.[xx]  SSM was developed from systems engineering approaches to be a learning system that would overcome the failures of its predecessors.  It is designed to learn about a complex problematical human situation, to find accommodations and take purposeful action in the situation that needs to be changed.  It assumes that different individuals and groups, being ultimately autonomous, will make different evaluations leading to different actions. This creates “issues” with which the manager must cope.[xxi]  Again, this should look familiar to the military planner.  So, SSM articulates complex social processes riddled with assumptions that need to be explored, challenged and tested. [xxii] As with planning in its true sense, it is intrinsically a participative process and has several features that I have found extremely useful.  Let’s first look at the methodology and then work a simple example. 

The overarching principle is inclusion, bringing together a range of subject matter experts (SME) who come well prepared to provide a comprehensive view.  We should also include our operational researchers alongside our Operations Assessment SMEs, not just because they are inherently smart, but because ultimately, they will derive the decision support metrics.  Selecting good SMEs and making them feel welcome is important for taking the first step in constructing our Operational Design.

• Develop a holistic, multi-perspective view of the environment.  The Comprehensive Approach (Joint Operating Environment (JOE) for US practitioners) demands a holistic understanding of the environment and the actors with a stake in that environment.  SSM uses a German conceptual term for a system of purposeful activity: Weltanschauung.[xxiii]  The usual translation is worldview, or point of view, which is also a common feature in design theory. It is really a holistic view that encompasses themes, values, emotions, and ethics, with the sort of nuances that give us Gerald Seymour’s "One man's terrorist is another man's revolutionary", from the book Harry’s Game.  In SSM terms, the CPOE provides the framework for comprehending complexity, when we will immerse ourselves in the engagement space, in order to understand the domains[xxiv] and the influence of the instruments of power.  The team should look at the problem as a whole, perhaps using a simple Alternative Analysis[xxv] technique grouping yellow stickies on a whiteboard and discovering key influences.  I have used a technique advocated by SSM on a real-time operation, the “Rich Picture”[xxvi] to discover logical patterns and derive directions of inquiry.  By using analytical techniques with which we are comfortable, we are applying a framework to bring clarity to complexity, such as relationship and COG analyses (Figure 2).[xxvii]  Having rationalised and reached a form of consensus on our view of the world, we managed to avoid the mental traps of trying to fit the situation into existing constructs. 

Figure 2: From SSM - A Framework Helps Us See Complex Situations More Clearly

• Articulate (not just identify) the elements to be explored.  Our earlier factor analysis and COG analysis will have provided a list of candidates, or “purposeful activities” in SSM terms, for further exploration.  With SSM, we will articulate each purposeful activity through a root definition using the acronym CATWOE:
  • Customer: who would benefit or be a victim of this activity?
  • Actors: who carries out this activity?
  • Transformation: what is the purpose (the change of undesirable to desirable)?
  • Weltenschauung, as above.
  • Owner: who could enhance or stop this activity?
  • Environmental constraints: what circumstances of the environment do we need to consider? 

The CATWOE part of this process may look easy; it’s not and takes some practice.  However, it will provide insights to focus the development of the activity as a system. The resulting phrases will reveal system elements and verbs that describe the role of that element in the system. The core is T, the transformation process, which for planners shows the acceptable/ non-acceptable system state; it is key to articulating the decisive condition.

• Model the system as an activity.  This part could be tricky, so it’s worth breaking down.
  • We are not modelling the system in “hard” terms, accurately describing flows et al.  The activity model in SSM is merely an intellectual device that helps structure an exploration of the issue at hand through debate amongst the team.[xxviii]
  • The model should be simple, based upon the root definition; it will represent what we perceive to be the system from the knowledge we have gained.  There should be no more than seven (plus or minus two) elements in the model as an aid to understanding.[xxix] We shouldn’t spend too long building the model; it’s quick and dirty and just enough to engender debate and adjust the model.
  • In traditional SSM, we only link the system elements with direction arrows. I would go one step further: if this system is to be a candidate for a DC, we should incorporate influence, whether positive or negative, and its strength/ longevity.  This is what we would have explored in relationship and influence diagrams developed in the initial stages and it will help us develop effects and understand how we will learn that our actions are achieving the effects.[xxx]
  • Remember that the model is never final; we continue to learn throughout the process. In simple terms, we will develop effects that reduce negative impact and enhance the positive.  We will then develop actions to create the desired effect that will change a system element to from undesirable to desirable.
• Incorporate a learning loop.  We will now incorporate a learning loop that will tell us we are meeting the desirable condition as defined by “T” in our root definition.  In SSM, effectiveness and efficiency are measured; the military planner will recognise this as measures of effectiveness and performance.  We must also consider whether the military effects that we are creating will support non-military stakeholders or impact adversely upon their efforts.  Understanding the links between the LOO and the LOE is intrinsic to the Comprehensive Approach and provides a tool for civil military interaction. 
• Name the DC and Effects.  The DC and resulting effects are appropriately named, remembering that these are not final and may be adjusted or adapted as we continue to develop the other DCs.

Figure 3: A Soft System Model of Purposeful Activity

As we work through the DC candidate list, we will start to connect DCs and understand how activity to create one effect may impact negatively or be supportive of other DCs for our operation or the efforts of other friendly or neutral actors.  As the overall model develops, we will understand where concessions may have to be made if we are to achieve the political end state.  This is our contribution to the comprehensive approach.

Another benefit of having OR experts involved is that at some point in the future the Commander will need to balance his/her information collection assets.  Whilst we will attempt to apply as much empirical evidence as possible to our decision making, such a rationalistic approach to decision making may require greater resources than decision-makers either command or have the capacity to assimilate.  This systems approach to defining DCs should assist our OR people in developing a model akin to a mixed-scanning model that combines high order, fundamental direction (achieving objectives) and incremental managerial decisions, favouring principles of sufficiency and uncertainty over completeness and determinism.[xxxi]

All of this may sound long-winded.  As with all of our processes and methodologies, as users gain experience, the principles become internalised and they cease to think of it in an algorithmic fashion.  Let’s now work a very simple example based on a PSO responding to a United Nations mandate for Country T, whose end state focus is stability.  The COG analysis for the Joint Task Force (JTF) revealed deployment and sustainment as a critical requirement, with the capacity and operation of the main Sea Port of Debarkation (SPOD) as a critical vulnerability.  All LOOs rely on one fundamental DC if they are to reach the operational objectives: get the force into the area of operations (AO) and sustain the operation.  The Commander must have uninhibited use of the port; failure to protect this vulnerability would leave the JTF COG open to attack and, therefore, mission failure. I have selected this candidate DC because it has appeared in many designs and developed with minimal effort as “SPOD Secure”.  Furthermore, there were never links to activities on LOE, yet it was obvious that the force would not be the port’s only customer.

• Holistic View.  The only seaport capable of taking large vessels acts as an economic hub managed by the National Port Authority (NPA); it is a source of pride for the Government of country T, having been partially modernised; there is a single highway linking the port with the city; local traders set-up a market every morning to sell fish and other goods.  The port functions inefficiently due to competing demands within tidal constraints.  The international airport is small with limited pan or hangar space; however, we will consider its management and use as a POD.  Aid agencies are big customers of the seaport and regularly complain about the lack of capacity. There is an increasing threat from armed insurgents and smugglers whose techniques are mainly extortion and corruption.
• Root Definition: a Government owned source of national pride to efficiently enable humanitarian assistance, commerce and stability, for multiple customers under the constraints of tide and poor security.  This was derived from:
  • Customers: commerce, aid agencies, military forces
  • Actor: NPA
  • Transformation: inefficient function " optimised operation
  • Worldview: an outward symbol of the Nation’s capacity to govern
  • Owner: Government of country T
  • Environmental constraints: tide, limited access routes, insurgent/ criminal threat

Figure 4: Model of the POD System

• Model: this is a simple representation based on what we have learned and the root definition. It is far from comprehensive; however, it is designed to enable debate and enrich our overall understanding. It’s worth pointing out some key features:
  • Positive influence (green arrows): these are to be reinforced. Of particular note is the stabilising effect on the Government of appeasing its multiple customers: humanitarian assistance, security forces and commerce. 
  • Negative influence (red arrows): these need to be countered either through good management (weather, tide and competing customers) or through improved security.  The negative arrow has been drawn from competing customers to the NPA and not the functioning of the port; failure of the NPA to manage the port efficiently will in turn reduce the stabilising effect trade or humanitarian assistance has on the Government.
  • Decisive Condition: Optimized operation of Ports of Debarkation.  This is quite different from the original “SPOD Secure”. The benefit comes from the insights gleaned during debate of the model. For example, how best to improve the management of the NPA whilst retaining it as a symbol of a functioning Government?
  • Learning/ measuring: discussion of the effects we need to create that will reinforce the positive influences and counter the negative could be exhaustive. The team leader, taking advice from the Operations Assessment and OR SMEs, can now narrow these into a manageable set.
  • Links: I would now expect to see clear linkage between this DC and the LOE for the Nation and the UN; we will need to work a compromise between the arrival of military and humanitarian supplies as well as commerce.  Importantly, by working with aid agencies, we can measure the inflow of humanitarian aid and its effect on stability.

The debate around the model will reveal aspects that will be of interest across multiple branches and enrich the annexes that will make this plan executable.   We can now develop effects based on the system elements and influence, such as “Ports security enhanced” and “Ports management supported”, and relevant actions (Figure 4). The first cut of DCs will provide the first draft of the operational framework for the Commander’s approval and further guidance on intent.  As planning teams head off to work different courses of action, I would recommend most strongly a review of the COG and risk analysis to winkle out additional DCs, effects and links, in addition to Decision Points (DPs).  Badly written DPs is another of my planning bêtes noires.

Figure 5: DC, Effects and Links

As I mentioned earlier, the application of a linear approach is not necessarily conducive to the understanding a holistic system, and planning aficionados will undoubtedly be curling their toes as they point out the contradiction.  However, in a multinational environment where English is not the first language of many and there are several different educational perspectives, it is a good place to start.  With practice, methodologies like this become normalised and the process can gain momentum. 

One final word about Decision Points (DP); operational level planners must identify “points in space and time … where it is anticipated that the commander must make a decision concerning a specific course of action “[xxxii] during the planning process.  It’s the last part of the definition that is key: we have anticipated a change in conditions that will force us to deviate from the LOO and our aim is to restore our passage towards the objective.  The concept is illustrated at Figure 6. 

There are two common mistakes: failure to identify DPs and failure to develop branch plans. 

Figure 6: Principles of the Decision Point in the Operational Design

If there are no DPs then the planners have failed to identify risk; absence of risk is incredibly unlikely. Where there are DPs on the operational framework, there must be a branch plan; the DC(s) will be achieved through effects and those effects created by actions.  Those actions may require forces, resources or ROE that are additional to the initial statement of requirement, and should be submitted with the concept of operations so that the additional force can be generated and the ROE approved.

Using our worked example above, we have identified a risk that the Government of T loses control of the sea port before the JTF has arrived; whilst the probability is low, the risk to mission is very high.  To mitigate this risk, we need a branch plan that will be triggered by a DP.  Commander’s Critical Information Requirements (CCIR) are developed to monitor the situation and provide additional information as necessary.  A DC is developed that will use an alternative POD to bring in enough force to regain control of the port.  The actions required to create the effects necessary required additional force elements, equipment and more forceful ROE. 

In summary, our plans need to be robust if they are to be useful during the execution phase. Great analysis and the Commander’s brilliance is certainly helpful; however, we must write better DCs, well thought out within a holistic approach and treated as a system. The holistic approach starts from the earliest phase and is fully inclusive.  We then conduct a thorough COG analysis on all actors, which is our start point for defining DCs.  The Operational Commander is given his or her objectives, so the DCs can be applied to a LOO.  We must have LOE and understand the impact of our DCs on LOE.  The DCs are further refined as we develop courses of action; we continue to learn and adjust, even as we enter the execution phase.  I have modelled the idea with a simple example for a non-Article 5 crisis response operation.  Perhaps the reader might wish to apply this technique in an Article 5 scenario based in the Baltic States, where a fundamental enabling DC would be control of the bridges over the rivers Daugava, Gauja and Pärnu, if the Commander is to retain freedom of action. There will be multiple customers for those bridges and the additional force requirement considerable.

If an operational planner takes anything away from this, please open the debate when developing DCs and treat them as systems, not tasks, and keep asking the questions.  As Confucius once said: He who knows all the answers has not been asked all the questions.

End Notes