Agile Acquisition for... Hardware?

Agile processes using minimum viable product strategies enable hardware development to deliver capabilities at speed

By Joseph Novick

Article published on: April 1st 2024, in the Spring 2024 AL&T Edition

Read Time: < 9 mins

In 2020, the Department of Defense outlined its DOD Instruction 5000.02, “Operation of the Adaptive Framework,” to provide program managers with a variety of options for acquiring weapons systems and defense capabilities. Its goals included empowering program managers to execute simplified and tailorable acquisitions, data-driven analysis and active risk management, while emphasizing sustainment to deliver capabilities faster through the acquisition process. While DODI 5000.02 is a framework that enables flexibility in acquisition, it does not present program managers with methods to shorten programmatic timelines.

Through the Urgent Capability Acquisition process, two programs—the High Mobility Decontamination System (HMDS), a terrain chemical agent decontamination trailer-mounted capability, and the Negatively Pressurized Conex (NPC), a portable isolation room built inside a steel shipping container in order to keep infectious patients from contaminating others on the aircraft transporting them—delivered urgent capability at lightning speeds by using a hybrid approach to acquisition. These programs tailored their acquisition process using methods typical of agile software development despite being hardware-centric systems. Software development companies focus on agile strategies as a primary project management structure; however, agile project management is not common in hardware development in DOD acquisition. The HMDS and NPC teams used minimum viable product (MVP) and iterative prototyping strategies, pillars of software development, to design, develop, test and deliver hardware systems at the speed of relevance.

FAST MOVING
The minimum viable product process for hardware development used in the urgent needs pathways to develop the HMDS and the NPC. (Graphic by the author)

Both programs had significant design and development processes and robust test programs while moving in high-pace acquisition environments. The HMDS fielded its initial capability within nine months, and “the first NPC mission was flown 85 days from JUON [Joint Urgent Operational Need] issuance,” retired U.S. Air Force Col. Paul “Jimi” Hendrickson said in his 2021 presentation “The Negatively Pressurized Conex (NPC) Program – How Acquisition and Systems Engineering Agility Delivered Capability to USTRANSCOM in 95 Days.” The NPC team won the David Packard Excellence in Acquisition Award in 2021, DOD’s highest acquisition team award.

This article will describe how program managers can apply agile processes, typical of software development, to deliver hardware capabilities at a rapid pace. It will consider the DODI 5000 definitions of minimum viable product, recommend a new definition of MVP that is inclusive of hardware development, and provide a template for program managers to use MVP and iterative prototyping in hardware acquisition

What is an MVP

When I talk to acquisition professionals in hardware development and they hear the term “minimum viable product,” they tend to think of an end-product with the minimum performance benchmarks to meet a stated requirement. Tey envision an end-product where features are removed until the product fts within cost, schedule and performance constraints before production and fielding.

Those in software development, however, think of the term in a completely different way. An MVP is an early prototype designed to understand the usefulness or potential demand of a product with the minimum amount of effort necessary. An MVP is a starting point. DODI 5000.87, “Operation of the Software Acquisition Pathway,” defines an MVP as “an early version of software to deliver or field basic capabilities to users to evaluate and provide feedback on. Insights from MVPs help shape scope, requirements and design.”

This is the only definition for an MVP in the Adaptive Acquisition Framework. Notice that it focuses on gathering information early in the product development cycle. It is a ball of clay ready to be molded. Also notice the definition specifies “software.” DOD could modify the MVP definition to incorporate hardware and software. A general definition of an MVP for DOD hardware and software capability development could be “a prototype that provides the program office with enough information to determine that the acquisition is worthwhile as soon as possible in the product development process. It may or may not be a fielded product,” as defined in my 2022 research presentation to the Naval Postgraduate School, “Minimum Viable Product as an Engineering Strategy for Urgent Needs Acquisition: A Case of the High Mobility Decontamination System.”

Direct user feedback and communications throughout this development cycle is critical for success.

This definition is inclusive of both hardware and software functional prototypes developed as early as possible in the development cycle. It enables iterative prototype development to add new features and agility to address new or changing requirements.

A template for using MVP in Hardware Development

Both the High Mobility Decontamination System and the Negatively Pressurized Conex followed an agile approach to hardware development as described in the diagram on Page 99. Tis hybrid approach uses an MVP strategy and feedback loops that are the centerpiece of the Software Acquisition Pathway but tailored to hardware acquisition. Tis process emphasizes direct user feedback throughout requirements analysis and prototype development. In the cases of NPC and HMDS, the programs tailored the iterative MVP approach to Urgent Capability Acquisition. A short requirements analysis phase derived performance requirements from Joint Urgent Operational Needs Statements through an engage, derive, assess and document loop with collaborative end user and combat developer involvement. These requirements led to a review with the milestone decision authority (MDA) to approve a sound acquisition strategy, sign key documents, assign funding and green light the contracting strategy.

