Technology and threats are both evolving very rapidly. Our own acquisition system too often undermines our ability to get the warfighter what he or she needs to meet and counter those threats. Generating and validating requirements, budgeting for funds, and contracting can each take two or more years, even before major acquisition programs are initiated. After major acquisition programs begin, it takes 8 to 9 years on average before systems are developed and deployed to warfighters. We cannot have an agile system if it takes us years to figure out what we want, how to fund it, who to hire even before development begins.
That was Mac Thornberry in a 2016 hearing, Acquisition Reform: Experimentation and Agility. What he’s saying is that if the services were to have an idea for a new weapon system in 2007 — the year the first iPhone become available — the “average” program would only start entering operations today in 2019.
What is the optimal lead-time to the authorization to proceed on a development project? Is it a year? Some months, or perhaps a few minutes?
Presumably, the lead-time should depend on the size of the work committed to and how complexity of the integration attempted. For small projects that are relatively compartmentalized, decisions should be quick. The Air Force has been touting how fast it is getting these small awards out on things like Pitch Day. But it does not use this method for initiating major defense programs. For large projects with complex integration, more lead time is required. Perhaps even three years or more is appropriate.
The thing is that fast-paced incremental decisions should, along the way, be building a case for the next logical step. The smaller projects, if successful, can “snowball” into larger and larger projects, having built up a compelling case along the way. These evolving programs cannot proceed unless they have a demonstrated case, and put effort toward a coherent financial plan.
If we think of these actions across a wide range of component and platform types, then an “agile” process is possible. There will be a range of fully developed components which can be recombined rapidly. The ease with which components can be swapped and deployed to users will affect the timescale of agile developments. But in either case, the 12 or so years between justifying funds and initial operational capability is too long.
The dirty secret that nobody wants to talk about is that this is a self-inflicted wound. Permission to begin a major acquisition program is politically expensive, so the Services try to pack as much content as possible (including the outright impossible) into each new program. That’s why it takes so long — the technology is immature and the requirements list is long. If you want more agile acquisition, the only proven method is to ask for less in each program.
Alternatively, you could take Modular Open Architecture seriously, and make your 12-year platform program easy to upgrade and improve. We never do that, either, because modularity and openness (and the necessary data rights) are traded away as soon as cost and schedule growth hit.
“Permission to begin a major acquisition program is politically expensive…”
That is certainly correct. But I don’t know if it is a dirty little secret. The rigamarole is well known and in some cases praised for being an exemplary application of oversight. If officials didn’t ask questions and provide obstacles, they would feel inexpert and superfluous.
This reminds me, by the way, of Adam Therier’s book on Permissionless Innovation, and how Mike Munger agreed in an EconTalk podcast that permissionless innovation is perhaps the most important concept in political economy. I agree. We need to look more to the upside of action rather than the downside.
And with a more modular approach, saying “yes” shouldn’t also mean laying aside billions over decades. Decisions should be more incremental, as perhaps should integration of complete weapon systems. Not of giant SDD contract, but several over time, always maintaining options.
I was focusing more on the fact that schedule (like cost) is a straightforward function of content. There is something in the water that makes people think acquisition is slow because of red tape; that’s nonsense. Every study ever done has concluded that acquisition is slow because of technical issues, usually related to immature technology and inadequate testing. Packard knew that, and it hasn’t changed since.
…Which is not to say that there isn’t a ton of zero-value-added administrative crap in our current process. It just isn’t on the critical path.
I think the administrative work is on the critical path for selecting new projects and iterating the requirements of existing projects. And that certainly impacts the actions taken to address technical content.
Agreed — but the administrative work that is on the critical path is not the red tape that the Services and contractors complain about. The reporting and oversight and JCIDS artifacts aren’t causing long delays — it’s the internal staffing within the Services, and the multiple stakeholders all wanting a say, and so forth. None of the recent spate of acquisition reform has done anything to help with that problem.
Yep, just ridding yourself of the JCIDS or 5000.01 processes will not necessarily reduce the layered decision-making throughout the Department.