DoDI_5000.02.pdf

Department of Defense

INSTRUCTION

NUMBER 5000.02

January 7, 2015

USD(AT&L)

SUBJECT: Operation of the Defense Acquisition System

References: See References

1. PURPOSE. This instruction:

a. In accordance with the authority in DoD Directive 5000.01 (Reference (a)), reissues the interim DoD Instruction 5000.02 (Reference (b)) to update established policy for the management of all acquisition programs in accordance with Reference (a), the guidelines of Office of Management and Budget Circular A-11 (Reference (c)), and References (d) through (ce).

b. Authorizes Milestone Decision Authorities (MDAs) to tailor the regulatory requirements and acquisition procedures in this instruction to more efficiently achieve program objectives, consistent with statutory requirements and Reference (a).

2. APPLICABILITY. This instruction applies to OSD, the Military Departments, the Office of the Chairman of the Joint Chiefs of Staff and the Joint Staff, the Combatant Commands, the Office of the Inspector General of the Department of Defense, the Defense Agencies, the DoD Field Activities, and all other organizational entities within the DoD (referred to collectively in this instruction as the “DoD Components”).

3. POLICY. The overarching management principles and mandatory policies that govern the Defense Acquisition System are described in Reference (a). This instruction provides the detailed procedures that guide the operation of the system.

4. RESPONSIBILITIES

a. Defense Acquisition Executive (DAE). The DAE is the Under Secretary of Defense for Acquisition, Technology, and Logistics (USD(AT&L)). The DAE will act as the MDA for Major Defense Acquisition Programs (MDAPs) and Major Automated Information System (MAIS) programs. In accordance with Table 1 in Enclosure 1 of this instruction, the DAE may

DoDI 5000.02, January 7, 2015 delegate authority to act as the MDA to the head of a DoD Component, who may further delegate the authority to the Component Acquisition Executive (CAE). The DAE may also delegate MDA authority to another OSD official as the DAE considers appropriate.

b. MDA. The MDA will establish procedures for assigned programs using this instruction as guidance. MDAs should limit mandatory procedures applicable to all assigned programs so as to not exceed the requirements for MDAPs or MAIS programs and other acquisition programs governed by this instruction or DoD Directive 5000.01 (Reference (a)). MDAs should tailor regulatory procedures in the document consistent with sound business practice and the risks associated with the product being acquired.

c. Heads of the DoD Components. The DoD Component Head will implement the procedures in this instruction and Reference (a). Component-required procedures will not exceed those specified in this instruction. When necessary, waivers or requests for exceptions to the provisions of this instruction will be submitted to the DAE, the DoD Chief Information Officer, the Director, Operational Test and Evaluation (DOT&E), or the Director, Cost Assessment and Program Evaluation (DCAPE), via the CAE. Statutory requirements cannot be waived unless the statute permits.

5. PROCEDURES

a. Overview

(1) The statutes governing defense acquisition programs are complex, and the categories into which a program falls will impact acquisition procedures. The designation of a program as an MDAP, a MAIS program, or a Major Weapons System; and the determination that the program is an Information System, a Defense Business System, or responds to an urgent need affect program procedures and policies.

(2) The structure of a DoD acquisition program and the procedures used should be tailored as much as possible to the characteristics of the product being acquired, and to the totality of circumstances associated with the program including operational urgency and risk factors.

(a) MDAs will tailor program strategies and oversight, including program information, acquisition phase content, the timing and scope of decision reviews and decision levels, based on the specifics of the product being acquired, including complexity, risk factors, and required timelines to satisfy validated capability requirements.

(b) When there is a strong threat-based or operationally driven need to field a capability solution in the shortest time, MDAs are authorized to implement streamlined procedures designed to accelerate acquisition system responsiveness. Statutory requirements will be complied with, unless waived in accordance with relevant provisions.

(3) Program Acquisition Categories (ACATs) and Types. All defense acquisition programs are designated by an ACAT (i.e., ACAT I through III) and type (e.g., MDAP, MAIS, or Major System). MDAPs are either estimated to achieve the statutorily defined MDAP cost threshold, or are designated as an MDAP by the DAE. Similarly, MAIS programs are either estimated to achieve the statutorily defined MAIS program cost threshold, or are designated a MAIS program by the DAE. MAIS programs are software intensive and typically have a lower investment level than MDAPs. A MAIS program that is estimated to attain the MDAP cost thresholds may be designated by the DAE as either an MDAP or a MAIS program. MDAP and MAIS program designations carry the greatest consequences in terms of management level, reporting requirements, and documentation and analysis to support program decisions.

Enclosure 1 of this instruction identifies the information requirements associated with all standard program categories or types in tabular form. Table 1 in Enclosure 1 provides specific definitions, funding thresholds, and decision authorities. Some information systems are also designated as a National Security System or a Defense Business System. These designations are defined in statute and have procedural and policy consequences. Enclosure 11 addresses Information Technology, and Enclosure 12 describes Defense Business Systems.

