"Big Bang" Acquisition

Definition: An acquisition strategy that involves a single pass through the organization's acquisition life cycle. 

Keywords: acquisition, big bang, grand design, one pass, one shot

MITRE SE Roles and Expectations: MITRE systems engineers (SEs) are expected to understand the fundamental conditions and implications of a big-bang acquisition approach. SEs should have an understanding of the acquisition program/project to determine if it can be successfully pre-specified, planned, and controlled so that only one pass through the traditional systems engineering life cycle is necessary to deliver a system or capability. MITRE SEs are also expected to understand when a big-bang acquisition is not appropriate to a situation, explain the basis for their assessment, and recommend better alternatives.


Max Wideman says, "What happens in a traditional acquisition process? Simply put, you figure out what you want, describe it in a Request for Proposal, solicit bids, pick a competent vendor with the lowest price and fastest delivery, enter into a standard legal contract, wait for the work to be finished, and come back when you can 'pick up the keys to the front door' [1]." The Department of Defense (DoD) as well as other government agencies and foreign governments used this strategy extensively for the acquisition of major systems [2]. In the mid-1990s, it was replaced by "evolutionary acquisition" as the preferred strategy. (See the SEG's Evolutionary Acquisition article.)

Big-bang acquisition is an unpopular strategy in the current environment and should only be used in limited settings when a series of conditions apply. Increasingly, government departments and agencies are acquiring information technology (IT)-intensive systems and capabilities and deploying rapidly fielded systems. Recent studies by the Defense Science Board (DSB) [3, 4] have concluded what many have suspected for years: "The deliberate process through which weapon systems and information technology are being acquired does not match the speed at which new IT capabilities are being introduced in today's information age." Thus big-bang acquisitions are expected to become less relevant and less frequently applied to future government capability developments.

Best Practices and Lessons Learned

The big-bang strategy is based on several assumptions (usually unstated), such as:

  • The user and the acquisition organization can define and articulate all system requirements in the request for proposal.
  • The critical technologies for the system remain static from the time the proposal is requested until the system is tested and delivered.
  • This type of system has been built before, and the development contractor knows how to build (or acquire) and integrate the necessary subsystems and components.
  • The interfaces with other systems remain static from the time the proposal is requested until the system is tested and delivered.
  • The user's operational environment does not change from initial request through delivery of the product.
  • The contractor will deliver the requested product without substantial interim review by the acquisition organization.
  •  The government's original cost estimate was accurate, product funding remains "protected" for the life of the contract, and management reserve is available to handle known unknowns.
  • The acquisition organization can coordinate and integrate the acquisition with other interfacing systems and parallel development efforts.

A big-bang acquisition is an appropriate strategy if all of the preceding assumptions can be met. When these assumptions do not hold and the program has elected (or been directed) to use a big-bang acquisition strategy, the program is at high risk of overrunning cost and schedule, delivering incomplete capabilities, and/or delivering fewer quantities than originally specified. This is because under a big-bang approach, the full system is designed, developed, tested, and deployed in a single instantiation. Any changes to the program, for example, budget cuts, requirements changes, or technology changes, will hinder the system from progressing to the next phase of the acquisition life cycle until the impacts of each change are addressed.

Figure 1 illustrates the General Accountability Office's assessment of the F/A-22 program for using a big-bang acquisition strategy [5]. The F/A-22's advanced avionics, intelligence, and communications technologies were not available at the time of initial contract award. Rather than developing the basic stealth platform with provisions for later technology insertion, a version of big-bang acquisition was used in which the entire aircraft delivery was delayed while the avionics, intelligence, and communications technologies matured.

Comparison of “Big-Bang” and Evolutionary Acquisition
Figure 1. Comparison of "Big-Bang" and Evolutionary Acquisition

Prior to the early or mid-1990s, big-bang acquisition was the normal approach for doing business in the DoD. With the exception of the SR-71 "Skunkworks" development, there have been few cases in the last four decades where a government big-bang development was completed fast enough for all of the assumptions to hold. Commercial aircraft and automobile firms have had better success with the big-bang strategy because of their shorter development cycles. When it became obvious that long acquisition times for major system acquisitions were causing the assumptions to fail, the department policy was changed to favor evolutionary acquisition. Evolutionary acquisition is an incremental approach to delivery of capability, providing for quicker initial (or partial) delivery of capability, while allowing future increments or spirals to address the balance of the requirements and accommodate changes. (See the SEG's Evolutionary Acquisition article.)

The systems engineering implications of a big-bang acquisition are tied closely to the assumptions listed earlier. These assumptions have been learned through MITRE's experience with traditional big acquisitions and explain why many large programs fail despite good traditional systems engineering practice. The longer an acquisition program remains in the development phase, the more likely there will be changes to the requirements, environment or mission, or relevant technology that will require contract modifications and engineering change proposals, thereby lengthening the cycle for delivery and increasing the cost and risk. For some programs, this becomes a vicious cycle (more changes beget more changes), and the development is never completed.

It is critical for SEs to point to the assumptions and stress their importance as indispensable to success when using big bang as the acquisition strategy for a program. In most cases, it is more likely that this strategy should not be chosen (based on historical lack of success) and an alternate strategy should be recommended.

References and Resources

  1. Max's Project Management Wisdom, "Progressive Acquisition and the RUP, Part I: Defining the Problem and Common Terminology," accessed August 30, 2016.
  2. Defense Systems Management College (DSMC), 1999, "Acquisition Strategy Guide," 4th Ed.
  3. DSB Task Force on Department of Defense Policies and Procedures for the Acquisition of Information Technology, March 2009, "Department of Defense Policies and Procedures for the Acquisition of Information Technology."
  4. DSB Task Force on Future Perspectives, April 2009, "Creating a DoD Strategic Acquisition Platform."
  5. GAO Testimony, April 11, 2003, "Better Acquisition Outcomes Are Possible If DoD Can Apply Lessons from F/A-22 Program," GAO-03-645T.


Download the SEG

MITRE's Systems Engineering Guide

Download for EPUB
Download for Amazon Kindle
Download a PDF

Contact the SEG Team