For several years, the Department of Defense (DOD) has expressed an urgent need to acquire new weapon systems to replace its force that it believes is becoming outdated and too costly to operate. DOD’s annual weapon system investment has increased from about $90 billion 3 years ago to almost $100 billion for fiscal year 2001; over the next 5 years, DOD plans to spend about $516 billion developing and acquiring weapon systems. DOD would like to get the most out of this investment, and it has set goals to develop new weapons in half the traditional time and within budget. Historically, DOD has not received a predictable return on its investment in major weapon systems as they have cost significantly more and taken much longer to complete than originally estimated. When one program runs into problems and needs more money than planned, it comes at the expense of delaying or canceling other programs, which reduces buying power and means less overall modernization. The ability to execute a program more predictably within cost and schedule estimates would lessen the need to offset cost increases by disrupting other programs. DOD recognizes that changes are necessary to its acquisition practices to achieve its modernization goals. Thus, it has advocated adopting the practices of leading commercial firms. Our reviews over the past 20 years have likewise pointed to a need to adopt new practices. We have seen many of the same problems recur in weapon system programs—cost increases, schedule delays, and performance problems. On many occasions, we found that programs required more resources—time and money—than were estimated for demonstrating technologies, designing solutions, and providing more production capabilities in order to meet customer expectations. Because customer expectations for the system’s performance were set when the decision was made to invest in the system, adding resources became the primary option for solving problems when they arose. Despite good intentions and some progress, our ongoing reviews of DOD’s weapon system acquisitions show that these persistent problems remain. As a result, we undertook a body of work that examines weapon system acquisitions issues from a different, more cross-cutting perspective—one that draws lessons learned from the best commercial product development efforts to see if they can be applied to DOD weapon system developments. In past years, leading commercial firms have developed increasingly sophisticated products in significantly less time and at lower costs. Our past work has shown that leading commercial firms expect their program managers to deliver high quality products on time and within budget. Thus, the firms have created an environment and adopted practices that put their program managers in a good position to succeed in meeting these expectations. Collectively, these practices comprise a development process that is anchored in knowledge. The firms demand—and receive— specific knowledge about a new product at key junctures in the process, (see fig. 1). cost, schedule, and There is a synergy in this process, as the attainment of each successive knowledge point builds on the preceding one. Such a knowledge-based process is essential to commercial firms getting better—and predictable— cost, schedule, and performance outcomes. It enables decisionmakers to be reasonably certain about critical facets of the product under development when they need it. We have found that when DOD programs have employed similar practices, they also experience good outcomes. This knowledge can be broken down into three knowledge points: when a match is made between the customer’s needs and the available when the product’s design meets performance requirements, and when the product can be produced within cost, schedule, and quality targets. The most important knowledge point occurs at launch—the point at which the product developer makes a decision to commit (or invest) the resources necessary to develop a new product that will meet customer needs. This knowledge point makes it easier to reach the remaining two knowledge points at the right time. Successful programs are launched only when a product developer is confident that it has the resources— technology, engineering, and production knowledge, along with sufficient time, and money—to develop a product the customer wants. Significant problems have occurred during development when programs were launched without this match. We have reported on how a key resource of a developer—advanced technology—can and must be readied to meet product requirements at the time a product’s development program is launched. In this report, we address both sides of the match: how customer needs and product developer resources can be managed so that a product developer can predictably deliver a product the customer wants. The decisions that are made in translating the ideas for a new product into actual features and characteristics dictate the amount of resources— knowledge, time, money, and capacity—that will be necessary to bring the product to market. Thus, they may be the most highly leveraged of all product development decisions. A product’s requirements are based on customers’ expectations and justify the developer’s investment of resources to provide the desired capability. Requirements drive the amount of capital, time, expertise, and technologies the developer must invest. In the past, it has not been unusual for weapon system requirements to be set at such a high level that the initial estimate of the resources necessary to develop a responsive product proves insufficient, evidenced by cost growth and schedule slippage. The case to justify the requirements is often so stridently made that decisionmakers are in a relatively weak position to do anything other than find more resources. For commercial firms and DOD, the basic process for formulating a product’s requirements is the same. Each begins with understanding the customers’ expectations. These expectations are then translated into product requirements that include the job the product is to perform, the functions or characteristics it is to possess, the practicality it must have, and its reliability. Typically, the first understanding of customer expectations exceeds what the developer can do within available resources, because the developer has a limited amount of resources at its disposal for product development. On one hand is knowledge—the technology and capabilities the developer has to engineer and manufacture the product. On the other hand is the time and money the developer has to develop additional knowledge, if need be, and to design, build, test, and deliver the product. It is not unusual for a customer to want a high-performing product that does not cost much or take too long to develop. Such an expectation may exceed the developer’s technology or engineering expertise or may be more costly and time-consuming to create than the customer is willing to accept. The developer must stay within its means if the venture is to remain mutually beneficial. Table 1 characterizes the divergent interests of the customer and the product developer. Given these different interests, a customer’s wants and a product developer’s available resources must be matched to form an achievable set of product requirements. On one hand, the product developer must develop and produce the product within the time frames the customer needs or the customer may find an alternative product or source. On the other hand, the customer must not demand a product that requires so much money or time to develop that it cannot be afforded or delivered when needed. There is a delicate balance that must be achieved between these two divergent interests before a product can be successfully developed and produced. On all product developments, there is an attempt to match expectations with available resources to define the new product. A customer’s expectations and a product developer’s resources are more closely scrutinized during the matching process that attempts to bring the two together. The outcome is a set of product requirements that represent an agreement that the product will meet the customer’s wants and that the developer can deliver the product within acceptable cost and schedule estimates. The requirements then guide the development program. This basic requirements setting process is illustrated in figure 2. The process of translating general customer expectations into a specific set of product requirements involves information gathering, analysis, negotiation, and agreement. In the commercial process, the customer and the product developer negotiate requirements, matching expectations and available resources into a documented set of product requirements prior to committing resources to product development. During this negotiation, the customer’s relatively unconstrained wants are often reduced to a set of performance characteristics that are achievable with available resources, yet still meet the customer’s needs. The commercial process is a two-way communication between the customer and the product developer. For example, an airline company may want a certain speed to maximize revenue per passenger mile from a new aircraft. However, the product developer may determine that the resources to develop an aircraft with that speed are not available or must be increased dramatically. Both parties then work through an iterative process of trades and negotiation to settle on an aircraft with mutually acceptable performance and resource requirements. The DOD process is somewhat more complex and involves communications among at least four major players. On one end is the customer, which is normally a military organization that belongs to a major fighting force. On the other end is the product developer, usually a defense firm that serves as the prime contractor for developing and producing the weapon system. In between are two other players that actually negotiate needs and resources to arrive at product requirements. One is referred to as the user representative, which is an organization separate from the customer but represents the customer and negotiates on its behalf. The other player is the DOD program manager, a separate organization that, in essence, represents the product developer. Figure 3 illustrates how these different players interact in commercial and DOD requirement-setting processes. Both commercial and defense organizations are concerned about how much a product or weapon system is going to cost, how long it is going to take to build, what resources will be needed to build and maintain it, and whether it works properly. All of these concerns are translated into the product’s requirements. Unlike the commercial process, the DOD product developer does not directly influence the product requirement prior to launching product development. Once requirements are formalized in what DOD refers to as the Operational Requirements Document, they are turned over to the prime contractor, who actually begins product development. The Chairman and the Ranking Member, Subcommittee on Readiness and Management Support, Senate Committee on Armed Services, requested that we examine various aspects of the acquisition process to determine whether the application of best practices can improve program outcomes.