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

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.

Let's now assume a COTS source selection. Remember that the ORD may or may not have been written to the widget that has actually been chosen by the field users. So, we have Developmental Testing (DT) to see if it meets technical specifications and a full-blown Operational Test (OT) because we've never had this widget in our inventory before (and besides, OT, by law is done by an independent tester). If we lucked out, only another year has elapsed (three years). Then, assuming all is good, we buy the widget and get it out to the field (three-and-a-half years).

That's if the ORD was fairly close to a COTS item. If it isn't, add at least another year for development (four-and-a-half years).

Well, the users get something fielded three-and-a half to four-and-a-half years after they tentatively identified a widget they needed. Little wonder the perceived need for shortened cycle times is rampant throughout the acquisition community.

Evolutionary Acquisition

The November 2000 draft U.S. Air Force Evolutionary Acquisition Guide, published by the Office of the Assistant Secretary of the Air Force for Acquisition (SAF/AQ), defines EA as:

"[a]n acquisition and sustainment strategy to rapidly acquire and sustain a supportable core capability with the ability to incrementally Insert new technology or additional capability."

The Defense Systems Management College (DSMC) publication, Joint Logistics Commanders Guidance For Use of Evolutionary Acquisition Strategy to Acquire Weapon Systems, never defines "Evolutionary Acquisition" as such, but does define the EA process as:

"[a] strategy for use when it is anticipated that achieving the desired overall capability will require the system to evolve during development, manufacture, or deployment."

I like the second definition better, but I'm still not crazy about it.

I believe that we should define EA as the process of acquiring either a new or improved capability where, for whatever reason, it is not possible or not practical to acquire it in a single acquisition. I like my definition for two reasons. First, a core capability may already exist and we may be looking at the next generation. Second, the term "require the system to evolve" used by DSMC somehow seems to reek of the idea of technical insertion.

While there is nothing wrong with technical insertion, that may not be the reason we are using EA. This harkens back to the old P31 process. Sometimes the pressing reason to use EA may be time, not technical performance. Or it may be cost.

At issue is what is really important to the user, and what do they really want? Naturally, what users really want is the ultimate widget that does everything perfectly, never breaks down, and never needs maintenance--they want it in their hands today, and they want it to cost no more than $1.40 a copy. That's only human nature. So the real issue is what widget can be acquired to meet the end user's needs? What are the pressing requirements?

What the process needs is for us to redefine what we view as Key Performance Parameters (KPPs). If having something--anything--to use in the field in 12 months' time is the most important factor, then our KPP is delivery in 12 months. If it is important that we be able to equip 12 million personnel with a widget and we only have $36 million to spend, then the KPP Is a cost of $3 a unit or less.

Roadblocks

What currently prevents our current acquisitions from being what they need to be? Also, as we try to implement EA, what will hinder the process?

ROADBLOCK No. 1

Acquisition teams don't exist until too late In the process. And therefore, acquisition strategies don't exist until too late. In our notional "widget" recap of the current process, they don't exist until one-and-a-half years after the users have already figured out what they want in the field. This is even later than the determination of a need.

ROADBLOCK No. 2

Program budgets and schedules are usually determined before the acquisition strategies are completed.

ROADBLOCK No. 3

ORDs only lay out end-state dreams. ORDs need to reflect (to a degree) the acquisition strategy. As a result, programs are always trying to chase everything on the list from Day 1. This is really much more of an issue than might meet the eye at first blush. And because of many factors, including honest differences in the needs of various users, the "users" (in this case the official user liaisons) won't admit to, or can't determine what is really important: consequently, they won't back down from anything in the ORD.

ROADBLOCK No. 4

Schedule and cost are not really viewed as requirements in the same way that performance requirements are viewed.

ROADBLOCK No. 5

The mindset that, "Acquisition people don't do requirements and users don't do acquisitions."

ROADBLOCK No. 6

The color and year of money simply make for a lot of waste.

ROADBLOCK No. 7

Requirements for a full-spectrum Operational Test and Evaluation (OT&E) on interim capability acquisitions use up a lot of time and money.

ROADBLOCK No. 8

User buy-in for an EA strategy. Users fear that support for programs will dry up before they get a lot of the capabilities that they need--that the EA approach will be arbitrarily short-circuited.

Paving the Road

