DODI_5000.02_Operation_of_the_Defense_Acquisition_System_CH2.pdf

Enclosure 12 was incorporated and cancelled by DoDI 5000.75, published 2/2/2017. Issuance text in red italic strikethrough was added by Change 1 and deleted by Change 2.

The linked image cannot be displayed. The file may have been moved, renamed, or deleted. Verify that the link points to the correct file and location.

Department of Defense

INSTRUCTION

NUMBER 5000.02

January 7, 2015

Incorporating Change 1, Effective January 26, 2017 Incorporating Change 2, Effective February 2, 2017

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 (DoDD) 5000.01 (Reference (a)) and DoDD 5134.01 (Reference (cm)), 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)(cw).

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).

c. Assigns, reinforces, and prescribes procedures for acquisition responsibilities related to cybersecurity in the Defense Acquisition System.

d. Incorporates and cancels Directive-type Memorandum 17-001 (Reference (cl)).

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”).

DoDI 5000.02, January 7, 2015

Change 2, 02/02/2017 2

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 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 (DoD CIO), 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.

d. Secretaries of the Military Departments. In addition to the responsibilities described in paragraph 4.c., the Secretary of the Military Department acquiring an MDAP will represent the customer (i.e., the DoD Component(s) fielding the system). The Secretary concerned, in coordination with the Chief of the Military Service fielding the system, will balance resources against priorities and ensure appropriate trade-offs are made among cost, schedule, technical feasibility, and performance throughout the life of the program.

e. Chiefs of the Military Services. The Chiefs of the Military Services fielding MDAPs will represent the customer and, with the Secretary of the Military Department acquiring the MDAP, balance resources against priorities and ensure that appropriate trade-offs are made among cost, schedule, technical feasibility, and performance throughout the life of the program. The Chief concerned will advise the MDA on trade-offs before Milestones A and B. As part of the MDA’s Written Determination before Milestone A and Certification and Determination before Milestone B (these milestone information requirements are detailed in Table 2 in Enclosure 1), Change 2, 02/02/2017 3 the MDA must determine that the Chief and the Secretary concur with the cost, schedule, technical feasibility, and performance trade-offs that have been made.

5. PROCEDURES

a. Overview

(1) Program Categories. 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) Program Structure. 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.

(c) In accordance with Section 806 of Public Law 114-92 (Reference (d)), the Secretary of Defense may waive acquisition law or regulation to acquire a capability that would not otherwise be available to the DoD Components. This waiver authority may not be delegated.

Detailed provisions and requirements for this waiver are identified in Table 6 in Enclosure 1 of this instruction.

(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

Change 2, 02/02/2017 4 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 DoDI 5000.75 (Reference (cw)) 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 (OIPTs) at the DoD OSD 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.

Change 2, 02/02/2017 5

DAB review preparation will be streamlined and efficient. Staff members will be provided with the data needed to support the review in accordance with scheduled submission dates established throughout this instruction. They will work to minimize the overhead burden placed on the DoD Components, PEOs, program managers, and their staffs. Staff reviews will focus on the substance of the program’s content: affordability, requirements reasonableness, technical risk reduction, contracting strategy, schedule realism, testing provisions, funding adequacy, and future decision criteria. Reviewers will inform the DAB chairperson and MDA, the OIPT leader, and the Military Service concerned of potential DAB issues. The MDA will prioritize key cost, schedule and performance issues to be addressed at the DAB. The Military Service concerned will address administrative or advisory comments. Similar procedures will be used for DoD Component-level reviews.

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.01HI (Reference (d)(e)), 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 is described in Section 4 of Enclosure 12 of this instruction Reference (cw).

(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.

Change 2, 02/02/2017 6

(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.”

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

(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

Change 2, 02/02/2017 7

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 the direction in 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

Change 2, 02/02/2017 8

(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.

Change 2, 02/02/2017 9

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 and 13 provide additional information about Information Technology programs (described in Enclosure 11), Defense Business Systems (described in Enclosure 12), and Urgent Needs Capability Acquisitions (described in Enclosure 13);

cybersecurity is described in Enclosure 14. Defense Business Systems are described in Reference (cw).

(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.

Change 2, 02/02/2017 10

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.

Change 2, 02/02/2017 11

(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

Change 2, 02/02/2017 12

(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

Change 2, 02/02/2017 13

(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 development of technical solutions necessary for follow-on capability increments have some

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

Change 2, 02/02/2017 14 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.

Change 2, 02/02/2017 15

(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

Change 2, 02/02/2017 16

(f) Models 5 and 6: 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

Change 2, 02/02/2017 17

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

Change 2, 02/02/2017 18

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

Change 2, 02/02/2017 19

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. The Program Manager will review the information requirements for the upcoming decision event and may submit a request for waiver to statutory (when authorized by statute) and regulatory requirements to the to the cognizant approval authority (e.g., MDA, DoD CIO, DOT&E, DCAPE, JROC). The MDA will conduct a DAB planning meeting approximately 6 months before a DAB that includes RFP release decisions. The purpose of the meeting will be to ensure timely review of the business approach and other key elements of program planning before completion of the RFPs. An approved Acquisition Strategy will inform development of the final RFPs for the next phase of the program.

Change 2, 02/02/2017 20

(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 materiel 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. Table 2 of Enclosure 1 lists program information requirements and identifies approval authorities for those requirements. Program Manager requests to tailor or waive information requirements associated with the next decision event may be submitted to the MDA at this milestone and at each subsequent program milestone. When the MDA is the approval authority for an information requirement, the MDA may approve the Program Manager’s request to tailor or waive that requirement. When another official is the approval authority for an information requirement, the MDA may endorse, but cannot approve, a Program Manager’s request to tailor or waive that requirement. An ADM will document decisions by the MDA or other approval officials to tailor or waive information requirement.

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

Change 2, 02/02/2017 21 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 and DoD Component cost position 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, any Program Manager information requirement waiver requests, 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. Competitive

Change 2, 02/02/2017 22 risk reduction prototypes will be included if they will materially reduce engineering and manufacturing development risk at an acceptable cost. If competitive prototyping is not considered feasible, single prototypes at the system or subsystem level will be considered.

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) (f)), 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 materiel developer can substantiate that a preferred solution is feasible, affordable, and supportable; satisfies validated capability requirements; and has acceptable technical risk.

Critical…