Acquisition transformation: lead into gold?

Acquisition reform. Acquisition transformation. Buzzwords or real change? How realistic is it to expect the current acquisition reform initiatives to bring about real transformation?

[ILLUSTRATION OMITTED]

Every acquisition professional can recite a litany of problems with the acquisition process and point back to Congress, the Federal Acquisition Regulation (FAR), or the DoD 5000 series as the "reasons" the process is as encumbered as it is. But just as often, the real reason is this: "That's the way we've always done it in this command."

Should we expect acquisition transformation to change this? Experience has shown there will be no quick fixes or miracle transformations. But even so, it isn't like trying to turn lead into gold. This transformation can be achieved as long as we realize that drastic change requires drastic actions.

Much has been written about current acquisition transformation initiatives. The July-August 2003 issue of PM magazine contained excellent articles on current efforts to work towards acquisition process improvements, starting with the interview with Marvin Sambur, assistant secretary of the Air Force (acquisition). Sambur has a solid grasp of the precept of evolutionary acquisition as a step to acquisition transformation. Air Force Instruction (AFI) 63-123 codifies the Air Force policy on evolutionary acquisition for command and control (C2) systems. It is discussed in the second article in that issue of PM. "Evolutionary Acquisition Strategies and Spiral Development Processes" by Kenneth Farkas and Paul Thurston. The article mentions the policy memo that Sambur issued on June 4, 2002, replacing Air Force Policy Directive (AFPD) 63-1 and stating that evolutionary acquisition is now the preferred acquisition strategy for the Air Force. In the fourth article in that same issue of PM, "The Underlying Keys to Acquisition," Alexander Slate asks, "Is Acquisition Transformation Doomed to Fail?" Slate emphasizes the importance of the fundamental acquisition processes of need, requirements, prioritization, and asset allocation and makes some suggestions about those processes.

The Need for Out-of-the-box Ideas

I believe the discussion continues because it has not yet been demonstrated that evolutionary acquisition is the true panacea that will heal the acquisition process. I assert that the acquisition community must continuously address all acquisition transformation initiatives and tailor and re-tailor guidance to adapt current government business practices to whatever changing technology and societal mores will sustain. As part of this, we need to invent out-of-the-box practices and assess them for pragmatic feasibility. This is the path to acquisition transformation.

I propose three such procedures, and while they are certainly out-of-the-box, they are not so far out as to be unreachable or unrealistic.

The Technology Dilemma

The case starts with the traditional process. An objective capability is defined, and against it the acquisition program manager (PM) will issue a request for proposal (RFP) for a contract to develop and deliver a system that provides that capability. Evolutionary acquisition allows the PM to create an acquisition plan for spiral development of that objective capability. The PM then awards the contract to the bidder proposing the best solution to satisfy the defined requirements. There are three reasons why the PM may choose an evolutionary acquisition strategy:

1. The development funds are spread across several years.

2. The complexity of the acquisition needs several years to accomplish the objective.

3. The technology is not mature enough to achieve the objective capability in the near time frame.

It's the third reason that causes the dilemma with evolutionary acquisition. If the PM knows precisely what the objective required system capability is, then the program doesn't need spiral development (discounting reasons 1 and 2.) But presumably the PM doesn't know this because none of us knows what tomorrow's technology will be capable of doing for the system. Being realistic, the PM writes requirements for only the first spiral for which technology exists, but the PM wants the objective. So how can the program office evaluate proposals from bidders who equally can't foretell future technologic capabilities but can only propose against the first spiral requirements? How can the PM pick a developer who will deliver the best objective capability, not just the best first spiral capability? All that the proposals can offer is a capability based on today's technology and a "promise" to incorporate tomorrow's technology in future spirals.

So the question for us is this: Is there a better way to plan an evolutionary acquisition and to structure an acquisition strategy that recognizes this dilemma? Or more specifically, is there a way for an acquisition plan to better address the vagaries of spiral development and the unknowns of future technologic capabilities? The answer will truly be a transformed evolutionary acquisition process.

