Evolutionary Acquisition: breaking the mold—new possibilities from a changed perspective - The Acquisition Process

Program Manager, May-June, 2002 by Alexander R. Slate

I began this article to help explain Evolutionary Acquisition (EA) to the people with whom I work--many of whom were asking questions. Over the course of writing it, the purpose of EA became increasingly clear. Armed with increased knowledge of EA and its potential for application DoD-wide, I began to discuss some particular aspects of how EA can and should work to the advantage of the acquisition, technology, and logistics workforce. And I began to see how EA could ultimately work to the advantage of the men and women of our Armed Forces--the warfighters and end users for whom we acquire systems. Presented here are my particular opinions--not Air Force or DoD policy--about how we can do our jobs better.

Why EA is So Attractive

EA is really nothing new. Those involved In software development have been using a process called spiral development for a number of years. Another analog of the EA concept is Pre-Planned Product Improvement (P31).

However, I would only go so far in comparing P3I to the current concept of EA. The differences lie In the application; the fact is that as we approach EA, we are willing to be a little more revolutionary in breaking the mold to acquire systems for the U.S. Air Force (USAF) and the Department of Defense (DoD).

P3I

P3I programs worked like this. Within USAF, we would have a systems requirements document--nowadays we call them ORDs (Operational Requirements Documents). The ORD would give us the user's desired end state. In the real bad old days, these simply came as a singularized set of requirements: now we at least have thresholds and objectives.

Sometimes requirements were not achievable. For many reasons we couldn't always give users exactly what they wanted. Let's ignore things like not having enough money and contradictory requirements and concentrate on available technology. Sometimes, the state-of-the-art just wasn't there, but in time perhaps technology could eventually get us there. So, we would plan and proceed with our acquisition programs.

In addition to planning the immediate acquisition, we would also do one or both of two things. The first course of action would be to follow the state-of-the-art and Insert capabilities into the program as soon as they were ready during the initial procurement. The second course of action would be to field capabilities according to the state-of-the-art at the end of the procurement and "fix" the item with up-to-date technology after the fact. In either case, the initial procurement would be a full-scale program, normally taking anywhere from three to five years to complete.

EA should differ from P3I in that our understanding of requirements needs to change. User and acquisition personnel need to cooperate much more closely, and to begin that cooperation earlier in the process. Also, both users and acquisition personnel need to redefine what we mean by requirements. Requirements are no longer simply technical needs. Think CAIV, or Cost As an Independent Variable (even though I dislike that particular term in this context). Both schedule and cost are also requirements.

The biggest complaint about the acquisition process is the time it takes to complete. The user has a problem--some widget or capability they need--and often need now! The timeline that follows is a composite picture of the various programs with which I was familiar from 1983 through 2001.

Typical Program

First, the users generate a Mission Needs Statement. That can take the better part of a year. Then the money people start angling for budget as the users develop an ORD. If we're lucky, acquisition personnel are brought in about halfway through this process, which can take anywhere from one to two years to complete. Only then do we kick off a program, with market research and an acquisition strategy--Commercial Off-the-Shelf (COTS) or not--which we will optimistically set at six months.

Understand that at some point in the ORD development process (usually fairly early), the field has seen some sort of widget, which they believe will meet their needs. In many cases, the ORD will basically be written around this widget, in addition to one or two "little" capabilities that the users want. Sometimes, however, a breakdown in communication occurs between the field users and the people who write the requirements; as a result, the ORD may not be written so that the widget the field users have identified will even fit or meet their requirements.

Now a year has passed since the field users have Identified their widget. Add the acquisition strategy development and we're at a year-and-a-half. From this point on, we will identify elapsed time from user widget identification parenthetically (one-and-a-half years).

Then the acquisition community has to develop a mechanism to actually procure the item, whether its COTS or not. This means going out on some sort of contract, which means preparing to go on contract. Let's be optimistic and say that getting to the source selection only lasts six months (two years)--and that is optimistic, because nine months to a year is more likely the case. Then comes source selection and the program proceeds.