Fix Requirements, You Fix Costs

Fix Requirements, You Fix Costs

A panel of experienced acquisition experts told the House Armed Service Committee today that the key to fixing what many lawmakers have said is a broken acquisition system lies with the requirements process.

Anyone who has dealt with military acquisition knows that requirements become almost holy writ during a program. But the panelists noted that there are requirements — Key Performance Parameters — and then there are requirements.

The focus on requirements arose from a question put to the four witnesses by Rep. Roscoe Bartlett, the committee’s Nr. 2 Republican, about how they would weight the causes of program cost overruns. Score “requirements creep, intentional under-bidding and overly optimistic or incompetent cost estimating,” Bartlett asked them.

Here’s how they scored. Rudy de Leon, former deputy secretary of defense, said 50 percent arose from requirements creep, underbidding 25 percent and overly optimistic estimates 25 percent. David Chu, former head of the PA and E shop,

Chu said optimistic cost estimates were responsible for “more than half the problem.” Requirements issues made up a substantial portion and underbidding made up an estimated 20 percent or less of the problem.

David Berteau, an acquisition expert at the Center for Strategic and International Studies who has served on Defense Science Board acquisition studies, declined to offer a quick estimate but noted that he “would have to add disruption of the budget” to the mix, a clear reminder that congressional actions can have a major impact on program performance.

The GAO’s acquisition reform expert, Paul Francis, said requirements creep was responsible for “most” of the growth in cost.

Frustration with the requirements process was obvious. Chu said that he wanted to stop using the word “requirements” to clarify that these are goals or objectives.

“The system should think about backing away from using the term requirement, except when it really is a requirement,” he said. “Much of what we pursue is actually technological objectives, not requirements.”

Berteau said he preferred the term “real requirements.” As an example of what we could call the range of what gets called a requirement, Berteau pointed to the Air Force tanker competition. It had 35 non-negotiable requirements and 800 “negotiable requirements I would respectfully submit sir, that when you have 800 of anything they aren’t requirements.”

Francis and Berteau both thought the deputy defense secretary should possess the ultimate say on requirements, as opposed to the current set up which vests that power in the vice chairman of the Joint Chief, who runs the Joint Requirements Oversight Council.

But all this talk of reform may be irrelevant without discipline and accountability, as John Young made clear in his valedictory interview with reporters earlier this week, a factor that Rep. John McHugh, the committee’s top Republican, addressed.

“John Young recently told reporters, ‘I just do not think you can mandate a process that will ensure successful defense acquisition… The bottom line is people run programs, not documents [or] processes.’ Sec. Young went on to compare acquisition reform legislation to mandating there will be no crime. While I find that particular analogy somewhat alarming, I agree with him that, in the end, implementation of sound acquisition policies and maintaining a skilled workforce is more important than passing new reforms. Nevertheless, we continue to see poor outcomes that could have been avoided if there had been a stronger independent voice, earlier in the program and the warfighters had a clear role in establishing the requirements up front,” McHugh said.

This website uses IntenseDebate comments, but they are not currently loaded because either your browser doesn't support JavaScript, or they didn't load fast enough.

Join the Conversation

Although all elements identified are to blame, the bottom-line is that garbage in equates to garbage out when it comes to program requirements. The requirements definition phase performed during concept development is rarely performed with the disciplined and coordinated approach to tradeoffs among cost, schedule, and performance. This process also seems to be done in a vacuum, with poor program management to blame for the lack of coordination among the organizations that are part of, or should be made part of, the process.
For technology programs in the commercial sector, a strong consideration is given to changes in requirements when considered against cost, performance, or schedule. These requirements are analyzed for benefit and impact against cost, and are either modified or eliminated. This approach does not normally happen with the typical government IT or defense acquisition program, and the result is rebaselining and scope creep without the business case to support the change or a process in place to analyze the change.
Requirements need to be defined upfront, baselined, and managed. Like the title implies; fix requirements and you fix costs.