The Answer: A Closer Partnership with Industry

Perhaps such an answer could be called phase II of Sambur's agile acquisition initiative. Sambur said agile acquisition is based on the collaboration of four partners: the requirers, the technologists, the testers, and the acquirer. My suggested phase II adds the developers: our industry partners. Industry must be an integral partner to craft a spiral development strategy that will adapt to the technologists' evolving improvements and the users' correspondingly evolving requirements. In fact, many acquisition instructions call for inclusion of the developer as part of the team. The acquirer (the system program office (SPO)) adds the overall process management and the legal acquisition structure while the tester keeps everyone on track. The PM must find a way to define an acquisition program and issue a corresponding RFP that uses all five partners during all stages of the process to solve this dilemma of unknown future spirals.

Out-of-the-box Idea #1: Concept Development

The industry partner must be included in the initial concept development, traditionally a government-only activity. The draft AFI 63-101 defines a pre-concept refinement phase, followed by a concept refinement phase, then the technology development phase that leads to a system development and demonstration phase, and then the production and deployment phase. The draft AFI 63-101 doesn't discuss the role of industry as a partner in these phases, but it is implied. DoDD 5000. 1, paragraph E1.2, in fact, includes the developers as integrated product team (IPT) members for the capability needs definition activity. Traditional acquisition procedures that have early industry involvement include market surveys, requests for information (RFIs), study contracts, fly-offs, down selects, and so on.

Getting the developer--industry and academia--working together with the team from the beginning requires my first out-of-the-box idea. How can we include the developer in the process from the beginning when we don't select the developer until well into the acquisition process, not until after we've defined the concept, the acquisition strategy, and the requirements?

RFIs and similar broad-based calls to industry for idea inputs are the traditional answer. My idea is to consider industry consortia in which several companies, as well as academia, have formed unofficial partnerships to address common themes or problems. And then there are the professional and technical associations and societies--such as the Institute of Electrical & Electronics Engineers (IEEE) and the Armed Forces Communications & Electronics Association (AFCEA)--that are made up of individual professionals and experts. Both appropriate consortia and professional associations could be called upon to join in the agile acquisition phase II partnerships in the early pre-concept refinement and concept refinement phases. Then as the PM uses the partnership to develop the analysis of alternatives and courses of action, the industry development community will contribute pragmatic ideas for real agile evolutionary acquisition.

Out-of-the-box Idea #2: Developer Selection

After the concept is developed, the PM wants to select a developer who will be the best choice for delivering the objective capability after an evolutionary acquisition of numerous spirals. Traditionally, the PM defines requirements in a technical requirements document (TRD) that becomes part of the RFP. The source selection team picks the bid that proposes the best satisfaction of this TRD. But this doesn't get out of the box to solve the dilemma of unknown future technology. The TRD contains the requirements for only the first spiral. How can the PM overcome the traditional dilemma of using only the TRD for the first spiral to select the developer for the objective system?

The best tool the PM has in the traditional process is the past performance criteria of the source selection process. Does the company have a good track record of maintaining a cost-effective quality development process, responsive to evolving requirements? Or does the company have a poor history, such as underbidding on the first spiral and then getting well on subsequent spirals?

This brings me to my next out-of-the-box idea. The company's long-term processes are more important than the near-term technical offering. Proposals must address the corporate processes to work in partnership with the technologists (the labs and academia) to track emerging technologies and to plan flexible alternatives for using the emerging technologies. Pre-planned product improvements ([P.sup.3]I) give way to flexible spiral technology paths and incremental emerging technology capabilities. What is the company's process for keeping its designs truly modular as an open system architecture to permit flexible technology insertion in the future?

