It seems clear that the reciprocity of innovation and requirement is unusually important during the period when demonstrations of feasibility are being attempted. The character of an innovation ordinarily influences the form of the “requirement” that authorized further development, but it does not appear that a statement of requirement influences the course of innovation unless the “requirement” has first been reshaped to reflect the technological implications of the innovation.
Within the limits imposed by knowledge (the state of the art constraint), a statement of requirement can induce performance improvements – as witness the remarkable advances in conventional propulsion and aerodynamics during the Second World War. But until a demonstration of capability has been carried through, there seems to be no way of anticipating the prospective applications of something essentially novel.
A requirements statement specifying product characteristics rather than performance goals tends to have slight applicability to devices that qualify as innovations. There probably are exceptions, but as a general rule it may be assumed that the ordinary military requirement is not likely to be satisfied if it calls out innovative technology still to be demonstrated.
In each of the examples treated here, the “concept” or “invention” stage of the innovative process occurred outside the main stream of aerodynamics and propulsion. The inventors usually had no clear perception of prospective applications. Whittle and Ohain were interested in the jet engine of itself rather than in its ultimate use.
That was the excellent Robert Perry, “Innovation and Military Requirements: A Comparative Study.” August 1967, RAND, RM-5182-PR. The reciprocity of requirements and technology was rediscovered by commercial startups and has led to tremendous progress — at least in software. But the principles have been understood for many decades and equally apply to complex hardware. The DoD simply cast out agile development after World War II when it sought to “perfect” innovation through immaculate planning. The ideology that one can be “certain” about uncertainty, and that enough third-party experts can verify the optimal specification, was brought to its peak by Robert McNamara in 1961. That ideology is still with us and is embodied in the Planning-Programming-Budgeting-Execution System.
I would phrase this very differently, Eric. The goal was to remove innovation from _purchasing_, and keep it in S&T and R&D where it belongs. If you are still innovating after you have committed to purchasing *that* particular system from *that* particular vendor, you have made a mistake and you are going to pay through the nose for it — if you don’t end up quitting with nothing.
The institutional problem is that there’s a lot more money in procurement* than in R&D. That creates systemic incentives for programs to get to the point where they are guaranteed procurement money as quickly as possible.
At the same time, annual budget crunches favor O&S over procurement, and procurement over development, and development over reasearch, because it’s easier to slow down research than it is to slow down SDD, and easier to slow SDD than to slow procurement of a program that is already at its minimum sustaining rate, and easier to slow procurement than to stop maintaining and operating the systems we already have.
*I include SDD funds in “procurement”; they are earmarked funds to buy a specific system, whose design should already be mature enough that no actual R&D is still happening. One of the reasons innovation is underfunded is that the bean counters mistakenly think SDD is R&D.
Well that is the central question, and was very much disagreed upon by the co-authors Economics of Defense in the Nuclear Age, which founded the modern PPBS. Hitch thought SDD was basically like procurement and should be controlled the same. McKean thought SDD was more part of R&D and should be allowed competition and innovation.
I am 100% with McKean on that, and history seems to prove that you cannot pretend that SDD is procurement. I can rattle off all the usual program suspects that demonstrate the fact.
I think we should take a humble approach to our knowledge, be able to start things and iterate without precise definitions, always with alternatives, always interacting with hundreds of users, and trust skilled and creative people to do what we pay them for: be professionals. As Rickover said, a person is not a professional if they are to be dictated a technical course of action.