When we all realize that the “real” requirement is the defense industry’s profit making on whatever the military needs, then we will be getting to the truth.
The programs are mostly run by the contractors, not government personnel.
Just when a project is almost complete, guess what? A new “feature” is pulled out of the hat and “sold” as a new requirement to the government.
I have seen projects burn up money even when the contractors know it is not working.
The government must hire government personnel, who have the power to stop the wasteful spending without being “transferred” because they are shutting down a politically powerful project. That courage is very hard to find.

In response to Ms. Feeney’s assertion that the defense industry is the sole agent responsible for “scope creep” and adding costs to all projects is absurd. The number of projects that experience adding requirements are legion however it is usually in response to someone involved with the program that adds new “features” and capabilities after a project has been baselined. Any time you add work (just like in construction) through change orders, you will incur costs rightfully!

In my observation, most “requirements” stem from technology features that look great. Defining required “capabilities” early and frequently provider the defense community most bang for the buck by deriving requirements from operational community assessment. Consider this article by the Air Force on their approach to ISR planning and requirements. http://​www​.af​.mil/​n​e​w​s​/​s​t​o​r​y​.​a​s​p​?​s​t​o​r​y​I​D​=​1​2​3​1​4​3​770

Trying to pass cost growth off onto contractors is a easy scapegoating of the entire acquisition process. Contractors do try to get what they can from the system; but the government encourages this by overmanaging the entire process. Cost will only go down if the contractor is encouraged to pursue a “fast in, fast out” development process w/o overly stringent requirements to begin with. If the government doesn’t know what it wants to begin with, then the development cycle stretches out as the contractor and government try to define in words what they can’t conceive of intellectually. the result is longer development time and increased costs. Reduce the requirements burden and shoot for a workable product instead of trying to perfect an item on the first go-around and the result will be a lower cost item but maybe not a perfect as one would like. Remember, in many, instances, the contractor is being asked to develop something that has never existed before; if the governm,ent keeps modifying it in development to achieve perfection, the item will take forever to built, cost a fortune for what may seen as a simple device, and won’t meet all the requirements.

This, from another blog. http://​www​.g2mil​.com/​b​l​o​g​0​9​.​htm

April 12, 2009 — Tenured Program Managers

Fixing America’s broken military acquisition system is a huge challenge. An simple change that would improve the process is to create tenured program managers. This key slot is currently filled by ambitious, career-focused officers who serve just two years. As a result, they seek to please everyone and hide problems rather than address them. Program managers know little about their program when they arrive and are easily misled by contractors. They are also intimidated by retired Generals working for contractors since these Generals have close contacts with active duty Generals that sit on promotion boards.

Troubled programs like the F-22 and V-22 have seen over a dozen program managers punch their career ticket with two years heading those programs. There are several ways to change this. Appointing career DoD civilians as program managers is one option. The Generals will dislike this idea, yet legislation should exclude military program managers for consideration for promotion. Accepting an assignment as a program manager would become a career ender. This would keep ambitious career officers away, and allow program managers to serve many years until they retire.

There will be no shortage of candidates because a program manager is a prestigious and interesting assignment. In addition, many senior officers tire of the career rat race and moving their families every few years. Many Colonels would be happy to serve their last eight or so years in the same job. Of course the contractors and Generals will not like the idea of tenured program managers, however, they can’t prevent the President or Congress from implementing this common sense reform.

Chu said: “Much of what we pursue is actually technological objectives, not requirements.”

This is entirely true–but the contemporary acquisition community has no way of telling the difference! Thanks to a blizzard of lawsuits filed by everyone in the world, the acquisition boards can no longer ask for “desirable” performance. Everything has to be a hard-and-fast no-backdown carved-in-stone REQUIREMENT, or else you’ll get sued for saying that you want it.

*required

Spam Protection by WP-SpamFree

NOTE: Comments are limited to 2500 characters and spaces.

By commenting on this topic you agree to the terms and conditions of our User Agreement