As soon as a need is identified, we need to form a program team. This needs to occur as soon as possible after the Mission Needs Statement is completed. The makeup of this team must be distributed between acquisition, test, and user communities. Participation by SAF/AQ may also be needed. This team needs to work on both requirements and market research right away.

The acquisition strategy will also start to flow from the determination of requirements and the current state-of-the-art. Developing the framework ORD is key An overall acquisition strategy needs to be framed, including a nominal evolution plan (a description of the projected allocations of capabilities and time frame for Implementation), an analysis of alternatives, funding profiles through at least several increments of development, and projected contract strategies.

Also needed will be a nominal increment-phased Test and Evaluation Master Plan (TEMP). Following Milestone Decision Authority (MDA) approval, the budget needs to be approved. At this point the program team makeup can change to a more classical acquisition makeup (Figure 1), though the continued heavy involvement of the users would be helpful.

The acquisition process described in this article has addressed Roadblocks 1, 2, 3, and 5. In some sense, Roadblock 4 is also addressed, but only if a proper EA ORD is created--one that properly phases requirements into different acquisition increments. If this takes place, I also believe that Roadblock 7 can also be addressed.

Roadblock 6 is a little different. In fact, this particular problem also exists with the classical acquisition process. The only way to change this "fact of life" is congressional realization and action allowing us to create programs where the entire program budget is set. For this type of program, money is available when it is needed, as opposed to only being available in particular years.

Roadblock 8 is a problem that can probably only be addressed with some program successes using these strategies. Of course, in order to have some successes, the solution is the same as for Roadblock 6. Right now, Roadblock 8 is one of perception, not actuality.

A Notional Program-Needs and Availability

Let us imagine a situation where the users have identified a need for a biological agent detector. This detector needs to be small enough so it can be clipped onto an individual's belt. Having this detector serves three purposes: 1) it should detect the presence of harmful biological agents, 2) It should warn the wearer of the presence of these agents, and 3) it should capture a sample of the agents (allowing caregivers a method to determine exposure and thus appropriate treatment).

An appropriate team is created. The team then determines the end-state requirements:

* The detector should have a physical volume no greater than 100 cubic inches (with no dimension to exceed seven inches).

* The weight (including any necessary power sources) shall be no greater than 10 pounds.

* It shall detect and warn of all known biological threat agents (as per a given list) in no longer than 15 seconds (given a certain level of agent present).

* It shall be field programmable to include new threat agents as they are determined.

* It should also allow detection and warning of chemical warfare agents and Toxic Industrial Materials (TIMs).

* Upon detection of agents, it should also provide a warning notification to a remote central site (including Global Positioning System, or GSP coordinates).

* It shall be capable of operating continuously for one week without any maintenance (including power supply changes).

* It shall have no more than a 5 percent false positive identification, and no more than a 1 percent false negative identification.

These requirements are difficult, but also ones which I would realistically expect the user community to require. The market research for our notional program indicates that several devices are available commercially that have various combinations of the requirements.

Device A can collect samples of biological agents, is well within the cube/weight requirements, and will operate for a week without any maintenance. (In fact, let us stipulate that there are a couple of different brands just like Device A.)

Device B will detect and warn the wearer of a partial list of biological agents (though only at a third of the sensitivity desired). It fits within the cube requirements, but the weight is 15 pounds, and it will only operate for a day before requiring new batteries. The false positive and negative rates are 10 percent and 5 percent respectively.

Device C will detect and warn of the same list of biological agents at the desired sensitivity levels. Its volume is 200 cubic inches and it weighs 18 pounds. It will also last for only a day before it requires new batteries, and the false positive and negative rates are 20 percent and 5 percent respectively

Neither Device B nor C collects samples. None of the devices detect chemical agents or TIMs, and none can send a signal to a remote site. Adding additional agents is limited for Devices B and C, and certainly not in the sense of being field programmable.

A National Program--The Alternative

An analysis of the available data indicates that a Research and Development (R&D) program to create the desired objective device in a single acquisition would take 10 years and $35 million. This would be from the time the initial R&D contracts are awarded until the time that all testing is complete, but would not include any production.

Our notional program would have two phases. At the cost stated, there would be two contracts for the Systems Integration, which would last five years. At that time, a single contract would be let for Systems Demonstration, which would also last five years.

Alternatively, any one of the three available devices could be tested and ready for distribution to the field in as little as a year at a cost of $1.5 million.

