Programs executing the software acquisition pathway are not subject to the Joint Capabilities Integration and Development System (JCIDS), and will be handled as specifically provided for by the Vice Chairman of the Joint Chiefs of Staff, in consultation with Under Secretary of Defense for Acquisition and Sustainment (USD(A&S)) and each service acquisition executive…
Programs using the software acquisition pathway will demonstrate the viability and effectiveness of capabilities for operational use not later than 1 year after the date on which funds are first obligated to develop the new software capability. New capabilities will be delivered to operations at least annually to iteratively meet requirements, but more frequent updates and deliveries are encouraged where practical…
Programs will require government and contractor software teams to use modern iterative software development methodologies (e.g., agile or lean), modern tools and techniques (e.g., development, security, and operations (DevSecOps)), and human-centered design processes to iteratively deliver software to meet the users’ priority needs.
That was DOD Instruction 5000.87, OPERATION OF THE SOFTWARE ACQUISITION PATHWAY, released on Oct 2, 2020. It’s a good bit different than the interim software pathway released earlier in the year. It represents one of six acquisition pathways in a revamped DoDI 5000.02, and includes 14 or more functional policies. I’d like to give this a really thorough read and update you with a fuller analysis. A couple things that jump out real quick:
(1) Value assessments done at least annually, which is intended I believe to be a criteria for oversight and reporting that is largely in lieu of traditional MDAP fixation on metrics found in the Defense Acquisition Executive Summary like performance to APB. This is very commendable, I’d love to see it in action. But ultimately, some requirement statement and a lifecycle cost estimate (which are waterfall concepts) keeps traditional types of information in place. GAO or other orgs will use that as part of their original framework of oversight.
(2) The Component/Service Acquisition Executive basically has to sign off on every program in the Software Pathway as the Decision Authority (DA). That individual is pretty high up the chain. I assume the DA can delegate its role to the PEO or even PM given the size of the program, but then again the DA is not the same thing as a Milestone Decision Authority, so those rules may not apply. I’d be interested to hear how that will work. The policy says “DAs are responsible for providing required program data to the USD(A&S).” So DA might have to be pretty involved. At any rate, software can only be as agile/modular as the organization. I think the trend will continue to be toward large programs to make major muscle movements with the cost estimate, IP plan, etc., but will ultimately do what ABMS and Skyborg are doing, which is release a number of smaller/modular/competitive contracts underneath the relatively large/fixed defense program.
Leave a Reply