Every new administration deplores the defense acquisition system it inherits and pledges to reform it aggressively. And every administration, while trying valiantly, fails. Instead, the system becomes more and more complex and lengthy. One big reason is the focus on process, not product.
The most important, yet most overlooked product in the defense acquisition system is a succinct operational requirements document. The operational requirements document, or ORD, is the foundation of the acquisition process from concept development through system development.
However, the Defense Department’s acquisition process is so overloaded with Office of the Secretary of Defense as well as Joint Staff bureaucracy, unqualified personnel, multiple reviews and councils, and duplication of the service’s requirements organizations, the ORD gets lost. That series of processes — the Joint Capabilities Integration and Development System, or JCIDS — in place since 2003, adds little value and never focuses on the ORD as the centerpiece.
In fact, the requirements document isn’t called the “requirements document” in JCIDS. As the lengthy JCIDS process proceeds at a snail’s pace, what substitutes for a requirements document goes by various names like “initial capability document,” then, the “capability development document,” then the “capability production document,” without having a clear owner for each. An end-to-end ORD just doesn’t exist in JCIDS.
[Contract protests up; contract awards down. What to do?]
Instead of the top-down, JCIDS-based requirements process, the requirements process should be bottom-up with single ownership by the service’s major operating commands throughout. Putting together and managing an airtight, bulletproof ORD should be the first priority and main focus of activity during concept development leading to milestone one. After milestone one, the ORD should stay in the forefront of every decision and remain unchanged. That is the way the system worked before JCIDS.
We need to learn from the past and get back to basics in the acquisition system starting with the requirements process. From the start of the F-15 and F-16 programs in the early 70s through the F-22 start in the late 80s, concept development began with small, smart teams working together from the operating and developing commands; understanding the need; conducting trade-off analyses to assess risk and cost, in continuous dialogue, producing a requirements document unfettered by top-down micromanagement or wall-to-wall reviews and nitpicking.
The teams were manned by smart operators from the major operating command, who understood the capability needed, and by technical experts from the development command, who understood the state of the art and the risk to go beyond it. They worked in harmony in horizontal dialogue, not having to go through vertical chains of command to communicate with each other, as is the case today. Nor did the Pentagon interfere.
This process worked to produce remarkably well-constructed ORDs in less than a year in most cases. The ORD, approved by the operating and development command, went directly to the service chief and secretary for validation, then to the Joint Requirements Oversight Council, which made sure it included joint service support.
Typically, the work in the Pentagon took less than six months to validate the requirement and put it on the street to industry. The key was the work done by the small teams, freed from bureaucratic tyranny and micromanagement by non-experts.
The ORD served as the main product and basis for the system specification, request for proposals and the source selection process. It kept discipline in the acquisition system throughout all pre-full-scale development milestones.
However, building small, smart teams is essential but difficult. Experience and expertise are prerequisites. Experts in development command teams must know technical and cost risks, and have a working knowledge of operational matters. Experts in the operational command teams must know threats and concepts of operations, and a working knowledge of acquisition matters. But, these experts must be trained and educated for their roles.
Today, particularly in the major operating commands, the officers defining requirements are good operators but not expert in the requirements business. To make matters worse, the responsibility for defining requirements has been subordinated in many operational commands under the plans and programming functions.
Many things need fixing in the defense acquisition system. Reform should start with eliminating JCIDS and returning to what worked — making the ORD the foundational document and driving force in acquisition programs created by small, smart teams from the responsible commands in the services The result will be an acquisition cycle that is years shorter than JCIDS, and systems that meet needed capabilities on cost and schedule.