(4) Program Decision Reviews and Milestones. The purpose of the decision reviews embedded in the acquisition procedures described in this section is to carefully assess a program’s readiness to proceed to the next acquisition phase and to make a sound investment decision committing the Department’s financial resources. Consequently, reviews will be issue and data focused to facilitate an examination of relevant questions affecting the decisions under consideration and to allow the MDA to judge whether the program is ready to proceed. The following policies will guide decision reviews:

(a) The MDA is the sole and final decision authority. Staff members and staff organizations support and facilitate the MDA's execution of that authority.

(b) The Defense Acquisition Board (DAB) will advise the DAE on critical acquisition decisions when the DAE is the MDA. The DAE or designee will chair the DAB. An Acquisition Decision Memorandum (ADM) will document decisions resulting from reviews.

Similar procedures will be established at the Component level for use by other MDAs.

(c) Program Managers, under the supervision of Program Executive Officers (PEOs) and CAEs, are expected to design acquisition programs, prepare programs for decisions, and execute approved program plans.

(d) Overarching Integrated Product Teams at the DoD level, and similar organizations within the DoD Components are expected to collectively assist the MDA in making sound investment decisions for the department, and to ensure programs are structured and resourced to succeed. These organizations are not decision bodies and they and their leaders do not supplant the authority of the Program Manager, PEO, CAE, or DAE.

(e) Issues should be resolved at the lowest level possible. When an issue cannot be resolved quickly at a lower level, the issue will be submitted to the MDA with complete and objective data necessary to support a decision.

(f) The documents prepared in support of the decision process (e.g., Acquisition Strategy, Systems Engineering Plan (SEP), Test and Evaluation Master Plan (TEMP), Life-Cycle Sustainment Plan (LCSP)) should generally not be prepared solely for staff review and approval, but be intended primarily for use within the program as planning and management tools that are highly specific to the program and tailored to meet program needs.

(g) Review preparation will be streamlined and efficient. Staff members will be provided with the data needed to support the review, but they will also work to minimize the overhead burden placed on the DoD Components, PEOs, program managers, and their staffs.

b. Relationship Between Defense Acquisition, Requirements, and Budgeting Processes

(1) Acquisition, requirements, and budgeting, are closely related and must operate simultaneously with full cooperation and in close coordination. Validated “Capability Requirements” provide the basis for defining the products that will be acquired through the acquisition system and the budgeting process determines Department priorities and resource allocations and provides the funds necessary to execute planned programs. Throughout a product’s life cycle, adjustments may have to be made to keep the three processes aligned.

Capability requirements may have to be adjusted to conform to technical and fiscal reality.

Acquisition programs may have to adjust to changing requirements and funding availability.

Budgeted funds may have to be adjusted to make programs executable or to adapt to evolving validated capability requirements and priorities. Stable capability requirements and funding are important to successful program execution. Those responsible for the three processes at the DoD level and within the DoD Components must work closely together to adapt to changing circumstances as needed, and to identify and resolve issues as early as possible.

(2) Capability Requirements Process

(a) All acquisition programs respond to validated capability requirements. Figure 1 illustrates the interaction between the requirements process and the acquisition process. The Chairman of the Joint Chiefs of Staff, with the advice of the Joint Requirements Oversight Council (JROC), will assess and validate joint military requirements for MDAP and MAIS programs, and less-than-MDAP or MAIS programs designated either as “JROC Interest” or “Joint Capabilities Board Interest.” When JROC validation authority is delegated in accordance with the Joint Capabilities Integration and Development System (JCIDS) process in Chairman of the Joint Chiefs of Staff Instruction 3170.01H (Reference (d)), the DoD Components will use variations of the JCIDS to validate their requirements. The chair of the Investment Review Board is the validation authority for Defense Business System capability requirements.

(b) Leadership of the acquisition and budget processes will be involved as advisors to the validation authority during consideration of initial or adjusted validation of capability requirements to ensure coordination across the three processes.

Figure 1. Illustration of the Interaction Between the Capability Requirements Process and the Acquisition Process

(c) The titles of capability requirements documents supported by JCIDS vary by the maturity of the capability gap to solution proposal and can vary by product classification. When the titles vary from the most typical Initial Capabilities Document (ICD), Capability Development Document (CDD), or Capability Production Document, the text will use the generic terms, “validated capability requirements document” or “equivalent requirements document.”-

(d) Capability requirements are not expected to be static during the product life cycle. As knowledge and circumstances change, consideration of adjustments or changes may be requested by acquisition, budgeting, or requirements officials. Configuration Steering Boards (CSBs), as described in paragraph 5d(5)(b) in this section, will also be used to periodically review program progress and identify opportunities for adjustment.

(3) Budgeting Process. The DoD budgeting process is based on the annual budget preparation cycle managed by the DCAPE and the Under Secretary of Defense (Comptroller) for the Deputy Secretary of Defense. This process produces a Future Years Defense Program (FYDP) that covers 5 years of spending. While individual program decisions fall under the DAE or designated MDA, DoD budget decisions are made separately at the Secretary or Deputy Secretary level, with the advice of the DAE and others. Within the DoD Components, MDAs will advise the Component budget authorities to ensure that acquisition programs are adequately funded and that program plans are consistent with programmed funding levels.

