Joint Publication (JP) 5-0, Joint Operation Planning, contains a significant editing error that, if not corrected, will further confuse the integration of the already difficult concepts of “design” and the “center of gravity.” Figure III-4 incorrectly places identification of friendly and enemy centers of gravity (COGs) in operational design’s “understanding the operational environment” step.1 This placement is also challenged by the J7’s Planner’s Handbook for Operational Design and the 2006 version of JP 5-0.2 A better placement would put identification of the enemy center of gravity in the “defining the problem” step and the friendly center of gravity’s identification in “developing the operational approach” step. The good news is the error is repairable.
JP 5-0, Figure III-4. Understanding the Operational Environment
This article argues three main points. First, commanders and staff cannot properly identify enemy COGs until after they have defined the problem. The logic is that until we identify the problem, we cannot be sure who or what the real adversary is. Second, as the commander develops an operational approach, or solution to the problem, he identifies his friendly COG; different approaches to solving a problem may require different capabilities and therefore different friendly COGs. Lastly, identifying the enemy and friendly COGs during the “understanding the environment” step is premature, illogical, and counter to the intent of operational design thinking.3 The conclusion then recommends changes to current doctrine that would make operational design and the center of gravity concept more compatible and complementary.
When doctrine writers introduce a new concept such as operational design, they try to integrate it with existing concepts in a complementary way. Unfortunately, this is not always easy; doctrine is not “plug and play.” Making sure the new concept is ready is only half of the integration process. Integration of new and older concepts and how they will function together requires thorough consideration. Existing concepts need to be reexamined in light of the new concepts and, if necessary, adapted to fit the new. Unfortunately, even with thorough consideration, doctrinal or editing errors are still possible. These errors may occur because a new concept has not fully matured or the implications on existing doctrine are not fully realized at the time of publication. The latter appears to be the case with JP 5-0’s discussion of operational design and the center of gravity.
In JP 5-0, figure III-4 clearly shows that the identification of friendly and enemy COGs is an output of operational design’s “understanding the operational environment” step.4 The placement of the COG identification in this step is likely based on a poor understanding of JP 2-01.3, Joint Intelligence Preparation of the Operational Environment (JIPOE), which discusses COG identification in detail.5 JP 2-01.3 emphasizes using a holistic view of the operational environment to identify centers of gravity in a system. The use of the word environment in both design’s first step and the JIPOE’s discussion of centers of gravity may have contributed to misplacing COG identification. The first step of JIPOE defines the operational environment, which includes understanding the joint force’s mission, operational area, and significant characteristics of the operational environment; this is consistent with design’s first step.6 However, the COG is not identified in this step. JIPOE’s identification of enemy COGs occurs in the third step, “evaluate the adversary,” which in some ways is similar to design’s “define the problem” step.7 It is assumed that a misplaced focus on the word environment led someone to mistakenly place the COG identification step in operational design’s “understanding the operational environment” step. It is an easy mistake, and even easier to overlook, but it represents a lack of understanding of the purpose and origins of operational design, specifically the problem identification and operational approach steps.
The purpose of design thinking is “to understand, visualize, and describe complex, ill-structured problems and develop approaches to solve them.”8 The origins of design thinking in military doctrine resulted from a recognition that commanders were having difficulty understanding increasingly complex environments that in turn hindered their ability to distinguish between the symptoms and the actual root causes of problems. This inability to identify root causes of problems led to solutions that often attacked symptoms rather than the root problem, with disappointing results. What commanders needed was a better identification process suited to ill-structured problems to complement existing problem-solving processes such as the joint operation planning process. Operational design was the solution to this challenge and is essentially a methodology for understanding complex environments and identifying ill-structured problems and potential solutions.
Operational design, as described in JP 5-0, “is a process of iterative understanding and problem framing that supports commanders and staffs in their application of operational art with tools and a methodology to conceive of and construct viable approaches to operations and campaigns.”9 Operational design consists of three steps: “understanding the strategic direction,” “understanding the operational environment,” and “defining the problem.” The answers or understanding obtained from these three steps enable the development of an “operational approach.”10 (A claim could be made that developing the operational approach is actually a fourth step that completes the operational design process, but doctrine does not label it as a step.11)
Understanding the Strategic Direction
This step helps the commander understand the strategic endstate and objectives as the starting point to formulate a vision of what the desired environment should look like. It simply asks, “What are the strategic goals to be achieved and the military objectives that support their attainment?”12 More simply, this step defines the goalposts and where they are, but not how to get to them. That occurs later in the process. This step provides a framework that defines the desired environment, but it does not describe the current environment. That framework and description are filled in during the second step.
Understanding the Operational Environment
The purpose of this step is to “help the [joint force commander] . . . better identify the problem; anticipate potential outcomes; and understand the results of various friendly, adversary, and neutral actions and how these actions affect achieving the military end state.”13 It asks, “What is the larger context that will help me determine our problem?”14 This step can be thought of as a prerequisite, not an end. This is a key point. In the 2011 version of JP 5-0, “understanding the operational environment” is one step in a larger design process. In this step, the commander and staff create “pictures” of the current and desired environments. It is akin to collecting and assembling the pieces of two puzzles. The goal is to arrive at understanding by assembling the pieces and knowing why and how the pieces fit and function together. At the end of this step, the commander and staff should be able to look at each puzzle (current and desired environments) and understand what is going on in the current environment and why, and what the desired environment should look like. The only things that have been identified are the desired and current conditions, actors, relationships, functions, and tensions in the environment that establish the operational context.
Any discussions of centers of gravity at this point are premature. A detailed understanding of 2006’s JP 5-0, JP 2-01.3, and the discussion in 2011’s JP 5-0 support this conclusion. For example, the 2006 pre–operational design JP 5-0 states, “The primary purpose of mission analysis is to understand the problem and purpose of the operation.”15 This clearly suggests that identifying the problem is paramount and other planning elements derive from it. Even the Planner’s Handbook for Operational Design acknowledges that COG identification in the environmental step, and prior to problem identification, is premature when it states that “Given sufficient time, planners should defer COG analysis until they have at least an initial problem frame, because identifying the factors that comprise the problem should facilitate COG analysis.”16 Identification of problems or adversaries and solutions that would provide insights to COG identification occurs in the following steps.
Defining the Problem
Defining the problem’s purpose “is defining what needs to be acted upon to reconcile the differences between the existing and desired conditions.”17 In this step, the commander looks at the environment “puzzles” and asks what the problem, obstacle, or condition is that prevents the current environment from becoming the desired environment. The answer to this question defines the problem and what needs to be “fixed.”
The problem is not the enemy COG. The problem merely defines the adversary or enemy system. (Note, in this context, the terms adversary or enemy do not imply hostility, only that they are obstacles to obtaining the goals. They are “the problem.”) This adversary system contains a center of gravity that must be identified by studying the system.18 This is where some argue that design’s problem statement actually replaces the COG. This is an incorrect understanding. The defined problem is not the center of gravity. Rather, it determines what the adversary system is and sets up a systems analysis based on the adversary’s goals, capabilities, and requirements that contribute to the COG identification and analysis process of that system. Planners using a systems perspective analyze the adversary system that is causing the problem to determine the enemy center of gravity. More simply, design’s problem identification defines for commanders and planners the system in which to look for an enemy center of gravity. Once the adversary or enemy center of gravity is identified, the next logical step is determining how to solve the problem.
JP 5-0’s figure III-4 would have the commander identify the enemy center of gravity prior to determining the adversary or enemy system causing the problem facing the joint force. This makes no sense and is contrary to the intent of operational design as expressed in the J7 handbook on operational design, which states:
The requirement to frame the problem and write a problem statement early in design raises a question concerning how the problem relates to one or more centers of gravity. Both [COG and problem] are important to developing the operational approach, but the caution to planners is that jumping to COG analysis too early in design [specifically understanding the environmental step] can constrain creative thinking about the problem.19
JP 5-0, Figure III-6. Defining the Problem
This statement clearly indicates that identifying the COG should not precede problem analysis.
Developing an Operational Approach
Just as the identification of the problem provided an enemy system for COG analysis, development of an operational approach guides the selection of a friendly center of gravity: “The operational approach reflects understanding of the strategic direction [step one], the operational environment [step two], and the problem [step three] while describing the commander’s visualization of a broad approach for achieving the desired end state.”20 Simply speaking, the operational approach is a description of the solution to the problem. It outlines the objectives, actions, tasks, missions, and desired conditions that are intended to solve the problem. These actions then help identify critical capabilities required to address the problem and achieve the objective. These critical capabilities in turn will suggest a friendly center of gravity that can perform the actions and achieve the objective.
JP 5-0—as currently illustrated, but contradicted by the J7 design handbook—has the commander identifying the friendly center of gravity before defining the problem and determining the broad operational approach to solving the problem. This is selecting “the tool” before we know what needs to be fixed or how to fix it. This type of logic is exactly what design thinking means to prevent.
Here is one way to think about an operational approach and its relationship to the friendly center of gravity. Since most problem sets can be described as blocking, lacking capacity, or faulty behavior, a technique for developing an operational approach is the remove, provide, and change (RPC) framework. For example, if the problem is blocking the transition to the desired state and it is not needed in the desired state, then removal is an approach. If the problem is the absence of a requirement or capability, then an approach is to provide. If the problem is a behavior or a condition of a requirement, or something that cannot be removed, then change is an approach. Again, these are broad categories of approaches, and actual approaches will be more specific and the lists of approaches are only limited by the ability to think creatively, but RPC provides a starting point. Additionally, these categories can be used in combination for a multifaceted approach to addressing the problem set.
Once an RPC approach or combination is selected, commanders and staffs can identify the friendly center of gravity by asking who or what has the critical capability to execute the RPC action and achieve the objective or endstate. The answer to that question is the friendly center of gravity.
The Illogic of Identifying the COG in Step Two
JP 5-0 figures III-4 and III-6 clearly show that friendly and enemy COGs are an output of “understanding the operational environment” and an input to “defining the problem.”21 Interestingly, in the textual discussion, there is no mention of COGs in either step. The error appears only in the figures. This, along with the J7 design handbook, suggests that doctrine never intended COG identification to be part of “understanding the operational environment” because of weak logic. It also suggests that the figures may simply contain an editing error. On the other hand, COGs, in the context of operational design, are first discussed in JP 5-0 in the narrative on developing the operational approach. The discussion does not specifically address when COG identification takes place, only that COGs, along with other elements of operational design, are useful in developing an operational approach.22 This suggests that COG identification should occur prior to the completion of an operational approach, but it is ambiguous. As shown in JP 5-0, it occurs during understanding the environment. But is this logical?
Here is an example using the current logic of JP 5-0’s figure III-4. The operating environment is an old house. The strategic direction (step one) is to have a solid floor. The current environment has a floor with loose boards and nails sticking up. The commander, knowing the goal is solid floors and seeing that the boards are loose and nails are sticking up, identifies the nails as the enemy center of gravity and a hammer as the friendly center of gravity. The commander is tempted to skip “defining the problem” and go directly to developing an operational approach—that is, hammering in the nails. After all, why define the problem if we already have identified the friendly and enemy COGs? It is a superfluous step. But is it?
The commander resists and continues to use operational design. To define the problem, he looks at the current and desired environment and asks probing questions to get at the root problem and not be misled by symptoms. Are the boards loose because the nails are sticking up? What caused the nails to stick up? Could the boards be warped, causing the nails to pull out? What is the condition of the wood? By attempting to identify the problem, he refines his understanding of the environment and realizes that the nails are not the problem or the enemy COG but rather a symptom of a larger problem that he needs to identify. He now realizes his hammer COG—and hammering nails—might not be the solution. By defining the problem, he may realize that the enemy COG is warped and rotten wood, which he needs to replace—that is, his operational approach. So now his COG is no longer a hammer, but new floorboards.
Without operational design thinking, the commander may have chosen to hammer nails, and when that did not work satisfactorily, try another approach and so on until the problem was ultimately solved or the effort abandoned, both at additional cost. Operational design was specifically introduced into doctrine to address this problem of misidentifying symptoms as root causes. Therefore, it is critical that the error be corrected because in the best case it will be ignored or explained away, which undermines doctrine’s credability. In the worst case, it subverts operational design and takes doctrine backward to where symptoms, not root causes, are addressed.
Operational design’s discrete steps can enhance understanding and enemy and friendly COG identification by correctly placing them into separate cognitive bins in a logical sequence. By asking what the root problem is before determining an enemy COG, operational design can point commanders and staffs toward an adversary system in order to identify the enemy center of gravity. This center of gravity, if attacked directly or indirectly, can significantly contribute to solving the problem. By asking in the “developing the operational approach” step, how the problem can be solved or center of gravity attacked and what has the capability to do so, commanders have an insight as to what their friendly center of gravity is or should be. Any discussion of enemy and friendly centers of gravity prior to defining the problem and the start of developing an operational approach is illogical and negates the utility of operational design.
This issue can be resolved by adopting two recommendations. The first is to delete references to friendly and enemy centers of gravity in figures III-4 and III-6. This recommendation corrects the error, but alone is insufficient to increase understanding of how operational design and the center of gravity concept complement each other. To improve understanding and clarity, a discussion of enemy COG identification should be added to the narrative on defining the problem along with a similar discussion on the friendly COG in developing the operational approach.
The discussion should include the following points: The problem defined in step three identifies the adversary and its system and sets up a systems analysis for identification of the enemy center of gravity in accordance with JP 2-01.3. More simply, design’s problem identification defines for commanders and planners the system in which to look for an enemy center of gravity. In step four, developing an operational approach, the enemy’s center of gravity and critical factors analysis will identify requirements and vulnerabilities that suggest where to act and offer possible solutions or actions to take. These actions require capabilities, and the possessor of these capabilities is the friendly center of gravity.
Adopting these recommendations and clarifying the relationship between operational design and center of gravity will strengthen synergy and contribute stronger, more useful doctrine. JFQ