The Department of Defense separates the procurement of materiel (“Acquisition”) from the use of materiel (e.g., Combat, Logistics).
- The End User owns the Operational Requirements, but has no contractual relationship with the Developer.
- The Acquisition Customer is charged with “translating” the Operational Requirements into contractually obligated Technical Requirements for use by the Developer.
The basic rationale for the split is that it permits specialists to develop their skills in the tools and techniques associated with procurement in accordance with the Federal Acquisition Regulations.
The downside to this concept is that it creates a slow-moving buffer between the Developer and the End User, which can impede the usefulness and timeliness of designs reaching the field. The upside is that it tends to “damp out” some of the developmental whiplash as late-coming End Users try to inflict their opinions (possibly not wrong, always strongly held) on the design.
It is interesting to note that our Commercial Transport aircraft development can also have a type of “acquisition customer”, when the aircraft are purchase by a leasing company. Because they can be very large customers, they can carry tremendous weight in establishing many kinds of development requirements for our commercial aircraft.