Materiel Solution Analysis Phase

Technology Maturation & Risk Reduction Phase

Initial Capabilities Document*

Materiel Development Decision

Engineering & Manufacturing Development

Phase

B

Production & Deployment Phase

= Milestone Decision

= Decision Point

Legend

* Or Equivalent Approved/Validated Requirements Document.

Development RFP Release

Decision Point

C

Operations & Support Phase

= Requirements Document

= Requirements Authority Review

Disposal

Capability Development Document*

Capability Production Document*

Draft Capability

Development Document*

Requirements Authority Review of

AoA Results

AA

c. Generic and DoD-Specific Acquisition Program Models, Decision Points, and Phase Activities

(1) This section is structured in increasing layers of detail and complexity, beginning with a very generic description of acquisition phases and decision points that could apply to almost any product life cycle, DoD or otherwise, followed by more specific commonly used DoD program models, and concluding with a description of the procedures used in most DoD acquisition programs prior to any tailoring. DoD acquisition managers and staff should focus on the basics of sound acquisition planning, management, and decision making as discussed in this section as their primary responsibility—while also assuring compliance, as appropriate, with the specific requirements found in the tables that follow in Enclosures 1 and 13 and other applicable enclosures.

(2) Generic Acquisition Program Structure and Decision Points

(a) Generic Acquisition Program Structure. For reference, a generic product acquisition program would follow the structure depicted in Figure 2. Figure 2 illustrates the sequence of decision events in a generic program, which could be a Defense program or, except for the unique DoD terminology, a commercial product.

Figure 2. Generic Acquisition Phases and Decision Points

Risk Reduction Decision (DoD: Milestone A)

Technology Maturation and Risk Reduction

Development Contract Award (DoD: Milestone B)

Development

Disposal

Low-Rate Initial Production or Limited Deployment and Operational Test

Initial Production or Fielding (DoD: Milestone C)

Full-Rate Production/ Full Deployment

Production, Deployment, and Sustainment

Figure 2 illustrates the sequence of decision events in a generic program.

It is not intended to reflect the time dedicated to associated phase activity.

Solution Analysis

Need Identification (DoD: Material Development Decision)

Requirements Decision Point (DoD: CDD Validation)

Development RFP ReleaseDevelopment Decisions

Production Decisions= Decision Point

Legend:

CDD

RFP

= Capability Development Document = Request For Proposal

(b) Generic Acquisition Milestones and Decision Points

1. Need Identification, called the Materiel Development Decision by DoD, is the decision that a new product is needed and that activities to analyze alternative solutions will occur.

2. Risk Reduction Decision, called Milestone A by DoD, is an investment decision to pursue specific product or design concepts, and to commit the resources required to mature technology and/or reduce any risks that must be mitigated prior to decisions committing the resources needed for development leading to production and fielding.

3. The decision to commit resources to the development of a product for manufacturing and fielding, called Engineering and Manufacturing Development (EMD) by DoD, follows completion of any needed technology maturation and risk reduction. DoD breaks this commitment into three related decisions: (1) a requirements decision point (called the CDD Validation Decision by DoD); (2) a decision to release a solicitation for development to industry, called the Development Request for Proposals (RFP) Release Decision Point; and (3) a decision to award the contract(s) for development, called Milestone B by DoD. Formally, the development contract award authorized at DoD’s Milestone B is the critical decision point in an acquisition program because it commits the organization’s resources to a specific product, budget profile, choice of suppliers, contract terms, schedule, and sequence of events leading to production and fielding. In practice however, almost all of these decisions have to be made prior to the release of the RFP to industry in order to inform the bidders’ proposals. For DoD, the Development RFP Release Decision Point is the point at which plans for the program must be most carefully reviewed to ensure all risks are understood and under control, the program plan is sound, and that the program will be affordable and executable.

a. Requirements Decision Point (CDD Validation Decision for DoD). The point at which the major cost and performance trades have been completed and enough risk reduction has been completed to support a decision to commit to the set of requirements that will be used for preliminary design activities, development, and production (subject to reconsideration and refinement as knowledge increases).

b. Development RFP Release Decision. The point at which planning for development is complete and a decision can be made to release an RFP for development (and possibly initial production) to industry.

c. Development Decision, called Milestone B by DoD. The development decision commits the resources (authorizes proceeding to award of the contract(s)) needed to conduct development leading to production and fielding of the product.

4. The decision to enter production follows development and testing. For DoD, the production decision is normally broken into two DoD decisions: (1) Low-Rate Initial Production (LRIP), called Milestone C by DoD, or Limited Deployment; and (2) the Full-Rate Production or Full Deployment Decision.

a. The Initial Production Decision. The production decision, based primarily on developmental testing results and usually also informed by an operational assessment, commits the resources (i.e., authorizes proceeding to award the contract(s)) required to enter production and begin deployment of the product. Evidence from testing that the product design is stable is the critical consideration for this decision. The commitment to enter production is very expensive and difficult to reverse.

