Are better requirements the answer to acquisition?

Here are some excellent insights from the Army Materiel Acquisition Review Committee’s 1974 report. Might sound like a lot of the arguments going on today in favor of JUONS and rapid acquisition pathways (which still takes a bureaucratic maze to get the approvals for, and doesn’t exempt you from many other regulations):

The theory is that the user can specify what his needs are and the developing agency can respond to this document by developing the required equipment in a straightforward and expeditious fashion in accordance with approved procedures… The concept is unworkable when a new class or type of equipment is to be developed and acquired.

 

In the opinion of our team, historically the most successful developments [of new weapons, not evolved] or the most useful operational equipment have not resulted from the “‘requirements” process, while building and trying equipment in response to a good idea has a much higher batting average –particularly if normalized to resources expended. Significant examples can be cited where the establishment actively resisted the introduction of a materiel system (Jeep, Christie Tank, P-51 Fighter Aircraft, SIDEWINDER and the previously mentioned US Army rifles).

 

The diligent reader will have observed that we place great reliance on the in-house laboratories in generating and demonstrating new ideas. Having an “in-house” view we are painfully aware that the incentives to the laboratories are to not “rock the boat” or otherwise exacerbate the situation. We believe that the only way that the laboratories are going to produce is by the (possibly painful) application of the competitive pressures.

 

A fundamental truth is that comparative tests are the only judge. We must test our new ideas and equipment in the presence of what is available now or what could be accomplished by others. This may frequently be painful.

 

We are solidly in favor of competitive prototyping, both for ideas, concepts and experimental equipment, as well as during engineering development.

 

The professional military officer has been thoroughly trained to try to bring order out of chaos. The R&D process is by nature disorderly and attempts to regularize and institutionalize it will usually stifle it. We are in hopes that the suggestions given will bring some order without repressing the process.

 

[Recommendations:] (1) R&D effort in the 6.2, 6. 3A and 6. 3B categories should be accomplished with low-level programs, full realization of technical risks, and no management promises. (2) Developer should build it and try it and let the user I try it and see if he likes it.

 

The preceding issue concluded that the firm requirement should not occur until entry into the Full Scale Development Phase (6.4).

 

Our team believes that in one sense there is no such thing as a ‘requirement.” The concept that a description of the end product can be made at the front end of a development program may be responsible for more useless and expensive equipment being acquired than all other causes combined…. If the word “requirement” causes managers to loose [sic] sight of the objective of providing operationally useful equipment to the Army, then it should be dropped from the Army’s lexicon…

 

The user’s inability to describe his needs is no condemnation. He has learning curves also, but his learning experience supports, depends on and intersects with the materiel developers’ learning experiences; therefore, the roles of these two agencies must be mutually supporting.

There were a lot of insights there. First is the validity of a technology-push approach to complement the requirements-pull, particularly in highly uncertain environments. Second, the need to avoid the travails of getting a program line item into the budget associated with S&T projects — at least until the start of full-scale development (though I would say, all of RDT&E is a “search” of the unknown and benefits from increased programmatic optionality). Third, a strong in-house technical staff is critical for the government to make good choices, and that competitive pressure evaluated by operational tests will keep government in-house offices effective (and the same goes for contractors as well).

Be the first to comment

Leave a Reply