Making a single decision, and then repeatedly cycling through deciding what to do next, is essential. In contrast to the traditional warship acquisition framework, which emphasizes control and cost minimization for fixed requirements leading to a “single loop” process, the cyclical OODA Loop approach inherently focuses on learning and refinement in stride. With an emphasis on a faster pace, action must be taken without perfect knowledge and it is recognized that there is an increased chance that the wrong choice might initially be made. Risk aversion inherent to a bureaucracy can stymie the process. But the cyclical nature of the OODA Loop fosters learning and with multiple iterations, analysis and decision making are refined with more observations of results and outside information, including the adversary’s responses to actions taken. This leads to fruitful results.
That was from a nice NPS Symposium paper by Michael Good and Glen Sturtevant, “Technology Insertion OODA Loop Strategy for Future Flexible Surface Warship Acquisition and Sustainment.” While the authors put together a really nice paper, these concepts are not new. Evolutionary Acquisition (EA) has been a mantra since the late 1990s and in reality, decades before. Here are the authors on the acquisition process:
EA essentially divides large systems into smaller chunks, increasing delivery flexibility and decreasing scheduling risk. Each block upgrade is managed as a separate increment for a fully operational system. Each increment will have its own set of requirements, funding, review cycles, certification and accreditation, milestones and Acquisition Strategy, in sequence.
Here’s my big problem. If we modularize program development into separable tasks, such as platforms, payloads, mission systems, integration efforts, and so forth, and each one requires its own funding line item in the budget, that could create a disjointed process. It still takes 2+ years to program the budget for any of these separable tasks. If lead time to pivots and new starts is measured in years, then you’re forced to try to predict the whole effort as if it were a single waterfall program. So while I agree in principle that the Adaptive Acquisition Framework and other policies in requirements and contracting allow for agile/incremental/evolutionary/etc. in theory, in reality the outcome is unlikely.
The authors express the need for experimentation. A pot of unprogrammed funds available for prototyping and experimentation that can be directed to projects in the year of execution is key. The authors point to the Rapid Prototyping Fund created in the FY 2017 National Defense Authorization Act:
Authorize each of the Services to utilize funding that is not tied to a specific Program of Record in order to prototype upgrades of components and to develop technology faster and more efficiently.
Unfortunately, that pot of unprogrammed funds is no longer being funded. If the money isn’t there to support experimentation that takes the OODA loop to heart, then the rest of it becomes a moot point.
Read the whole paper though, there’s a lot of great material. Here is a really good point from David Ullman:
Since the OODA loop was designed to describe a single decision maker, the situation is usually much worse than shown as most business and technical decisions have a team of people observing and orienting, each bringing their own cultural traditions, genetics, experience, and other information. It is no wonder that we often get stuck here, and the OODA loop is reduced to the stuttering sound of OO-OO-OO.
Leave a Reply