Another alternative would be that the capabilities of Device A could be combined with the capabilities of either Device B or C (perhaps with some minor enhancements) and ready for production in four years at a cost of $11 million. This would be done with a single contract; adding a second alternative competitor would add no time but would add $4 million.

A National Program-The Evolutionary Acquisition Strategy

The users determine that they want some capability out there as soon as possible, but they also don't want to give up the quest for more capability. After a lot of internal wrangling, they decide that they want to acquire Device A, and they want to start fielding in 10 months.

In fact, because of the current world situation they determine that fairly wide fielding of Device A, within a years time frame, is absolutely crucial. In five years they want the capabilities of Devices A and C, but are willing to accept three days' continuous operation without maintenance. So an Operational Requirements Document is written.

This ORD Is written to an evolutionary strategy in three Increments (Figure 2). For the first increment, the KPPs are Initial Operating Capability (IOC) within one year, the ability to collect sufficient biological agents to allow for positive identification for treatment purposes, and one-week continuous operation. Other requirements are a threshold volume of 100 cubic inches (50 desired), sufficient ruggedness so that no more than 1 percent of the items will break given combat battlefield conditions, and silent operation. Collection of chemical agents and TIMs is given as a desired capability.

For the second Increment, the KPPs are that the new device must be able to collect sufficient biological agents to allow for positive identification for treatment purposes; the device must warn for the top five listed biological threat agents within 30 seconds (15 seconds and the top 10 biological threat agents listed are desired), and three days' continuous operation (one week desired).

Other requirements include a threshold volume of 200 cubic inches (100 desired), weigh less than or equal to 15 pounds, false positive ID rates no greater than 10 percent, false negative ID rates no greater than 2 percent, and sufficient ruggedness for battlefield operation. IOC is given as five years. Desired capabilities include chemical agent and TIM warning, and remote location signal capability

A third increment also calls for the requirements as initially identified by the program team and an 100 of 12 years. The funding profiles needed to accomplish these three evolutionary increments are determined and the Program Objective Memorandum (POM) process begun.

The first increment will be a COTS acquisition. The actual acquisition strategy is that this increment will concentrate on testing the capabilities of the available market devices, particularly concentrating on testing those capabilities that the companies haven't already tested. The selected item will then be purchased using an Indefinite Delivery, Indefinite Quantity (IDIQ) contract.

At the same time, the acquisition team will begin developing the Request For Proposal (RFP) package for the second acquisition increment. They plan on awards to two different contractors to develop the desired item(s). These will be cost-plus contracts. Production will be a separate contract to either one or both of the contractors, depending upon the success of the program. As soon as practical after production begins on the second item, the team will begin working on the RFP on the third increment of the requirement evolution.

A Notional Program--Execution

The program is briefed to the MDA and approval is received. Budget is acquired. The best strategy to accomplish the first phase is to solicit items from industry. The Services will purchase sufficient numbers of the different items from the different vendors in order to conduct testing. Once testing is complete, quotes for an IDIQ contract will be requested from those vendors whose items meet required capabilities. We can then determine the best value between capabilities and cost, and award a single contract to the "winning" bidder. This best value will compare the capabilities to the number of items that can be procured with the budget at hand.

Having worked together, the acquisition team has determined that what needs to be tested most is the field ruggedness of the COTS devices. Also important, though, is the ability of the samples collected to be used to determine medical treatment. The Operational Test Agencies (OTAs) will be responsible for this testing, which will be run as a Limited User Evaluation (LUE). Also examined will be any compatibility issues that the devices have with other gear worn by the users.

Working together, the Services determine that the roughest environment these devices have to face is that of the combat infantryman. So, in order to save time and money, we will conduct this assessment in conjunction with an available Army or Marine Corps exercise.

In order to test the treatment requirement, the OTAs, in conjunction with the DT personnel, arrange for a chamber test where the devices are exposed to realistic levels of battlefield contaminants. The "filled" devices will then be sent to a series of medical pathologists to determine whether the correct contaminant can be identified.

Since it is not critical to the acceptance of the device, separate DT is conducted to determine the capability of the devices to collect chemical warfare agents and TIMs. While this may affect the final determination of what is bought, operational impact is minimal, so the OT testing doesn't address this at all.

A Notional Program--Preparing For Phase II