b. Full Rate Production or Full Deployment Decision. The decision, following completion of operational testing of representative initial production products, to scale up production and/or deployment.

5. While these generic decision points and milestones are standard, MDAs have full latitude to tailor programs in the most effective and efficient structure possible, to include eliminating phases and combining or eliminating milestones and decision points, unless constrained by statute. Paragraph 5d provides more detail about the standard structure, milestones, and decision points as they apply to most defense acquisition programs. Enclosure 1 includes tables of specific requirements for the various statutory and regulatory categories of programs. Enclosures 11 through 13 provide additional information about Information Technology programs (described in Enclosure 11), Defense Business Systems (described in Enclosure 12), and Urgent Needs (described in Enclosure 13).

(3) Defense Acquisition Program Models

(a) Paragraphs 5c(3)(b) through 5c(3)(e) describe four basic models that serve as examples of defense program structures tailored to the type of product being acquired or to the need for accelerated acquisition. Two additional hybrid models combine the features of multiple basic models. Each basic model is tailored to the dominant characteristics of the product being acquired (e.g., hardware intensive products such as most weapons systems). The hybrids are described because many products will require combining models, such as a weapons systems development that includes significant software development. Acquisition programs should use these models as a starting point in structuring a program to acquire a specific product.

1. The models provide baseline approaches. A specific program should be tailored to the unique character of the product being acquired.

2. All of the models contain requirements and product definition analysis, risk reduction, development, testing, production, deployment, and sustainment phases punctuated by major investment decisions at logical programmatic and contractual decision points. Progress through the acquisition management system as depicted in any of these models or in a tailored variation depends on obtaining sufficient knowledge about the capability to be provided and risks and costs remaining in the program to support a sound business decision to proceed to the next phase.

3. Figures and brief descriptions are provided for each model. The figures illustrate the typical sequence of events and activities. A dotted diagonal line and color blending imply overlapping activities.

(b) Model 1: Hardware Intensive Program. Figure 3 is a model of a hardware intensive development program such as a major weapons platform. This is the classic model that has existed in some form in all previous editions of this instruction. It is the starting point for most military weapon systems; however, these products almost always contain software development resulting in some form of Hybrid Model A (paragraph 5c(3)(f)1 describes Hybrid Model A).

Figure 3. Model 1: Hardware Intensive Program

BA C

= Milestone Decision = Decision PointLegend:

Materiel Development

Decision

CDD

Validation

Full Rate Production (FRP) Decision

Development

RFP

Release Decision

Initial Operational Capability

(IOC)

Full Operational Capability

(FOC)

Materiel Solution Analysis

Technology Maturation &

Risk Reduction

Production & Deployment

Engineering & Manufacturing Development

Disposal

LRIP

Operational Test and Evaluation (OT&E)

Operations & Support

Sustainment

(c) Model 2: Defense Unique Software Intensive Program. Figure 4 is a model of a program that is dominated by the need to develop a complex, usually defense unique, software program that will not be fully deployed until several software builds have been completed. The central feature of this model is the planned software builds – a series of testable, integrated subsets of the overall capability – which together with clearly defined decision criteria, ensure adequate progress is being made before fully committing to subsequent builds.

1. Examples of this type of product include military unique command and control systems and significant upgrades to the combat systems found on major weapons systems such as surface combatants and tactical aircraft.

2. Several software builds are typically necessary to achieve a deployable capability. Each build has allocated requirements, resources, and scheduled testing to align dependencies with subsequent builds and to produce testable functionality to ensure that progress is being achieved. The build sequencing should be logically structured to flow the workforce from effort to effort smoothly and efficiently, while reducing overall cost and schedule risk for the program.

Figure 4. Model 2: Defense Unique Software Intensive Program

Full Deployment

Decision

(FDD)

Full Deployment

(FD)

Materiel Solution Analysis

Technology Maturation &

Risk Reduction

Engineering & Manufacturing Development

Materiel Development

Decision

Production & Deployment

Operations & Support

Disposal

IOC

Build 1.1

Build 1.3Build 0.1

Risk Reduction

= Milestone Decision = Decision PointLegend:

CDD

Validation

Build 1.5 Build 2.1*

Integration

OT&E

Limited Deployment

* The actual number and type of builds during the program will depend on system type.

Development

RFP

Release Decision

Build 1.4

Build 1.2

(d) Model 3: Incrementally Deployed Software Intensive Program. Figure 5 is a model that has been adopted for many Defense Business Systems. It also applies to upgrades to some command and control systems or weapons systems software where deployment of the full capability will occur in multiple increments as new capability is developed and delivered, nominally in 1- to 2-year cycles. The period of each increment should not be arbitrarily constrained. The length of each increment and the number of deployable increments should be tailored and based on the logical progression of development and deployment for use in the field for the specific product being acquired.

Figure 5. Model 3: Incrementally Deployed Software Intensive Program

