Traditional requirements documentation for software-intensive military systems (e.g., command and control; intelligence, surveillance, reconnaissance, and targeting; and information operations) are insufficient, especially when the usual method of requirements decomposition and analysis takes years. The new Department of Defense (DoD) Software Acquisition Pathway, thankfully, affords most new software systems a ‘pass’ on the traditional requirements definition process (defined through the Joint Capabilities Integration and Development System), possibly accelerating this process. If their weapons are any indication, U.S. adversaries can outpace the DoD’s ability to design, develop, and field software applications. Although these new policies allow for rapid prototyping and acquisition, and software developers are extremely willing to embrace industry best practices, many DoD acquisition program offices are reluctant to change their culture.
The DoD acquisition community embraced the concepts of Lean Six Sigma and value streaming for hardware-dominant programs and projects in the 1990s, but recent publications, such as the Defense Innovations Board’s Do’s and Don’ts for Software and Software Is Never Done, indicate that software-dominant programs and projects fall short of conforming with these concepts. The new DoD Instruction 5000.87: Operation of the Software Acquisition Pathway minimally defines the role of product owner/manager, a position that many industries have institutionalized as a best practice, and on which many books are written.
Although Defense Acquisition University certifications for requirements, program management, engineering, and information systems competencies espouse ideals of product owner and user representation during the early phases of a program, the warfighter value stream responsibilities remain diffuse within a traditionally organized program office. Senior Navy requirements officers remain too far removed from software developers to accurately convey operational commanders’ values and needs in a timely manner, especially if those commanders need to address emergent or immediate changes. Requirements documents lose too much context during the requirements decomposition process.
The following are recommendations to improve the DoD software acquisition process:
1. Establish a product owner/manager training, certification, and career field within DoD and the Department of the Navy that cultivates potential product owner’s existing competencies and expands their skills, focusing on:
- Recent users and customers who know warfighting tactics, techniques, procedures, and maintenance challenges and how warfighters are trained and evaluated. These qualities are critical in determining which warfighter requirements customers will value most in proposed software solutions.
- Those who value continual learning—specifically, those who take courses and read publications that advance warfighting acumen and broaden human-machine teaming and seek to implement best practices from the Air Force’s Kessel Run experimentation lab, the NavalX centers for adaptive warfighting, and the software developers that are invited to the Advanced Naval Technology Exercises (ANTX).
- Those who are value-minded—who know what warfighters need and can convey these values in writings and diagrams to software engineers and architects.
- Those who have demonstrated innovation and creativity, and will disrupt legacy program office mind-sets to deliver customer-valued solutions.
- Critical thinking and planning that integrates sponsor requirements, warfighter “desire-ments,” and principles of software engineering.
2. Formalize a product owner/manager role in software-dominant acquisition programs. The program manager should brief the component acquisition executive if a product owner/manager with warfighting experience is not needed.
3. Expound on the product owner/manager role in future updates to DoD Software Acquisition Pathway guidance, using industry best practices. One of the goals must be to establish a repeatable process in which the product owner/manager routinely (at least quarterly) invites military operators and future system users (typical paygrades must fall between E-4 and O-3) to participate in planning and development. Too often, system details must be staffed through committees, working groups, and/or operational testers, which wastes valuable time.
The often-quoted management consultant Peter Drucker claimed organizational cultures consume new strategies and processes. Without catalyzing agents, such as a product manager who is a direct consumer of the software acquisition system, cultural change in the defense acquisitions community will continue to be slow, giving U.S. adversaries the advantage.