As testing begins on the first phase, the acquisition team sets to work preparing the solicitation package for the second phase of the program. Going back to the MDA Isn't necessary since both Phase I and Phase II were part of the original decision. Similarly when the POM requests went forward, the budgetary requirements for both phases were included. The source selection for Phase II will begin around the time the Phase I purchase decision takes place.

Some Variations on Evolutionary

Earlier in this article, I used the term spiral development. The notional program described in this article is that of a spiral development, where a phase is followed by another, and then perhaps another to follow the second (Figure 3). But there are some other things we can do to make EA even more adaptable and capable of accomplishing what we need done.

Overlapping Development

Let's talk about overlapping development (Figure 4), which I often refer to as helical development, because we have concurrent spirals which wrap around each other like the coils of a DNA helix. This is something that we in the acquisition community already do to a degree, but don't necessarily talk about. And again, much of the difference about what we currently do as compared to what we can do is a matter of commitment and intent.

Let's say that a couple of things might need to be accomplished in order to prepare for a follow-on phase in our EA strategy Perhaps the next phase requires testing to a sensitivity that we cannot yet accomplish, or perhaps requires a test that doesn't exist. Part of the overall strategy for our EA will need to be the development of required testing concurrently with an earlier phase of our program.

Similarly, maybe we need to spur technological development. The specific purpose is different, but the overall intent is the same--to aid an evolutionary phase of the program. Now, we already do this, but what we don't do is to really tie these together as a single strategy It becomes too easy to cut the R&D program, so when we are "ready" for our follow-on acquisition we really aren't ready for our follow-on acquisition. And sometimes, although less often, we cut out the acquisition program without effecting the necessary technology or test development when they are perceived as no longer necessary. These things need to be addressed as a holographic whole.

Spiral Testing

Often we test items or capabilities that don't make a difference in our acquisition of a particular item. Now, testing is good. But tests take time and they take up resources. Something we don't take advantage of is that, nationally there exists follow-on DT and OT. Testing doesn't necessarily have to end when we procure something. When a program is tight on either time or money why not delay non-decision value-added work until later.

A good example of this was the fairly recent development of the now currentgeneration protective gear. One operational question was, if this protective gear rips can we slap some hundredmile-an-hour tape on it and keep going? This wasn't a reasonable fix for the current gear, and wasn't a critical or key performance requirement for the new gear. Therefore, the answer to this question would have no impact whatsoever on any acquisition decision.

This was at a point in the program where cost cutting was getting critical, and tests (which might have made a difference) were getting cut. This particular answer would not only tie up money but would also tie up a one-of-a-kind chamber, which was needed for other testing. Yet, we could not get one particular element to back off this test. This test, in our new way of thinking, was certainly something important to know from an operations-concept point of view but should have been conducted as we were buying and fielding the item, not while we were developing it.

Similarly as programs run across time pressures, maybe we need to realize that full-scale, multi-million dollar operational tests of every system aren't necessary. Perhaps using limited fielding to provide the real-world data for operational assessment is the way to go, or perhaps the correct course is hybrid testing, which involves testing only those items absolutely necessary to address safety and health concerns prior to fielding, and following up with field data on other capabilities later.

Please understand that I am not talking about skimping on necessary testing, either DT or OT. This Is a practice that is already too common, and is one that has produced bad results. Dr Philip Coyle III, former Director of Operational Test and Evaluation, Office of the Secretary of Defense, and others have already discussed the results of this practice, so I need not repeat their findings. But, that said, we only want to test those requirements that are appropriate to the goals of the particular phase of a program.

Limited Fielding For Its Own Sale

In the preceding discussion, I explained the strategy of using limited fielding for the sake of providing OT data. But say that we are pushing an EA strategy in order to get some type of capability into the field for a critical need. Does everyone need that capability? Perhaps eventually the answer is yes, but that they don't need something in nine months. Perhaps only a certain theater of operation requires something right away and that a reduced capability is better than no capability in this context. Maybe we can scale the procurement appropriately.

Living with Consequences

Implementing the types of strategies I have discussed won't necessarily be easy. And certainly, specific effects will result from trying to take this type of path. These aren't necessarily bad things, though some people will see them as such. They are simply consequences of the decisions we make, and we need to understand and accept them as such if we are going to make things work better.

CONSEQUENCE No. 1

The first consequence is that more work is needed up front in the very beginning of the acquisition process, with acquisition strategies and formal market research taking place much earlier in the process.

CONSEQUENCE No. 2