1. This model is distinguished from the previous model by the rapid delivery of capability through multiple acquisition increments, each of which provides part of the overall required program capability. Each increment may have several limited deployments; each deployment will result from a specific build and provide the user with a mature and tested sub-element of the overall incremental capability. Several builds and deployments will typically be necessary to satisfy approved requirements for an increment of capability. The identification and

BA

FDD

Materiel Solution Analysis

Risk Reduction

Development & Deployment

Materiel Development

Decision

Build 1.1

Build 0

Risk Reduction

Build

CDD

Validation

OT&E

Build 1.n

Build 1.2

Limited Deployment

Decisions

Sustainment

FD

IOC

Operations & Support

Build 2.1

OT&E

Build 2.n

Build 2.2 . . .

Sustainment

FDDLimited Deployment Decisions

FD

IOC

B

Risk Reduction

Development & Deployment

Operations & Support

Increment 2

Disposal

Build n.1

OT&E

Build n.n

Build n.2 . . .

Sustainment

FDD FD

B

Risk Reduction

Development & Deployment

Operations & Support

Increment n

= Milestone Decision

= Decision Point

Legend

RFP

Release Decision

Development RFP Release Decision

Development RFP Release Decision

IOC

Limited

Decisions development of technical solutions necessary for follow-on capability increments have some degree of concurrency, allowing subsequent increments to be initiated and executed more rapidly.

2. This model will apply in cases where commercial off-the-shelf software, such as commercial business systems with multiple modular capabilities, are acquired and adapted for DoD applications. An important caution in using this model is that it can be structured so that the program is overwhelmed with frequent milestone or deployment decision points and associated approval reviews. To avoid this, multiple activities or build phases may be approved at any given milestone or decision point, subject to adequate planning, well-defined exit criteria, and demonstrated progress. An early decision to select the content for each follow-on increment (2 through N) will permit initiation of activity associated with those increments. Several increments will typically be necessary to achieve the required capability.

(e) Model 4: Accelerated Acquisition Program. Figure 6 is a model that applies when schedule considerations dominate over cost and technical risk considerations. This model compresses or eliminates phases of the process and accepts the potential for inefficiencies in order to achieve a deployed capability on a compressed schedule. The model shows one example of tailoring for accelerated acquisition and many others are possible. This type of structure is used when technological surprise by a potential adversary necessitates a higher-risk acquisition program. Procedures applicable to urgent needs that can be fulfilled in less than 2 years are a subset of this model and are discussed in Enclosure 13.

Figure 6. Model 4: Accelerated Acquisition Program

A/B

Solution Analysis

Concurrent Technology Maturation, Risk Reduction and Development

Materiel Development

Decision

Preliminary Design Review

Concurrent Production and

Deployment

= Milestone Decision = Decision PointLegend:

C

FOCIOC

Sustainment Disposal

Operations & Support

OT&E

(f) Hybrid Acquisition Programs

1. Figure 7 is a model depicting how a major weapons system combines hardware development as the basic structure with a software intensive development that is occurring simultaneously with the hardware development program. In a hardware intensive development, the design, fabrication, and testing of physical prototypes may determine overall schedule, decision points, and milestones, but software development will often dictate the pace of program execution and must be tightly integrated and coordinated with hardware development decision points.

Figure 7. Model 5: Hybrid Program A (Hardware Dominant)

2. In the hybrid “A” model, software development should be organized into a series of testable software builds, as depicted in Figure 7. These builds should lead up to the full capability needed to satisfy program requirements and Initial Operational Capability (IOC).

Software builds should be structured so that the timing of content delivery is synchronized with the need for integration, developmental and operational testing in hardware prototypes. The Milestone B decision to enter EMD and the Milestone C decision to enter Production and Deployment (P&D) should include software functional capability development maturity criteria as well as demonstrated technical performance exit criteria.

FRP

FOC

Materiel Solution Analysis

Technology Maturation &

Risk Reduction

Engineering & Manufacturing Development

Materiel Development

Decision

Operations & Support Disposal

IOC

Build 1.1 Build 1.2

Build 1.3 Build 1.4

Build 0.1

= Milestone Decision = Decision PointLegend:

CDD

Validation

Build 1.5 Build 2.1 Integration

OT&E

LRIP

Build 3.1 Build 3.2*

Production &

* The actual number and type of builds during the program will depend on system type.

RFP

Release Decision

3. Figure 8, Model 6: Hybrid Model B (Software Dominant), depicts how a software intensive product development can include a mix of incrementally deployed software products or releases that include intermediate software builds. All of the comments about incremental software fielding associated with Model 3 in paragraph 5c(3)(d) apply to this model as well. This is a complex model to plan and execute successfully, but depending on the product it may be the most logical way to structure the acquisition program.

Figure 8. Model 6: Hybrid Program B (Software Dominant)

(g) Risk Management in Hybrid Models. Highly integrated complex software and hardware development poses special risks to program cost and schedule performance. Technical, cost, and schedule risks associated with hardware and software development must be managed throughout the program’s life cycle and will be a topic of special interest at all decision points and milestones.

BA

Solution Analysis

Materiel Development

Decision

