The global aerospace and defense (A&D) industry can produce astonishingly advanced airplanes and other complex equipment, but it routinely fails to develop those programs on time, on budget, and in line with projected performance. The problem is not new, but it is getting worse and now constitutes a full-fledged crisis of execution. We believe the solution is to focus less on capabilities and technical complexity and more on program speed—locking in a delivery date as a fixed entering argument and then designing other parameters around that goal.
That was from a Boston Consulting Group paper: A Need for Speed in Aerospace and Defense. (HT: Sean) I think those conclusions are what a lot of acquisition reform has been about. It flips the traditional, industrial era paradigm. Rather than fix requirements too early and then estimating the lifecycle cost/schedule to get there, improved methods fix cost/schedule increments and allow requirements to flex within those parameters, with iteration built in over time.
Below, the authors provide a table indicating how program schedules have grown, particularly since the end of the Cold War. In my estimation, this table is sloppy. First, programs like the C-17 entered into service in 1995, but actually started in 1980 making it clearly a Cold War program. Same with the DDG-51 Burkes.
Another issue is that what it means to “start” and “enter service” differs by program and has changed over time. There was no background on how they arrived at these figures. For example, the F-18 program actually started in 1975, so if it entered service in 1983 that’s an 8 year timeline, not 5 years. The F-18’s first flight was 1978, so that time is from first flight to IOC. But the F-18 was also derived from the YF-17 prototype developed in 1972. So the full timeline is closer to 11 years for the F-18.
Compare that to their measure for the F-35 which they cite as a 20 year timeline from 1995 to 2015. Well, 1995 was the start of the JSF prototyping phase. It entered full-scale development in 2002, first flew in 2007, and then entered service 2015. So if you took F-35 from first flight to IOC as they did for the F-18, its timeline drops to just 8 years. (Another note, I would actually use Aug. 2016 for IOC of F-35A, rather than IOC for the F-35B the previous year.)
I don’t want to belabor the point, but the C-5A is quoted as 4 year timeline, but it had severe deficiencies and had to be rewinged starting in 1972. This chart is also selective, excluding F-111, F-14, F-15, F-117, amphibs, the LCS, and other major programs.
My general point is that the Cold War isn’t the real marker of change in development times. It is actually the introduction of the PPBE in 1961, which didn’t solidify until the early 1970s. But in that time, you had “PPBE-style” programs like the F-111 and the C-5A that performed abysmally, and then you had “irregular” programs like the F-16, F-18, A-10, F-117 that did not abide by those rules. And systems like the F-105 and F-4 were pre-PPBE.
Anyway, sloppy analysis of timelines but ultimately I agree with their conclusions on managing developments. Here’s a good quote:
Even as other industries have shifted to agile product development, the A&D industry still relies primarily on traditional methodologies built around a series of milestones that must be achieved in order to advance development. This waterfall timeline is an outcome of decisions made early in a program’s development—many of which have unclear implications on the time to market.
And here are other principles: Focus on incremental advances; Rely more on established technology; Shift to an agile development approach; Digitize the design process; Rotate talent; Streamline supply chains.
I’ll leave you with an interesting chart on commercial aircraft outsourcing over time, which seems to correspond to similar trends in DoD programs:
In a sense, the success of agile methods (and the need for them!) is a scathing indictment not of the acquisition process, but of the requirements generation process. Agile goes faster because it avoids doing work that wasn’t necessary. Iterative / evolutionary acquisition doesn’t get you to useful capability any faster unless you were wrong up front about what the real threshold capabilities are.
I suspect it would be more useful, in both the short and long terms, to reform the requirements process. However, the Services have a lock on that, and Congress won’t touch it. It’s so much easier to yell at the people who are told to implement the requirements overreach.
Yes definitely, would love to see folks tie off efforts within a requirements stream and reallocate that. But requirements and funding are often tied to specific implementations, so even if the requirement is met in a better or more cost-effective way, it still has to go through the gauntlet of a new start or new program. I think that’s the way congress and oversight wants it, so that’s why we’re seeing the backlash to MTAs.