A major part of the military’s struggle to keep up with, much less stay ahead of, global and technological change lies in its requirements process — the starting point of the acquisition process and, essentially, how the Pentagon figures out what to provide its forces. This approach to major system requirements (known as the Joint Capabilities Integration Development System, or JCIDS) is inward-looking and slow. A 2011 report on the Army, for example, revealed it takes on average 15-22 months to get requirements approved. The Pentagon usually thinks it knows what it needs, and it has no problem taking a long time detailing all the ins and outs of what it wants to buy…
Under the JCIDS process, the Defense Department typically predetermines the solution it seeks, spending far too little time analyzing and truly understanding the problem and the full range of ways to solve it. The requirements process winnows competitive proposals from industry down to only those that align with the solution the department opted to pursue, potentially years before ever initiating a competition. Official guidance states that Milestone A (a critical early stage in the acquisition process, also called the Risk Reduction Decision) is an “investment decision to pursue specific product or design concepts.” In other words, by this early stage, the crucial decision has already been made about the nature of the solution.
That was from Jarrett Lane and Michelle Johnson from the Section 809 Panel. They make some good points. However, the origins of the JCIDS requirements process was not Packard’s 5000.01 as Lane and Johnson suggested.
 |
| JCIDS process chart from DAU. Lane and Johnson called the JCIDS “Joint Cutting-edge Ideas Death Sentence”. |
The program milestone acquisition process that Packard implemented was basically a rebranding of McNamara’s innovation process with “three key decision points” created by DODI 3200.6 dated June 7, 1962. For all the talk of purging McNamara’s systems analysis “whiz kids”, it is evident that systems analysis was firmly established in the DOD. That is because Laird and Packard never reformed the other side of the coin, the program budget.
The PPBS reflects the twin ideas of systems analysis and program budgeting. It is the super-structure that organizes the flow of funds. The PPBS concept necessitates the requirements process because it intends to relate all program funding to a single strategic plan. For the strategic plan to be coherent, it’s requirements must determine the optimal program specifications. Otherwise, an anarchy of competing plans would lead to duplication, waste, and an unbalanced force structure.
 |
| SecDef Robert McNamara instituted the PPBS in 1961 which has yet to be reformed. The PPBS is a top-down decision-making process which necessitates a “requirements pull” approach. It rejects “technology push”. |
At its core, the PPBS rejects empiricism. Technical specifications are deduced from natural laws and military requirements. It does not allow for trial-and-error discovery in engineering solutions. E.S. Quade said of systems analysis:
The situation is not like an empirical science, which starts with observed facts, but more like that of mathematics, where the results take any ‘validity’ they might have in the real world from the assumptions… it is important that the assumptions be the ‘right’ assumptions.
Any observer who sees benefits in “technology push” techniques will find problems with the PPBS and its attendant “requirement pull” processes. The trick is designing a system where you get an interaction of these top-down and bottom-up processes.
Programs cannot be a tightly controlled plan of future action (because the technology is not yet known). Budgets should be appropriated to operating organizations, who should do their best to account for expenditures by programs to aid in accountability after-the-fact.
The Section 809 Panel report wants to create an “outcomes-focused system.” Well, that was the exact purpose of the PPBS, organizing control of funds and administration through program classifications as opposed to by organization/object. The DOD needs to be a people-focused system; the technology will follow.
Perhaps the best critique of the requirements process I’ve seen was from the Army Requirements & Concepts Panel for the AMARC in 1974:
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 lose 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.
The Army showed an appreciation for nonlinear development processes reflected in the Agile fad today. Ultimately, the biggest obstacle to achieving technology transition is not the requirements process itself. It is the PPBS which locks in top-down decision-making communicated through requirements.
Leave a Reply