Build 1.1.1

Build 1.0.1

CDD

Validation FDD

OT&E

Build 1.1.2

Sustainment

FD

IOC

Disposal

Build 2.1.1

OT&E

Build 2.1.2

Sustainment

FD

B Increment 2

Production & Deployment

Engineering & Manufacturing Development

Operations & SupportTechnology Maturation &

Risk Reduction

Build 1.1.3 Build 1.2

Integration

Limited Deployment

(LD)

Build 2.1.3

C

Build 1.3.1 Build 1.3.2*

Production & Deployment

Engineering & Manufacturing Development

Operations & SupportTechnology Maturation &

Risk Reduction

Build 2.2

Integration

C

LD

Build 2.3.1 Build 2.3.2

= Milestone Decision = Decision PointLegend:

RFP

Release Decision

Development RFP Release Decision FDD

IOC

d. Acquisition Process Decision Points and Phase Content. The procedures in subparagraphs 5d(1) through 5d(14) are general and are applicable to the acquisition program models previously described and to variations in them. Tailoring is always appropriate when it will produce a more efficient and effective acquisition approach for the specific product. Non- MDAP and non-MAIS programs will use analogous DoD Component processes. Additional or modified procedures applicable to Information Technology and to Defense Business System programs are described in Enclosures 11 and 12 of this instruction, respectively, and procedures applicable to urgent needs are described in Enclosure 13.

(1) Materiel Development Decision

(a) The Materiel Development Decision is based on a validated initial requirements document (an ICD or equivalent requirements document) and the completion of the Analysis of Alternatives (AoA) Study Guidance and the AoA Study Plan. This decision directs execution of the AoA, and authorizes the DoD Component to conduct the Materiel Solution Analysis Phase.

This decision point is the entry point into the acquisition process for all defense acquisition products; however, an “acquisition program” is not formally initiated (with the accompanying statutory requirements) until Milestone B, or at Milestone C for those programs that enter directly at Milestone C. DoD Components may have conducted enough analysis to support preliminary conclusions about the desired product at this point. If so, that analysis may be used by the MDA to narrow the range of alternatives. If not, requirements are likely to be less well-defined or firm, and a wider range of alternatives will need to be considered.

(b) At the Materiel Development Decision, the DCAPE, (or DoD Component equivalent) will present the AoA Study Guidance, and the AoA lead organization will present the AoA Study Plan. In addition, the Component will provide the plan to staff and fund the actions that will precede the next decision point (usually Milestone A) including, where appropriate, competitive concept definition studies by industry.

(c) If the Materiel Development Decision is approved, the MDA will designate the lead DoD Component; determine the acquisition phase of entry; and identify the initial review milestone, usually, but not always, a specific milestone as described in one of the program models. MDA decisions will be documented in an ADM. The approved AoA Study Guidance and AoA Study Plan will be attached to the ADM.

(2) Materiel Solution Analysis Phase

(a) Purpose. The purpose of this phase is to conduct the analysis and other activities needed to choose the concept for the product that will be acquired, to begin translating validated capability gaps into system-specific requirements including the Key Performance Parameters (KPPs) and Key System Attributes (KSAs), and to conduct planning to support a decision on the acquisition strategy for the product. AoA solutions, key trades among cost, schedule, and performance, affordability analysis, risk analysis, and planning for risk mitigation are key activities in this phase.

(b) Phase Description

1. Minimum funding required for this phase is normally that needed to analyze and select an alternative for materiel development, and to complete the activities necessary to support a decision to proceed to the next phase; technology development and concept analysis and design efforts may also be funded in this phase.

2. The validated ICD and the AoA Study Plan will guide the AoA and Materiel Solution Analysis Phase activity. The analysis will be conducted in accordance with the procedures in Enclosure 9 of this instruction, and focus on identification and analysis of alternatives; measures of effectiveness; key trades between cost and capability; total life-cycle cost, including sustainment; schedule; concepts of operations; and overall risk. The AoA will inform and be informed by affordability analysis, cost analysis, sustainment considerations, early systems engineering analyses, threat projections, and market research.

3. Prior to the completion of this phase, the DoD Component combat developer will prepare a Concept of Operations/Operational Mode Summary/Mission Profile (CONOPS/OMS/MP) that will include the operational tasks, events, durations, frequency, operating conditions and environment in which the recommended materiel solution is to perform each mission and each phase of a mission. The CONOPS/OMS/MP will be provided to the Program Manager and will inform development of the plans for the next phase including:

acquisition strategy, test planning, and capability requirements trades. It will be provided to industry as an attachment for the next acquisition phase RFP.

4. This phase ends when a DoD Component has completed the necessary analysis and the activities necessary to support a decision to proceed to the next decision point and desired phase in the acquisition process. The next phase can be Technology Maturation and Risk Reduction (TMRR), EMD, or P&D, depending on the actions needed to mature the product being acquired. Each of these phases has associated decision points to authorize entry:

Milestone A, Development RFP Release and Milestone B, or Milestone C. Each decision point and phase has information requirements identified in Table 2 in Enclosure 1 of this instruction, and other criteria as defined in paragraphs 5d(3) through 5d(14) in this instruction.