My agile acquisition phase II makes demonstrated performance as an evolutionary acquisition developer a primary source selection criterion. A proposed satisfaction of a single-spiral TRD should be a secondary criterion. Past performance evaluation will consider how well the company has participated in industry/academic consortia to help the government plan for evolutionary technology insertion. The draft AFI 63-101 not only calls for a technology development phase, but also requires a strong technology transition plan. Source selection criteria should also put weight on the company's proposed technology transition plan and its past performance in executing technology transition. Has the company been willing to overcome the not-invented-here syndrome by selecting and integrating technology and capabilities developed by others? And certainly the evaluation must look at how well the company has maintained a cost-effective, best-value spiral development process on previous contracts.

Out-of-the-box Idea #3: New Test Paradigm

The evolutionary acquisition spiral development process presents a significant dilemma for the test member of the partnership. What are the test criteria for spirals that don't have well defined advance requirements? Just as in the discussion of capabilities-based acquisition, how does the PM test for evolving capabilities rather than against static requirements? The draft AFI 63-101 puts a lot of emphasis on ensuring the testers address the problems imposed by spiral development.

The PM and tester must create a suitable new test paradigm to determine the success of each spiral. This new paradigm is my third out-of-the-box idea. The tester must be integral to the five-member team so that the test or acceptance criteria for each spiral are allowed to evolve as the acquisition evolves. The criteria must be open-ended to determine when spirals have produced value-added capability for the warfighter, without regard for pre-conceived notions of what the requirement was "supposed" to be. For instance, the requirer might have thought he wanted a cube, but the best capability might turn out to be in a sphere.

Let's imagine a requirement for a personal combat weapon no bigger or heavier than an M-16. It must have lethal capability against any person or vehicle up to high-mobility multipurpose wheeled vehicle (HMMWV) size at any range that's in line of sight. It must be operator-adjustable to be either lethal or non-lethal. It must have automatic aim capability with 99.9 percent probability of kill and be smart enough not to fire in lethal mode against any friendly target or any non-combatant target. It can be connected, wirelessly, to remote sensors already available in the battlespace.

If that reminds you of something--you're right. Gene Roddenberry conceived such a weapon, called it a phaser, and equipped Captain Kirk's Starship Enterprise crew with it. It always killed or stunned on command and never hit a friendly. But is it simply the stuff of science fiction? Not altogether.

In fact we do have personal weapons that have variable muzzle velocity to either kill or not kill. We have laser spotters and designators. Electronic battlefield networks that will connect every soldier to remote sensors are in development. Even so, we still wouldn't issue an RFP based on these requirements today because technology is still not all in place yet. With agile acquisition phase II, a consortium of industry and academic experts would lay out a logic diagram of what could be done through spiral development if various technology options come to fruition. Based on this, the PM would select a developer who had a demonstrated track record of working with laboratories to spirally develop a system along such potential technology paths. Along these paths, the developer would deliver incremental capability upgrades as appropriate technologies matured. The tester would determine when these spirals warranted fielding of the next increment of capability.

The Musts for Transforming Acquisition

A transformed evolutionary acquisition process must continuously examine and update the traditional processes and must also use new, out-of-the-box practices. Industry and academic partners must be brought into the concept planning process early on. The PM must select the development contractor based on meaningful evaluation of the contractor's spiral development processes for technology insertion. The PM must have new spiral development test strategies that don't need pre-determined requirements for each spiral.

None of that is alchemy. And Congress, the FAR, and the 5000 series aren't standing in the way.

Out-of-the-Box Ideas

1. Industry community as partner during initial concept development

2. Source selection based on demonstrated evolutionary acquisition excellence

3. Test criteria based on capabilities, not requirements

Editor's note: The author welcomes comments and questions. He can be contacted at [e-mail].

Rippere is employed by Titan Systems in support of the Air Force Electronic Systems Center. He has a master's degree in electrical engineering from the Air Force Institute of Technology. He is Level III certified in program management and in systems planning, research, development and engineering, and Level II in developmental engineering.