The second consequence follows on from the first and directly addresses Roadblock No. 5. Acquisition personnel are going to get a lot more involved in determining requirements; conversely the users are going to have a lot more to say about acquisition strategy. A lot of compromise is needed here.

CONSEQUENCE No. 3

The third consequence is also a follow-on from the first. We will need some sort of operating budget for acquisition a lot earlier than in the past. We are no longer talking about vague future planning suitable for planning offices. We are talking about a definitive acquisition strategy which will take up program office resources. This might well mean a new budget line item available for this up-front work.

CONSEQUENCE No. 4

Consequence No. 4 is that programs don't necessarily end when we acquire something. That means resources don't get freed up for other activities.

CONSEQUENCE No. 5

Consequence No. 5 may be considered by some a different way of saying Consequence No. 4, but I view it as very different. Consequence No. 5 is that we have to make commitments to a whole plan involving more than a single round of activity. And we have to be serious about that to which we are committing.

Once we set the requirements for a particular increment of activity, they are set. No creeping requirements allowed! When it comes to making changes, obviously a nine-month program cannot have the flexibility of a four-year program.

CONSEQUENCE No. 6

Consequence No. 6 follows on from both No. 4 and No. 5; MDA decisions will cover a potentially much broader scope than before. That means a lot more work preparing for them, and a new layer of meaning for all involved.

CONSEQUENCE No. 7

Consequence No. 7 is that some activities may have to get used to dealing with less complete data upon which to base their decisions. But that doesn't mean the data aren't sufficient to make the necessary decisions--it's just that some things matter at certain times and others don't.

CONSEQUENCE No. 8

Consequence No. 8 may not be so much of a consequence as a wish. The current method of budgeting for specific years needs to go away. Instead, we need to look at the timeframes involved in specific programs and make budgeting decisions appropriate to those programs.

CONSEQUENCE No. 9

Consequence No. 9 is contingent on No. 8. If we are serious about committing resources to a particular program, we have to be serious about doing these programs right--being patient when it is required, but conversely demanding performance when it is appropriate.

CONSEQUENCE No. 10

Consequence No. 10 is that we may accomplish a smaller number of simultaneous programs in order to make the commitment necessary for the programs we choose to pursue.

Consequences No. 5 and No. 8, when taken together, address the User fears noted as Roadblock 8, earlier in the article. Programs not being allowed to mature to a necessary level will be a real problem if the people and institutions responsible for strategic vision and budget (everyone from agency headquarters staff to Congress) don't have a good understanding of what EA is about and the purposes and goals of the particular program acquisition strategies that will result.

Sill a Few Bugs in the System

A few things can still cause us to stumble. The biggest problem is the time necessary to get the money for these programs into the POM cycle. A sufficiently large wedge placed in the POM as soon as a need is Identified will help matters. However, we have to realize that when we place that wedge in the POM, it isn't going to be even a SWAG (Sophisticated Wild A---- Guess).

For that reason, teams need to have freedom to adjust that amount when planning is sufficiently far along. And, unless the budgeting cycle can adjust to the changes in a reasonable amount of time, we are going to be attempting to accomplish things without the proper resources. Because of Consequence No. 10, having too much money set aside as a wedge may be as big a problem as having too little.

Another problem is that we will be developing acquisition strategy prior to completing the ORE). This is really just a consequence, as opposed to a stumbling block. But if we cannot overcome the mindset that we need firm requirements before creating an acquisition strategy we could seriously impact the capacity that EA has to reduce the time needed to field items.

Evolutionary Acquisition holds a lot of promise. It will not necessarily be appropriate for all acquisitions, and one of the most serious mistakes made is that we try to force everything into the same mold. EA will mean new mindsets and a lot of work, especially as we try to get it right. The first few efforts may easily fail, but commitment and innovation will eventually make it worth the effort and frustration.

Editor's Note: Slate welcomes questions or comments on this article. Contact him at [email protected].

FIGURE 2

Evolutionary Increment Capabilities Comparison

Requirement             Increment 1        Increment 2

Collect bio sample          Yes                Yes
IOC                       1 year             5 years
Bio presence warning        No                 Yes
# of bio agents             N/A             5 (10 obj)
time to warn                N/A               30 sec
                                       (tradable for # of
                                             agents)
Remote warning              N/A             Objective
False Positive              N/A                10%
False Negative              N/A                 2%
Volume                100 [in.sup.3]      200 [in.sup.3]
                         (50 obj)           (100 obj)