(c) Program Office Establishment and Next Phase Preparation. During the Materiel Solution Analysis Phase, the CAE will select a Program Manager and establish a Program Office to complete the necessary actions associated with planning the acquisition program with emphasis on the next phase. Prior to preparation and release of a final RFP for the planned next phase, the Program Manager should complete and submit the Acquisition Strategy and obtain MDA approval. An approved Acquisition Strategy will inform development of the final RFPs for the next phase of the program.

(3) Milestone A

(a) The Milestone A decision approves program entry into the TMRR Phase and release of final RFPs for TMRR activities. The responsible DoD Component may decide to perform technology maturation and risk reduction work in-house and/or award contracts associated with the conduct of this phase. Competitive prototypes are part of this phase unless specifically waived by the MDA. Key considerations are:

1. The justification for the preferred materiel solution.

2. The affordability and feasibility of the planned materiel solution.

3. The scope of the capability requirements trade space and understanding of the priorities within that trade space.

4. The understanding of the technical, cost, and schedule risks of acquiring the materiel solution, and the adequacy of the plans and programmed funding to mitigate those risks prior to Milestone B.

5. The efficiency and effectiveness of the proposed acquisition strategy (including the contracting strategy and the intellectual property (IP) strategy) in light of the program risks and risk mitigation strategies.

6. The projected threat and its impact on the material solution.

(b) At the Milestone A Review:

1. The Program Manager will present the approach for acquiring the preferred materiel solution including: the Acquisition Strategy, the business approach, framing assumptions, an assessment of program risk and how specific technology development and other risk mitigation activities will reduce the risk to acceptable levels, and appropriate “Should Cost” management targets.

2. The DoD Component will:

a. Present an affordability analysis and proposed affordability goals based on the resources that are projected to be available to the DoD Component in the portfolio(s) or mission area(s) associated with the program under consideration. The analysis will be supported by a quantitative assessment of all of the programs in the prospective program’s portfolio or mission area that demonstrates the ability of the Component’s estimated budgets to fund the new program over its planned life cycle. Affordability analyses are not intended to produce rigid, long-range plans; their purpose is to inform current decisions about the reasonableness of embarking on long-term capital investments at specific capability levels. The affordability analysis will support the Component’s proposed affordability goals for unit production and sustainment costs for MDA approval and inclusion in the Milestone A ADM. Enclosure 8 details the policy for affordability analyses and constraints.

b. Submit a DoD Component cost estimate for the preferred solution(s) identified by the AoA. Enclosure 10 covers cost estimating in greater detail.

c. Demonstrate that the program will be fully funded within the FYDP at Milestone A.

3. If Milestone A is approved, the MDA will make a determination on the materiel solution, the plan for the TMRR Phase, release of the final RFP, and specific exit criteria required to complete TMRR and enter EMD. The MDA will document these decisions in an ADM.

(c) If substantive changes to the plan approved at Milestone A are required as a result of the source selection process, the DoD Component will notify the MDA who may, at his or her discretion, conduct an additional review prior to contract awards.

(4) TMRR Phase

(a) Purpose. The purpose of this phase is to reduce technology, engineering, integration, and life-cycle cost risk to the point that a decision to contract for EMD can be made with confidence in successful program execution for development, production, and sustainment.

(b) Phase Description

1. This phase should include a mix of activities intended to reduce the specific risks associated with the product to be developed. This includes additional design trades and requirements trades necessary to ensure an affordable product and executable development and production programs. Capability requirements are matured and validated, and affordability caps are finalized during this phase. The TMRR Phase requires continuous and close collaboration between the program office and the requirements communities and authorities. During this phase, any realized Should Cost management savings should normally be used to further reduce program risk and future program costs. Enclosure 2 describes baseline cost control and the use of Should Cost management.

2. This phase normally includes competitive sources conducting technology maturation and risk reduction activities and preliminary design activities up to and including a Preliminary Design Review (PDR) prior to source selection for the EMD Phase.

a. Risk reduction prototypes will be included if they will materially reduce engineering and manufacturing development risk at an acceptable cost. Risk reduction prototypes can be at the system level or can focus on sub-systems or components.

b. A competitive prototype, or if this is not feasible, a single prototype or prototyping of critical subsystems prior to Milestone B is statutorily required to be part of the Acquisition Strategy for MDAPs and is a regulatory requirement for all other programs. The MDA may waive the competitive prototyping requirement at or prior to Milestone A if:

I. The cost of producing competitive prototypes exceeds the expected life-cycle benefits (in constant dollars) of producing the prototypes, including the benefits of improved performance and increased technological and design maturity that may be achieved through competitive prototyping; or

II. The department would be unable to meet critical national security objectives without such a waiver.

3. There are a number of ways to structure this phase which should be tailored to reduce the specific risks associated with the product being acquired. Technology Readiness Levels, described in the Technology Readiness Assessment (TRA) Guidance (Reference (e)), should be used to benchmark technology risk during this phase; however, these indices are rough benchmarks, and not conclusive about the degree of risk mitigation needed prior to development.

