We’ve been reviewing the four themes outlined in the bipartisan report, Defense Acquisition Reform: Where Do We Go From Here? A Compendium of Views by Leading Experts, including incentivization of the acquisition workforce, and attracting and training a qualified acquisition workforce.
Theme #3: Realism in program requirements and budgets
Requirements have always been the key to avoiding extra costs and delays. But getting good requirements up front has never been easy. And with limited budgets and limited money to spend, and certainly staffing that’s been reduced over time, it’s been a constant problem that can only get worse.
The fact that this was included as one of the key factors in acquisition reform points out the issue, but without making it easy to figure out the solution.
Ultimately, we need to balance getting better, more precise requirements against not specifying a solution that thereby constrains industry ingenuity and innovation on the other end.
We want the government to give their industry partners the opportunity to be innovative, but to also be able to specify a solution that is at least close to what the government thinks is going to be workable, and that will fit within their budgetary restraints.
Here is an example of this issue in action: The government has something they want to do, e.g., build a tank. You have a certain amount of functional activity you know the tank is supposed to do, i.e., it has to carry ammunition and troops. But then there are other questions to answer:
How fast does it need to go? How long does it need to drive for in order to get from where it starts to the battlefield, and how much does it have to do after it arrives? How many rounds of ammunition should it carry? What does its crew need to do? Can it go on roads? Does it need to have a certain center of gravity to not destroy the road? What about electronic counter-measures and safety for the crew, and armor sizing?
So you see that while conceptually what I wanted was a tank, now I’ve identified many more details. Yet I don’t necessarily want to tell the people bidding how to do everything, because I’d like some innovation and improvement to come in from their bid.
The more requirements I specify, the more I’m droning down into one constrained solution, because I’ve told people so much of what I want. The less I specify requirements, the more likely they are to have a range of solutions, but thereby a range of costs and a range of capabilities that they’re delivering against that more loose set of requirements. I might end up in a tank with a gun that shoots left, which might not be so good.
More specific requirements are also more costly to generate, because they need to be developed in precision. There’s a joke in the acquisition community about $1,000 wrenches. A wrench may only cost $12.99 at your local hardware store, but if you’ve over-specified in your requirements, the only way to build it to those specs will be with costly and foolish materials. Meanwhile, the $12.99 wrench would have been just fine. Maybe not perfect, but okay.
We have to have requirements at some level, and we have to understand that the more specific the requirements, the less diverse solutions we’re going to get.