Weight (including      not specified          15 lb.
power source)
Field programmable          N/A             Objective
MTBM                       1 wk        3 days (1 wk obj) *
Ruggedness              1% breakage            Same
Silent operation            Yes                Yes
Collect chem             Objective             Yes
agents & TIMS
Warn of chem                No              Objective
agents & TIMS
Acquisition             Commercial          R & D Cost
strategy              Item Evaluation          Plus
Runs                       Begin         Concurrent with
                        Immediately        Increment 1

Requirement            Increment 3

Collect bio sample         Yes
IOC                      12 years
Bio presence warning       Yes
# of bio agents             25
time to warn              15 sec


Remote warning             Yes
False Positive              5%
False Negative              1%
Volume                200 [in.sup.3]

Weight (including         10 lb.
power source)
Field programmable         Yes
MTBM                       1 wk
Ruggedness                 Same
Silent operation           Yes
Collect chem               Yes
agents & TIMS
Warn of chem               Yes
agents & TIMS
Acquisition             R & D Cost
strategy                   Plus
Runs                     Follows
                       Increment 2

* The reason that a lower MTBM is allowable from Increment 1 to
Increment 2 is that the power sources are required to accomplish a
greater number of required tasks.

RELATED ARTICLE: CONSEQUENCES OF IMPLEMENTING AN EVOLUTIONARY ACQUISITION STRATEGY.

Consequence No. 1 More work is needed up front in the very beginning of the acquisition process, with acquisition strategies and formal market research taking place much earlier in the process.

Consequence No. 2 Acquisition personnel are going to get a lot more involved in determining requirements; conversely, the users are going to have a lot more to say about acquisition strategy.

Consequence No. 3 We will need some sort of operating budget for acquisition a lot earlier than in the past. This might well mean a new budget line item available for this up-front work.

Consequence No. 4 Programs don't necessarily end when we acquire something. That means resources don't get freed up for other activities.

Consequence No. 5 We have to make commitments to a whole plan involving more than a single round of activity. And we have to be serious about that to which we are committing. Once we set the requirements for a particular increment of activity, they are set. No creeping requirements allowed!

Consequence No. 6 MDA decisions will cover a potentially much broader scope than before. That means a lot more work preparing for them, and a new layer of meaning for all involved.

Consequence No. 7 Some activities may have to get used to dealing with less complete data upon which to base their decisions.

Consequence No. 8 The current method of budgeting for specific years needs to go away. Instead, we need to look at the timeframes involved in specific programs and make budgeting decisions appropriate to those programs.

Consequence No. 9 If we are serious about committing resources to a particular program, we have to be serious about doing these programs right--being patient when it is required, but conversely demanding performance when it is appropriate.

Consequence No. 10 We may accomplish a smaller number of programs simultaneously in order to make the commitment necessary for the programs we choose to pursue. Action teams don't exist until too late in the process.

EIGHT ROADBLOCKS TO IMPLEMENTING AN EVOLUTIONARY ACQUISITION STRATEGY

Roadblock No. 1  Acquisition teams don't exist
                 until too late in the process.

Roadblock No. 2  Program budgets and schedules
                 are usually determined before the
                 acquisition strategies are completed.

Roadblock No. 3  ORDs only lay out end-state dreams.

Roadblock No. 4  Schedule and cost are not really
                 viewed as requirements in the same
                 way that performance requirements
                 are viewed.

Roadblock No. 5  The mindset that, "Acquisition
                 people don't do requirements
                 and users don't do acquisitons."

Roadblock No. 6  The color and year of money
                 simply make for a lot of waste.

Roadblock No. 7  Requirements for a full-spectrum
                 Operational Test and Evaluation (OT&E)
                 on interim capability acquisitions
                 use up a lot of time and money.

Roadblock No. 8  User buy-in for an Evolutionary
                 Acquisition strategy.

Slate is an acquisition advisor for the Acquisition Center of Excellence at Brooks AFB, Texas. His acquisition career experience includes serving as a test manager, program manager and team lead for a Systems Program Office. He is Level Ill-certified in Program Management. Test and Evaluation, and Systems Planning, Research, Development, and Engineering; and Level I-certified in Logistics.

COPYRIGHT 2002 Defense Acquisition University Press
COPYRIGHT 2003 Gale Group