The Criticality of Collaborative Planning

In both 2011 and 2012, the Barack Obama administration announced a pivot to the Asia-Pacific region. One of the factors necessitating this pivot was the strained relationship between China and Japan, as well as the U.S. bilateral agreement with Japan to provide security for it. Furthermore, recent disputes over the Senkaku Islands in the East China Sea have placed a premium on how the United States postures to meet its obligations politically and militarily. President Obama confirmed that the U.S.-Japan bilateral security pact applies to the islands. The asymmetric nature of this situation demands a dynamic and flexible planning capability—not one focused only on military operations, but one that also integrates diplomatic, information, military, and economic dimensions of power into a coherent strategy.

U.S. Paratroopers assigned to 91^st Cavalry Regiment, 173^rd Airborne Brigade, recover parachutes following jump during airborne exercise with German and Czech counterparts at 7th Army Joint Multinational Training Command’s Grafenwoehr Training Area, Germany, October 1, 2014 (U.S. Army/Gertrud Zach)

The complexity of planning these military operations is exacerbated by the need to quickly respond to new threats and challenges. As such, a 21st-century planning process must be a joint enabler that is flexible, dynamic, adaptable, and collaborative.

This article focuses on the collaborative aspect of the planning process because collaboration is less about expensive tools that may or may not be or become available, and more about approach or even mindset. Collaboration can be defined as working together to execute a task to achieve an agreed-upon goal. When properly enabled, people can work together toward a goal and combine their expertise, insights, and resources while moving through some process to complete the task.1 Yet military planning involves challenges due to working in a large, culturally diverse, hierarchical, globally distributed team with existing and emerging inter- and intra-organizational relationships and benefits. Operational benefits of working with such teams can be realized if the members are able to communicate in real time and maintain a shared understanding of commander’s intent, strategic objectives, and resources. This shared situational awareness must be maintained in a highly dynamic setting.2 The loss of shared understanding due to stovepiping or bottlenecking may result in decisions that are inconsistent with overall mission objectives.

We intend to discuss current challenges and proposed changes to the planning processes. Specifically, we present an overall planning framework and introduce the collaboration engineering approach as a way to design repeatable, collaborative planning activities.

Military Planning: Present and Future

Today’s joint planning processes were designed during World War I and World War II to support operations of the day that involved sequential events, known (or at least expected) battle rhythms, and extended timelines (see figure 1). This method no longer seems appropriate or in line with changing world conditions that demand shorter decision cycles. The 24-month contingency planning cycle seems too sluggish to keep up with the faster-paced world in which we operate. Past missions and recent exercises demonstrate that off-the-shelf plans are often too static, too difficult to adapt, and too heavily based on assumptions, assessments, forces, and circumstances not encountered during actual crisis situations.3

Compounding this already challenging environment, joint planning is largely compartmentalized and authoritarian, perhaps understandably much like the military it supports. The result is often time-consuming adjustments, extended development timelines, and uninformed, less responsive decisionmaking.

In tomorrow’s global environment (which could literally be tomorrow), there are a multitude of probable regions for serious U.S. national security concern. Any future military planning construct must understand the dynamic nature of the environment in which plans are created and executed as a sort of wiki, where planning artifacts are ever-evolving, the planning environment is inclusive, and the commander’s objectives are met. In this future environment, participants can add fidelity and contribute to a common operating picture by continuously updating newly emerging knowledge from a data-rich environment. To achieve this, the collaborative planning process must be defined, accepted, and sold by leadership. These processes will then lead to an architecture that can be used as a blueprint for the development and production of future enabling tools.

The future planning model (see figure 2) is envisioned as a cyclical, collaborative exchange that emphasizes the planning process as being a real-time capability. To do this, multiple procedures must be performed simultaneously with current and relevant information derived from an extensive data-rich environment, in a real-time collaborative network of people and tools that drives the schedule that defines an agile virtual battle rhythm. The cyclical collaborative exchange allows for flexibility in battle rhythm—for instance, being proactive or rapidly responsive rather than waiting for a scheduled meeting. Five critical procedures in the future planning environment lead to relevant, desired outcomes:

• Achieve situational awareness: specific, focused, and inclusive knowledge of anything affecting the plan; continuous and collaborative flows of information for planning.
• Create directive: joint planning objectives, concept plans, operations plans, and concepts of operations derived from current and appropriate portions of the national and defense guidance.
• Assess: understanding the situation, scope, and involved community.
• Decide upon course of action: product resulting from the planning process that is presented to decisionmakers. It can be military, diplomatic, or a combination.
• Execute: carrying out the plan.

In the future planning environment, situational awareness and shared understanding become the most important inputs to the collaborative planning process. These originate not only from intelligence and diplomatic agencies, but also from across the planning processes and community of interest so that appropriate courses of action can be developed, adjusted, and presented to decisionmakers. The wiki planning process thus creates living and continuously evolving artifacts throughout all phases of the operation.

To realize the future planning process, appropriate collaboration processes must be defined and engineered; concepts developed, approved, and applied; and architectures developed for tools to be engineered. At present, there is no common model of how military planners should undertake collaboration. For the most part, collaboration happens by sheer force of will and actions by individual planners to meet a regularly scheduled battle rhythm. We propose that the “collaboration engineering approach” is one viable way to purposefully design operational planning such that it will expedite the quality and quantity of decisions and products and bring about unity of effort among disparate mission partners.

The Collaboration Engineering Approach

Collaboration engineering is an approach to design and deploy collaboration processes and technologies that are then transferred to practitioners to execute without the ongoing intervention of a professional facilitator. It specifically focuses on processes for mission-critical tasks that frequently recur. To design such processes, collaboration engineering recognizes different ways in which people work together toward goals and the best practices to guide them in these efforts. The five distinct forms in which people work together are called patterns of collaboration. Each collaboration process consists of a particular sequence of activities in which one or more patterns of collaboration among team members unfold. To purposefully create a pattern of collaboration during a process activity, a team leader can use facilitation best practices called “thinkLets” (see table 1).

ThinkLets. A central foundation for collaboration engineering is the use of design patterns to support the design and transition of collaborative work practices. Design patterns are composed of named and scripted procedures called thinkLets, which are a best practice for a collaborative task that creates one or more patterns of collaboration. The practitioner uses the thinkLet to evoke a certain pattern of team behavior by means of giving short and simple instructions to the team. For example, a LeafHopper thinkLet allows a team to brainstorm ideas for a collection of topics simultaneously. The LeafHopper thinkLet defines how the team should set up its workspace and what instructions members should receive. In this instance, the team can use a dedicated collaboration tool or a collection of papers on the wall labeled with titles. Instructions are to generate ideas for specific topics, start with the most familiar or interesting topic, and read what others generated and build on those ideas.

ThinkLets represent a menu of “collaboration Legos”: they can be combined into best practice collaborative problem-solving processes. When appropriately combined, thinkLets guide team members through a reasoning process of collaboration patterns that allows them to focus all their attention on a single, more manageable reasoning task. During the brainstorming part of the course of action development, a variety of ideas can be generated by means of requiring team members to produce as much information as possible without evaluating. In this case, the process of generating ideas is separate from the process of evaluating information, allowing team members to focus their attention on a single task that is uninterrupted by interpersonal discussions.

Each thinkLet has a catchy name to support recognition and memorization of the technique’s essence and provide a common lexicon between the private and public sectors. The thinkLet is known only to the practitioner who uses its script as a sequence of things to say and do to evoke the desired pattern of collaboration within the team. Each thinkLet also defines the specific technology that the team must use to execute the script and the configuration of those tools—for example, the tool settings and pre-loaded data. ThinkLets can make use of simple pen and paper technologies or sophisticated technologies, such as a Group Support System (GSS).

Group Support Systems. A GSS is a suite of collaboration tools that support creative problem-solving and co-creation in collocated and distributed teams. It includes the software for electronic brainstorming and electronic voting as well as the methods to accompany the tools and the environment in which the tools are used. More than 2 million people worldwide, including members of the U.S. Army and Navy, have participated in GSS-supported meetings to encourage creative problem-solving toward a common goal or task. Extensive case studies have shown that a GSS can reduce project labor costs and calendar days required for completion by over 50 percent.4

The GSS supports a team along four fundamental dimensions (communication, deliberation, information support, and goal congruence) to help address some common challenges that may affect team productivity. First, team members communicate ideas and preferences anonymously and in parallel, thus alleviating such challenges as dominance, evaluation apprehension, and ideation production-blocking. Second, teams use a meeting structure that keeps them focused and on time. For example, during a generation task, an electronic brainstorming tool provides each participant with a different electronic page where a single, short idea is entered. The system then randomly sends the page to another participant and brings a page containing someone else’s idea. Third, the GSS creates complete records of the electronic discussions, enabling future review and analysis. Finally, features and functions in a GSS encourage the alignment of team and individual goals.

