How a program is structured is critical to determining when capabilities can be delivered to users. After decades of attempting to build exquisite large complex systems via a single “big bang” approach with limited success, agencies have embraced more iterative, spiral, and Agile development with greater success. Breaking the scope of work into multiple smaller releases enables organizations to be responsive to changes in operations, risks, budgets, priorities, contractors, technology, and more.
A program’s acquisition strategy must assess the environmental factors and structure development, integration, and delivery accordingly. A major weapon system that delivers all of its planned capabilities after 10–15 years will not satisfy its customers as much as a system that delivers 60 percent of its capabilities in 6–8 years, with the program office involving the customer in iterative deliveries thereafter. This principle holds true for acquisitions from small software programs to large aircraft systems.
The GAO reported in 2003 that the Air Force’s F-22 fighter would have been more successful and less costly if it was developed via three evolutionary steps vice a single 22-year program.
The National Defense Strategy published in Jan 2018 stresses iterative development:
“Streamline rapid, iterative approaches from development to fielding. A rapid, iterative approach to capability development will reduce costs, technological obsolescence, and acquisition risk. The Department will realign the incentive and reporting structure to increase speed of delivery, enable design tradeoffs in the requirements process, expand the role of warfighters and intelligence analysts throughout the acquisitions process, and utilize non-traditional suppliers. Prototyping and experimentation should be used prior to defining requirements and commercial off-the-shelf systems. Platform electronics and software must be designed for routine replacement instead of static configurations that last more than a decade. This approach, a major departure from previous practices and culture, will allow the Department to more quickly respond to changes in the security environment and make it harder for competitors to offset our systems.”
DODD 5000.01 states:
“Advanced technology shall be integrated into producible systems and deployed in the shortest time practicable. Approved, time-phased capability needs matched with available technology and resources enable evolutionary acquisition strategies. Evolutionary acquisition strategies are the preferred approach to satisfying operational needs. Incremental development is the preferred process for executing such strategies.”
The Federal Information Technology Acquisition Reform Act (FITARA) stresses incremental development to include:
“for development of software or services, planned and actual delivery of new or modified technical functionality to users occurs at least every six months.”
MITRE published an Authority, Autonomy, and Accountability paper in Jun 2017 that proposes:
“A bias toward evolutionary development mitigates against over-engineered solutions, requirements creep, and premature technology insertion. Over time, with quick learning, rapid course corrections, and more opportunities to insert evolving technology, a series of incremental projects fulfills the overall portfolio mission needs by following a step-wise path, instead of attempting large and risky episodic jumps in capability.”
US Navy's Polaris Program
Stephen Denning’s The Leader’s Guide to Radical Management includes an interesting Navy story on accelerating capabilities from the 1950s/60s.
Iterative thinking was also used in the U.S. Navy to build submarines. In October 1957, Vice Admiral Levering Smith had recently been appointed technical director of the new Polaris program, which was aimed at developing submarines that could launch missiles when submerged. The first Polaris submarine was scheduled to be operational eight years later, in 1965. That was already an ambitious target, as the Polaris program required the development of nine new technologies.
Two weeks after Sputnik I was launched, the deadline for completing the Polaris program was moved up from 1965 to 1959. What was already a very difficult goal had suddenly turned into mission impossible. So Smith decided to approach the task iteratively.
Instead of creating the ultimate system in nine years, he set about creating a progression of systems: A1, A2, and A3. The A1 version would contain whatever technology could be deployed in three years. The A2 version would be developed in parallel but proceed more slowly to allow it to use more desirable technologies. The A3 version would incorporate everything learned in the development of the earlier versions.
On June 9, 1959, the first Polaris missile was launched from a submarine. By the end of 1960, two Polaris submarines were patrolling at sea. Unlike many other defense systems, the missile performed as promised. There was never a hint of a cost overrun. The key to success is delivering value to clients at the end of each iteration.
Actions You Can Take
- Structure: A program in the early stages should plan to structure the delivery of systems or services of the full envisioned scope in multiple iterations.
- Requirements: There should be flexibility in requirements documents to allow for iterative deliveries without having to meet the full set of performance requirements envisioned for the complete solution.
- Collaborate: Discussions with users, development/integration contractors, engineers, enterprise architects, testers, and other stakeholders should seek to understand the potential constraints and tradespace in determining iterative breakpoints based on major groupings of scope or a repeatable timeline (e.g. annual deliveries).
- Dependencies: Identify dependencies with external programs and discuss with stakeholders the required functionality, interfaces/integration, and timelines.
- Strategies: Acquisition, contracting, engineering, and testing strategies should reflect the iterative structure to include the processes, resources, and decisions needed to field each release.
0 Comments