Deeper analysis of the actual risks associated with the preferred design and any recommended risk mitigation must be conducted and provided to the MDA.

(c) The Acquisition Strategy will guide this phase. Multiple technology development demonstrations, defined in the acquisition strategy, may be necessary before the operational user and material developer can substantiate that a preferred solution is feasible, affordable, and supportable; satisfies validated capability requirements; and has acceptable technical risk.

Critical program information will be identified during this phase and program protection measures to prevent disclosure of critical information will be implemented consistent with section 13 in Enclosure 3. Planning for EMD, production, developmental and operational test, and life-cycle sustainment of proposed products will occur during this phase. The government will update the program IP Strategy (see paragraph 6a(4) of Enclosure 2) to ensure the ability to compete future sustainment efforts consistent with the Acquisition Strategy to include competition for spares and depot repair.

(d) During this phase, and timed to support CDD validation (or its equivalent), the Program Manager will conduct a systems engineering trade-off analysis showing how cost and capability vary as a function of the major design parameters. The analysis will support the assessment of refined KPPs/KSAs in the CDD. Capability requirements proposed in the CDD (or equivalent requirements document) should be consistent with program affordability goals.

(e) Subsequent to CDD validation, the Program Manager will conduct additional requirements analysis including: requirements decomposition and allocation, definition of internal and external interfaces, and design activities leading to a PDR. Unless waived by the MDA, the PDR will occur prior to Milestone B.

(f) Program Planning

1. During the TMRR Phase, the Program Manager will plan the balance of the program, prepare for subsequent decision points and phases, and submit an updated Acquisition Strategy for MDA approval. The updated Acquisition Strategy will describe the overall approach to acquiring the capability to include the program schedule, risks, funding, and the business strategy. The business strategy will describe the rationale for the contracting approach and how competition will be maintained throughout the program life cycle, and detail how contract incentives will be employed to support the Department’s goals.

2. To avoid re-planning and program disruptions, an updated Acquisition Strategy should be submitted to the MDA in time for approval prior to the preparation of the final RFPs for the next phase.

(g) Life-Cycle Considerations During the TMRR Phase

1. Planning for the sustainment phase should begin in this phase, when requirements trades and early design decisions are still occurring. The Program Manager will finalize sustainment requirements and decompose them into more detailed requirements to support the PDR and for the following uses:

a. Support system and product support package design trades.

b. Support test and evaluation (T&E) planning.

c. Provide performance metrics definition for product support contracts and organic support requirements.

d. Provide logistics requirements, workload estimates, and logistics risk assessment.

2. The Program Manager will integrate the product support design into the overall design process, and assess enablers that improve supportability, such as diagnostics and prognostics, for inclusion in the system performance specification. As the design matures, the Program Manager will ensure that life-cycle affordability is a factor in engineering and sustainment trades.

(5) CDD Validation and Configuration Steering Boards (CSBs)

(a) CDD Validation

1. During the TMRR Phase, the requirements validation authority will validate the CDD (or equivalent requirements document) for the program. This action will precede the Development RFP Release Decision Point and provides a basis for preliminary design activities and the PDR that will occur prior to Milestone B unless waived by the MDA. Active engagement between acquisition leadership, including the MDA, and the requirements leadership, including the validation authority (the JROC for MDAP and MAIS programs), during the development and review of proposed requirements trades is essential to ensuring that the validated requirements associated with the program continue to address the priorities of the DoD Component and the joint force in a cost effective and affordable way. The MDA (and CAE when the MDA is the DAE) will participate in the validation authorities’ review and staffing of the CDD (or equivalent requirements document) prior to validation, to ensure that requirements are technically achievable, affordable, and testable, and that requirements trades are fully informed by systems engineering trade-off analyses completed by the Program Manager or the DoD Component.

2. The KPPs and KSAs included in the validated CDD, will guide the efforts leading up to PDR, and inform the Development RFP Release Decision Point. As conditions warrant, changes to KPPs and KSAs may be proposed to the applicable capability requirements validation authority. All non-KPP requirements (when delegated by the capability requirements validation authority) are subject to cost-performance trades and adjustments to meet affordability constraints. Cost performance trades (for non-KPP requirements) will be coordinated with the cognizant capability requirements validation authority.

(b) CSBs. For ACAT I and ACAT IA programs, and following CDD Validation, the Acquisition Executive of each DoD Component will form and chair a CSB with broad executive membership including senior representatives from the Office of the USD(AT&L) (including the Assistant Secretary of Defense for Acquisition), the Joint Staff (Director of Force Structure, Resources, and Assessments, J-8), and the DoD Chief Information Officer; empowered representatives from the Service Chief of Staff and comptroller offices of the Military Department concerned; representatives from other Military Departments where appropriate; the Military Deputy to the CAE; the PEO; and other senior representatives from OSD and the DoD Component, as appropriate, in accordance with section 814 of Public Law (P.L.) 110-417 (Reference (f)).