Both the NPC and the HMDS used other transaction agreements for contracting. These agreements are prototype-centric and enable the MVP engineering approach. Because requirements will not be well defined for agile and iterative prototyping programs, the acquisition and contracting strategies must include “sprint-like” development structures. Considering the rigor involved with modifying hardware, iterations are not true sprints as used in software development that last for one to two weeks. These hardware “sprint-like” iterations may last for several weeks or even months in order to address the redesign or delivery of parts, installation of modifications, or the availability of test fixtures. Both the acquisition and contracting strategies should take these considerations into account.

Once in the iterative prototyping phase, the MVP (labeled as P(1) in the diagram) undergoes a design, develop, demonstrate and analyze feedback loop with direct user and combat developer involvement. The design and development portions of the loop should prioritize schedule over other metrics, as the goal of the MVP is to understand the utility of the capability with the least amount of effort conducted. “Demonstrate” actions include simultaneous developmental or laboratory testing and user evaluations in a test-analyze-fix-test cycle. Direct user feedback and communications throughout this development cycle is critical for success. The program managers must work with the end users and combat developers to prioritize and reprioritize requirements and feature demands based on a consistent flow of new information in the “analyze” action. Design decisions are often made on the spot to keep the test-analyze-fix-test cycle flowing.

At the completion of the development and demonstration of the MVP, the program will undergo an iteration decision process, typically executed with the MDA, program manager, user decision maker and other relevant senior leaders. Based on the information gathered during the MVP development sprint, senior leaders will make a “go/no-go” decision. A “go” decision allows the program to proceed. A “no-go” decision leads to program termination. It is important to note that decision-makers could determine a “go” decision even if the prototype does not meet benchmarks. The potential of the future iterations to meet risky, yet valuable, benchmarks will also impact the decision.

DEFINING MVP AND MVC

MINIMUM VIABLE PRODUCT (MVP)

The MVP is a prototype that provides the program office with enough information to determine if the urgent need acquisition is worthwhile as soon as possible in the product development process. It may or may not be a fielded product.

MINIMUM VIABLE CAPABILITY (MVC)

Like an MVP, the MVC is the first iteration that is ready for fielding. It enables the user to meet mission needs with the minimum amount of effort in development. The MVC is both an operational and learning tool for future iterations.

From the “go” decision, the program will address readiness for fielding as well as the desire for iterative development of another prototype. Production and fielding decisions will require analyses considering performance, production, sustainment and operational risk. The frst system that enables the user to meet mission needs is the minimum viable capability (MVC); it is both an operational and learning tool as described in my 2022 presentation. The program office will assess the need to develop future prototypes or modular features against the remaining program budget and schedule.

ATOMS VS. BYTES

Agile hardware program managers consider specialized skills like welding, electrical, engine repair, material repair, tailoring, plumbing and other skill sets when addressing hardware prototypes in “sprint-like” events.

Should the program office determine the need to develop another iteration, it will conduct a prototype design review. The contractor, program office and the user are the participants as well as other relevant stakeholders. Performance data, emerging requirements, changes to tactics and the realization of other needs will scope the next prototype iteration. The team will reevaluate and prioritize desirable features considering cost, schedule, performance and contracting requirements.

Tis cycle can repeat or end on a case-by-case basis depending on the performance, schedule and funding constraints of the acquisition.

Iteration Independence

The independence of each prototype iteration reduces risk. Tis independence requires that each iteration undergoes its own independent baseline even if the design is similar to previous iterations. Each independent iteration is evaluated on its own merits. The team can mitigate the impacts of requirements creep by reprioritizing or inserting desired features based on performance data or new insights. Design and development for riskier features can continue in an independent iteration while an operationally viable iteration goes into a fielding phase. Additionally, iteration independence enables previous iterations to serve as a fallback plan should risky performance features fail to meet user needs. By using iteration independence, the program manager can deliver operationally relevant capabilities while developing riskier features or modules in future iterations.

Conclusion

Tailoring the Software Acquisition Pathway for hardware capabilities is an effective way to get capabilities to the field fast. While the HMDS and the NPC programs demonstrated hardware development using minimum viable products for Urgent Capability Acquisitions, programs using Middle Tier of Acquisition or Major Capability Acquisition pathways could also consider this approach. Agile hardware strategies enable program managers to make rapid decisions during design, development and test while addressing requirements creep in real time. Involving the end user throughout development for feedback will help clarify ambiguities in requirements definition and improve communications throughout system testing to reduce the impacts performance issues and schedule slips. MVP and agile strategies have the potential to enable hardware programs in any acquisition pathway under the Adaptive Acquisition Framework to develop high performing and worthwhile capabilities at astonishing speeds.

For more information, email the author at joseph.e.novick.civ@ army.mil.