MTA Rapid Prototyping programs, by law, are supposed to deliver “leave behind” capabilities to the user by year 5. Taking 10 years on average means some serious over promises and underdelivering is going on. That’s not a “little fire”, that’s 100% program management and engineering incompetence and malpractice.
MTA program strategies do outline the capabilities they'll leave behind as part of rapid prototyping. That is different from an IOC measure for MDAPs. The "10 year average" was for 5 programs GAO selected among the 106 MTA programs. Likely the five programs with the longest timelines. One should definitely examine why it will take 14 years to re-engine the 70 year old B-52s. Page 70 offers some insight. If PTS and FLRAA were done completely in the MCA pathway, they would likely have taken them more than the 10-12 years to achieve IOC. There are definitely opportunities to streamline DoD processes and properly scope programs to rapidly prototype and produce capabilities via the MTA pathway. One should also look across the Pentagon and Congress as to delays to include budget and compliance, not simply slander the PMOs.
It's hard to tell which programs GAO selected. Nevertheless, a 10 year average is not a good time frame for an acquisition pathway that is supposed to be rapid, within 5 years for rapid prototyping with leave behind, or 5 years to fulfill production quantity for rapid fielding. I've seen all too often that rather than mature a new technology for insertion - one of the initial purposes of rapid prototyping - many brand new ACAT I level MDAPs are initiated as "rapid prototyping". That creates a lot of risk and some unrealistic expectations at program initiation. MTA rapid prototyping and rapid fielding are a great pathways for acquisition, but need to be applied properly, and based on what I see since 2016, and in the GAO report, some better due diligence and acquisition planning (and tailoring) before utilizing these pathways is required.
And for sure, Congress and the Pentagon need to be aligned with budgetary and oversight processes that align with agility and rapid delivery of capability. Creating a permanent Software appropriation to fund the software development pathway, instead of typical RDT&E and Procurement, is just one example.
Lastly, I put the engineering and program management accountability on industry, as much as or more so than government program offices; I did not intend to focus on one side of the acquisition provider enterprise.
The GAO noted 4 programs with 10+ years to IOC. That is <5% of MTA programs. So a 10- year average is misleading. The benefit of rapid prototyping is to explore working solutions to shape scope, designs, and more. Not simply 2 years of JCIDS and AoA, and 2-years of developing RFP and source selections based on paper proposals.
GAO must do better with stats. That’s some bad cherry picking there.
Concur that rapid prototyping is about exploring proofs of concept and shaping solutions.
And as much about finding out what does not work for a capability solution, stop, and move to other options that might work. Iterate the solution space, until one satisfies the military need, and stop throwing good $$ after bad solutions.
MTA Rapid Prototyping programs, by law, are supposed to deliver “leave behind” capabilities to the user by year 5. Taking 10 years on average means some serious over promises and underdelivering is going on. That’s not a “little fire”, that’s 100% program management and engineering incompetence and malpractice.
MTA program strategies do outline the capabilities they'll leave behind as part of rapid prototyping. That is different from an IOC measure for MDAPs. The "10 year average" was for 5 programs GAO selected among the 106 MTA programs. Likely the five programs with the longest timelines. One should definitely examine why it will take 14 years to re-engine the 70 year old B-52s. Page 70 offers some insight. If PTS and FLRAA were done completely in the MCA pathway, they would likely have taken them more than the 10-12 years to achieve IOC. There are definitely opportunities to streamline DoD processes and properly scope programs to rapidly prototype and produce capabilities via the MTA pathway. One should also look across the Pentagon and Congress as to delays to include budget and compliance, not simply slander the PMOs.
It's hard to tell which programs GAO selected. Nevertheless, a 10 year average is not a good time frame for an acquisition pathway that is supposed to be rapid, within 5 years for rapid prototyping with leave behind, or 5 years to fulfill production quantity for rapid fielding. I've seen all too often that rather than mature a new technology for insertion - one of the initial purposes of rapid prototyping - many brand new ACAT I level MDAPs are initiated as "rapid prototyping". That creates a lot of risk and some unrealistic expectations at program initiation. MTA rapid prototyping and rapid fielding are a great pathways for acquisition, but need to be applied properly, and based on what I see since 2016, and in the GAO report, some better due diligence and acquisition planning (and tailoring) before utilizing these pathways is required.
And for sure, Congress and the Pentagon need to be aligned with budgetary and oversight processes that align with agility and rapid delivery of capability. Creating a permanent Software appropriation to fund the software development pathway, instead of typical RDT&E and Procurement, is just one example.
Lastly, I put the engineering and program management accountability on industry, as much as or more so than government program offices; I did not intend to focus on one side of the acquisition provider enterprise.
I appreciate the discussion. Thanks.
The GAO noted 4 programs with 10+ years to IOC. That is <5% of MTA programs. So a 10- year average is misleading. The benefit of rapid prototyping is to explore working solutions to shape scope, designs, and more. Not simply 2 years of JCIDS and AoA, and 2-years of developing RFP and source selections based on paper proposals.
GAO must do better with stats. That’s some bad cherry picking there.
Concur that rapid prototyping is about exploring proofs of concept and shaping solutions.
And as much about finding out what does not work for a capability solution, stop, and move to other options that might work. Iterate the solution space, until one satisfies the military need, and stop throwing good $$ after bad solutions.