Personnel from the U.S. Army Research Laboratory did a case study on the use of a GSS software tool at the Command and General Staff Officer’s Course, the Army’s tactics and decisionmaking course for field grade officers. The software GroupSystems was applied to the 17-step mission analysis process in the Military Decision Making Process (MDMP). The MDMP is sequential, often cumbersome, and complex (and thus intimidating) when applied to today’s modern mobile and dynamic battle space. The Army used a GSS for parallel planning to increase the speed and quality of plans through the GroupSystems brainstorming, organizing, and evaluation tools. Many students found that the GSS greatly reduced the time required to complete the mission analysis, improved staff coordination, and resulted in a better product. Students noted that synergism among individuals improved as the tool facilitated staff cross-talk and interaction, which helped students profit from others’ ideas and input.5

The benefits of and successful experiences with the GSS cannot just be attributed to the tool itself. For a GSS-enabled collaboration effort to succeed, a precise collaboration process has to be carefully crafted. In the collaboration engineering approach, the potential of the GSS is blended with the thinkLets design library to enable such collaboration processes. A thinkLets-based approach to the collaborative creation of the deliverable mission statement is presented next.

Participants of U.S. Army Africa Training Center Capabilities Seminar 2015 receive capability briefing at 7^th Army Joint Multinational Training Command in Grafenwoehr, Germany, November 3, 2015 (U.S. Army/Gertrud Zach)

Collaboration Engineering for Mission Statement Creation

A key activity of the planning process, whether it follows legacy planning processes or a future dynamic model, is to develop the commander’s mission statement. It must be a clear, concise statement of the essential (specified and implied) tasks to be accomplished by the command and the purpose(s) of those tasks. Although several tasks may be identified during the mission analysis phase, the mission statement includes only those that are essential to the overall success of the mission. The tasks that are routine or inherent responsibilities of a commander are not included in the mission statement, which becomes the focus of the commander’s and staff’s estimates and is reviewed at each step of the process to ensure planning is staying on course. Because of the statement’s importance to planning and the frequency with which it is accomplished, a thinkLets-based approach to developing essential tasks is presented below. In this case, the specific product is the mission statement. Since the mission statement is derived from the essential tasks, the thinkLets-based method also creates the objectives and specified and implied tasks that make up the essential tasks.

Process Design. A conceptual design using thinkLets has been created for the development of the mission statement. This process can also be applied to other defense activities such as idea generation during course of action development. Figure 3 shows the notional design and a thinkLets template. A summary of the thinkLets, patterns of collaboration, and purposes is presented in table 2. The collaborative process lets a team develop the event’s two categories of artifacts: objectives prescribe friendly events, and tasks describe friendly actions to create desired effects or preclude undesired effects. The artifacts are related; a single objective may have multiple tasks. The design process allows a team to derive objectives and task information in parallel. Furthermore, each artifact can be continuously modified, based on deeper insights as other artifacts are developed.

The process starts with a FreeBrainstorm (diverge) and TreasureHunt (converge) thinkLets sequence to create a list of clearly defined objectives. The team first generates as many objectives as possible, including information concerning their constraints, restraints, assumptions, resources required, and timing considerations. To this end, the team makes contributions in parallel to a number of discussion categories, which display the objectives-related contributions for inspiration to add further detail. Next, using the TreasureHunt thinkLet, pairs of team members extract the most promising objectives from the separate buckets into a central list, rewording them where necessary. The team thus ensures that each objective in the list is clearly defined and unambiguous and that no overlap between objectives exists.

Next, the team uses the LeafHopper thinkLet (organize) to collect information regarding the effects and tasks for the objectives. During this thinkLet, each team member contributes relevant information to the objectives that he or she knows or cares most about so that the team collects a lot of raw information regarding the objectives’ tasks. This raw information is processed, consolidated, and prioritized during the BucketShuffle thinkLet (evaluate). During this activity, the team is split into small subgroups of two or three members, and each subgroup becomes responsible for one or more objectives. The subgroups process the raw information by extracting clearly formulated tasks, and, if necessary, by rewording the objectives during this process as well. After each subgroup is done, it reviews the work of the other subgroups, leaves comments, and processes the feedback received on its own work. During this part of the process, it is also possible for directorates, divisions, or components to delineate how they can support the objective conceptually. As mission statement development includes geographically dispersed teams, electronic GSS tools should be applied to connect teams. As the process is conceptual, it should be tested and then compared to the old way of doing business in order to collect data and make improvements.

Metrics. Metrics should be designed and applied to measure the effectiveness of all collaboration engineering efforts. Regarding the conceptual design of the mission statement product, data can be collected from senior leaders, users, developers, and practitioners from surveys, questionnaires, one-on-one interviews, focus groups, or direct observation.6 Many metrics are also located in systems, records, or databases; hence, if a GSS is used, those metrics can be monitored to compare them to expectations or trends. The quality of the design object can be measured with the following indicators:7

• satisfaction of process owner and participants
• quantity of results of the collaboration process
• reusability of the collaboration process
• perceived ease of use of practitioner who leads the effort
• perceived gain in productivity of the collaboration process.

Mission statement development should be measured twice: first, using the current process, and then implementing the collaboration engineering process design in figure 3. Comparing the results will help with process analysis for total process improvement. Metrics help with process analysis in identifying the actual cause of the gap between the expected and actual result (for example, time was longer due to improved quality). As for process improvement, metrics are an important part of determining and ensuring operational success as they show what is working and not working and provide information to make adjustments.

U.S. Soldier with 3-27^th Field Artillery Regiment, 2^nd Fires Platoon maps target areas during Exercise Dragon Strike at Avon Park Air Force Range, Florida, June 10, 2015 (U.S. Air Force/Dillian Bamman)

Final Thoughts

Military planning processes are critical yet complex, partly because of the collaborative nature and requirements that they impose on the actors involved. While we do not present the collaboration engineering approach as the single solution for all planning challenges, we argue that it may well provide the concepts and design thinking approach that may improve an evolved planning process, resulting in higher quality deliverables in less time. In fact, both the U.S. Army and Navy have conducted case studies on the implementation of the GSS in their planning processes with successful results, such as increased speed and higher quality of plans. The current data-rich environment places a high demand on planning processes that support the battle rhythm of a collaboration-friendly community. Fresh thinking or a reinvigorated approach seems needed to reengineer legacy processes into adaptive, dynamic, and timely tools for the emerging national security playing field.

Today’s complex national security environment requires accelerated decisionmaking by leadership and strong coordination of military operations to respond to emerging threats. The current planning process served its masters well despite being slow, static, and sequential. Now is the time for a paradigm shift to planning processes that are adaptive, dynamic, and timely, based on situational awareness and collaboration in support of everyday missions. JFQ

Notes

1 Gert-Jan de Vreede, Robert O. Briggs, and Anne P. Massey, “Collaboration Engineering: Foundations and Opportunities,” Journal of the Association of Information Systems 10, no. 3 (2009), 121–137, available at <http://aisel.aisnet.org/jais/vol10/iss3/7/>.

2 Michael C. Dorneich et al., “Lessons Learned from an Evaluation of a Shared Representation to Support Collaborative Planning,” Knowledge Systems for Coalition Operations 1, no. 11 (2012), available at <http://ksco.info/ksco/ksco-2012/papers/KSCO-2012-Allen-Evaluation-of-CPM.pdf>.

3 Robert M. Klein, “Adaptive Planning: Not Your Great-Grandfather’s Schlieffen Plan,” Joint Force Quarterly 45 (2nd Quarter 2007), 84–88, available at <http://ndupress.ndu.edu/portals/68/Documents/jfq/jfq-45.pdf>.

4 Gert-Jan de Vreede and Robert O. Briggs, Facilitation of Technology Supported Collaboration (Omaha: University of Nebraska Omaha, 2011).

5 Robert J. Harder and Howard Higley, “A Group Support System for Military Mission Analysis,” paper presented at Proceedings of the 36th Hawaii International Conference on System Sciences, 2003, available at <http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1173668>.

6 Ann Fruhling et al., “Designing and Evaluating Collaborative Processes for Requirements Elicitation and Validation,” paper presented at Proceedings of the 40th Hawaii International Conference on System Sciences, 2007, available at <http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4076398&tag=1>.

7 Ibid., 4.