DODI 5000.02 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 An acquisition program that is designated by the USD(AT&L) as an MDAP; or is estimated to require an eventual total expenditure for RDT&E including all planned increments, of more than $480 million in FY 2014 constant dollars or, for procurement, including all planned increments, of more than $2.79 billion in FY 2014 constant dollars., a MAIS program, or a Major Weapons Systems A combination of elements that shall function together to produce the capabilities required to fulfill a mission need, including hardware, equipment, software, or any combination thereof, but excluding construction or other improvements to real property. A system shall be considered a major system if it is estimated by the DoD component head to require an eventual total expenditure for RDT&E of more than $185 million in FY14 constant dollars, or for procurement of more than $835 million in FY14 constant dollars, or is designated as major by the DoD component head.; and the determination that the program is an  Information System A combination of computer hardware, computer software, data, or telecommunications that performs functions such as collecting, processing, storing, transmitting, and displaying information. Excluded are computer resources, both hardware and software, that are an integral part of a weapon or weapon system; used for highly sensitive classified programs (as determined by the Secretary of Defense); used for other highly sensitive IT programs (as determined by the DoD CIO); or determined by the DAE, that is, the USD(AT&L), or designee to be better overseen as a non-AIS program., a Defense Business Systems (DBS) An information system, other than a national security system, operated by, for, or on behalf of DoD, including financial systems, management information systems, financial data feeder systems, and the information technology and cybersecurity infrastructure used to support business activities, such as contracting, pay and personnel management systems, some logistics systems, financial planning and budgeting, installations management, and human resource management. , 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 A capability required to meet an organization’s roles, functions, and missions in current or future operations. To the greatest extent possible, capability requirements are described in relation to tasks, standards, and conditions in accordance with the Universal Joint Task List or equivalent DOD Component Task List. If a capability requirement is not satisfied by a capability solution, there is also an associated capability gap. A requirement is considered to be ‘draft’ or ‘proposed’ until validated by the appropriate authority..

(b) When there is a strong threat The sum of the potential strengths, capabilities, and strategic objectives of any adversary that can limit U.S. mission accomplishment or reduce force, system, or equipment effectiveness. It does not include (a) natural or environmental factors affecting the ability or the system to function or support mission accomplishment, (b) mechanical or component failure affecting mission accomplishment unless caused by adversary action, or (c) program issues related to budgeting, restructuring, or cancellation of a program. -based or operationally driven need to field Fielding a weapon system by placing it into operational use with units in the field/fleet. 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 An acquisition program that is designated by the USD(AT&L) as an MDAP; or is estimated to require an eventual total expenditure for RDT&E including all planned increments, of more than $480 million in FY 2014 constant dollars or, for procurement, including all planned increments, of more than $2.79 billion in FY 2014 constant dollars., MAIS, or Major System A combination of elements that shall function together to produce the capabilities required to fulfill a mission need, including hardware, equipment, software, or any combination thereof, but excluding construction or other improvements to real property. A system shall be considered a major system if it is estimated by the DoD component head to require an eventual total expenditure for RDT&E of more than $185 million in FY14 constant dollars, or for procurement of more than $835 million in FY14 constant dollars, or is designated as major by the DoD component head.). MDAPs are either estimated to achieve the statutorily defined MDAP cost threshold, or are designated as an MDAP by the  DAE The individual responsible for supervising the Defense Acquisition System. The DAE takes precedence on all acquisition matters after the Secretary of Defense and the Deputy Secretary of Defense. . 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  A system in which software represents the largest segment in one or more of the following criteria: system development cost, system development risk, system functionality, or development time. 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 Systems (DBS) An information system, other than a national security system, operated by, for, or on behalf of DoD, including financial systems, management information systems, financial data feeder systems, and the information technology and cybersecurity infrastructure used to support business activities, such as contracting, pay and personnel management systems, some logistics systems, financial planning and budgeting, installations management, and human resource management. . These designations are defined in statute and have procedural and policy consequences. Enclosure 11 addresses Information Technology Any equipment or interconnected system or subsystem of equipment, used in the automatic acquisition, storage, analysis, evaluation, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the executive agency, if the equipment is used by the executive agency directly, or is used by a contractor under a contract with the executive agency that requires the use of: (1) that equipment, (2) that equipment to a significant extent in the performance of a service or the furnishing of a product. It includes computers, ancillary equipment, peripheral equipment designed to be controlled by the central processing unit of a computer, software, firmware and similar procedures, services, and related resources. It does not include any equipment acquired by a federal contractor incidental to a federal contract., and DoDI 5000.75 (Reference (cw)) describes Defense Business Systems.

(4) Program Decision Reviews and Milestones. The point at which a recommendation is made and approval sought regarding starting or continuing an acquisition program, i.e., proceeding to the next phase. Milestones established by DoDI 5000.02 are: Milestone A that approves entry into the Technology Maturation and Risk Reduction phase; Milestone B that approves entry into the Engineering and Manufacturing Development phase; and Milestone C that approves entry into the Production and Deployment phase. 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 MDAs is the sole and final decision authority. Staff members and staff organizations support and facilitate the MDAs execution of that authority.

(b) The Defense Acquisition Board (DAB) will advise the DAE The individual responsible for supervising the Defense Acquisition System. The DAE takes precedence on all acquisition matters after the Secretary of Defense and the Deputy Secretary of Defense. on critical acquisition decisions when the DAE is the MDA. The DAE or designee will chair the DAB. An Acquisition Decision Memorandum A memorandum signed by the Milestone Decision Authority that documents decisions and direction resulting from milestone and other major decision point reviews. will document decisions resulting from reviews. Similar procedures will be established at the Component level for use by other MDAs.

(c) Program Managers  Designated individual with responsibility for and authority to accomplish program objectives for development, production, and sustainment to meet the user’s operational needs. The PM shall be accountable for credible cost, schedule, and performance reporting to the Milestone Decision Authority., under the supervision of Program Executive Officers (PEOs) A military or civilian official assigned program responsibilities for Acquisition Category I and IA and sensitive classified programs, or for any other program determined by the Component Acquisition Executive to require dedicated executive management. and CAEs Secretaries of the military departments or heads of agencies with the power of redelegation. In the military departments, the officials delegated as CAEs (also called SAEs are respectively, the ASA(AL&T); the ASN(RD&A); and the ASAF(A)). The CAEs are responsible for all acquisition functions within their components. This includes both the SAEs for the military departments and acquisition executives in other DoD components, such as SOCOM and DLA, which also have acquisition management responsibilities., are expected to design acquisition programs, prepare programs for decisions, and execute approved program plans.

(d) Overarching Integrated Product Teams Team composed of representatives from appropriate functional disciplines working together to build successful programs, identify and resolve issues, and make sound and timely recommendations to facilitate decision-making. There are three types of IPTs: Overarching IPT that focus on strategic guidance, program assessment, and issue resolution; Working-level IPT that identify and resolve program issues, determine program status, and seek opportunities for acquisition reform; and Program-level IPT that focus on program execution and may include representatives from both government and industry after contract award. (OIPTs) at the 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 Describes the Program Manager’s plan to achieve program execution and programmatic goals across the entire program life cycle. Summarizes the overall approach to acquiring the capability. Contains sufficient detail to allow senior leadership and the MDA to assess whether the strategy makes good business sense, effectively implements laws and policies, and reflects management’s priorities. Once approved by the MDA, the Acquisition Strategy provides a basis for more detailed planning. The strategy evolves over time and should continuously reflect the current status and desired goals of the program., Systems Engineering Plan (SEP)  An acquisition program’s primary technical planning document. It serves as the blueprint for the integration and management of technical processes and design development in order to define and balance system performance, cost, schedule, risk, and security within the program and throughout its life cycle. The SEP is a living document in which Systems Engineering planning should be kept current and fidelity should evolve as the program progresses through each acquisition phase. Test and Evaluation Master Plan (TEMP)  Documents the overall structure and objectives of the T&E program and articulates the necessary resources to accomplish each phase of test. It provides a framework within which to generate detailed T&E plans and documents schedule and resource implications associated with the T&E program. The TEMP also identifies the necessary DT&E, OT&E, and Live Fire Test & Evaluation activities, and provides a clear roadmap connecting evaluation objectives, test measures, requirements, test methodologies, decision points, test events, and resources. For multi-Service or joint programs, a single integrated TEMP is required. Life-Cycle Sustainment Plan (LCSP) Initially prepared for Milestone A and updated for the Development RFP Release Decision Point, Milestone B, Milestone C, Full-Rate Production Decision Review and at least every 5 years after a system’s IOC. It contains the results of life cycle sustainment planning accomplished during the MSA phase and the TPRR phase and spans the system’s entire life cycle from Milestone A to disposal. The LCSP addresses how the PM and other organizations will acquire and maintain oversight of the fielded system.) 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) 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 A military or civilian official assigned program responsibilities for Acquisition Category I and IA and sensitive classified programs, or for any other program determined by the Component Acquisition Executive to require dedicated executive management., program managers  Designated individual with responsibility for and authority to accomplish program objectives for development, production, and sustainment to meet the user’s operational needs. The PM shall be accountable for credible cost, schedule, and performance reporting to the Milestone Decision Authority., 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” A capability required to meet an organization’s roles, functions, and missions in current or future operations. To the greatest extent possible, capability requirements are described in relation to tasks, standards, and conditions in accordance with the Universal Joint Task List or equivalent DOD Component Task List. If a capability requirement is not satisfied by a capability solution, there is also an associated capability gap. A requirement is considered to be ‘draft’ or ‘proposed’ until validated by the appropriate authority. 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 A program is executable if the program manager has adequate near-term approved funding 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 A capability required to meet an organization’s roles, functions, and missions in current or future operations. To the greatest extent possible, capability requirements are described in relation to tasks, standards, and conditions in accordance with the Universal Joint Task List or equivalent DOD Component Task List. If a capability requirement is not satisfied by a capability solution, there is also an associated capability gap. A requirement is considered to be ‘draft’ or ‘proposed’ until validated by the appropriate authority. 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 1. The review and approval of capability requirement documents by a designated validation authority. 2. The process by which the contractor (or as otherwise directed by the DoD Component procuring activity) tests a publication/technical manual for technical accuracy and adequacy. 3. The process of evaluating a system or software component during, or at the end of, the development process to determine whether it satisfies specified requirements. joint military requirements for MDAP An acquisition program that is designated by the USD(AT&L) as an MDAP; or is estimated to require an eventual total expenditure for RDT&E including all planned increments, of more than $480 million in FY 2014 constant dollars or, for procurement, including all planned increments, of more than $2.79 billion in FY 2014 constant dollars. and MAIS programs, and less-than-MDAP or MAIS programs designated either as “JROC Interest” or “Joint Capabilities Board The JCB is a board below the Joint Requirements Oversight Council (JROC) and provides review and endorsement of documents and adjudication of lower level issues prior to validation by the JROC. The JCB has validation authority for Joint Capabilities Integration and Development System documents with a Joint Staffing Designator of “JCB Interest.” The JCB is chaired by the Joint Staff Director, J-8. It is comprised of general or flag officers, or government civilian equivalent, from the Services and Combatant Commands.“. When JRCO validation authority is delegated in accordance with the Joint Capabilities Integration and Development System (JCIDS)  Supports the Chairman of the Joint Chiefs of Staff and the Joint Requirements Oversight Council in identifying, assessing, and prioritizing joint military capability requirements. process in Chairman of the Joint Chiefs of Staff Instruction 3170.01I (Reference (e)), the DoD Components The Office of the Secretary of Defense; the military departments; the Chairman, Joint Chiefs of Staff and the Joint Staff; the combatant commands; the Office of the Inspector General of the DoD; the defense agencies; DoD field activities; and all other organization entities within the DoD.  will use variations of the JCIDS to validate their requirements. The validation authority for Defense Business System An information system, other than a national security system, operated by, for, or on behalf of DoD, including financial systems, management information systems, financial data feeder systems, and the information technology and cybersecurity infrastructure used to support business activities, such as contracting, pay and personnel management systems, some logistics systems, financial planning and budgeting, installations management, and human resource management. capability requirements is described in Reference (cw).

(b) Leadership of the acquisition and budget processes will be involved as advisors to the validation authority The designated authority for validation of Joint Capabilities Integration and Development System capability requirement documents. The Joint Requirements Oversight Council is the ultimate validation authority unless otherwise delegated to a subordinate board or to a designated validation authority in a Service, Combatant Command, or other DOD Component. The validation authority is dependent on the Joint Staffing Designator of the document. during consideration of initial or adjusted  validation of capability requirements A capability required to meet an organization’s roles, functions, and missions in current or future operations. To the greatest extent possible, capability requirements are described in relation to tasks, standards, and conditions in accordance with the Universal Joint Task List or equivalent DOD Component Task List. If a capability requirement is not satisfied by a capability solution, there is also an associated capability gap. A requirement is considered to be ‘draft’ or ‘proposed’ until validated by the appropriate authority. to ensure coordination across the three processes. image

(c) The titles of capability requirements A capability required to meet an organization’s roles, functions, and missions in current or future operations. To the greatest extent possible, capability requirements are described in relation to tasks, standards, and conditions in accordance with the Universal Joint Task List or equivalent DOD Component Task List. If a capability requirement is not satisfied by a capability solution, there is also an associated capability gap. A requirement is considered to be ‘draft’ or ‘proposed’ until validated by the appropriate authority. documents supported by JCIDS Supports the Chairman of the Joint Chiefs of Staff and the Joint Requirements Oversight Council in identifying, assessing, and prioritizing joint military capability requirements. 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)  The Initial Capabilities Document documents the DoD need for a materiel approach to satisfy specific capability gaps. The ICD essentially summarizes any capability analysis and defines those gaps in terms of the functional area; the relevant range of military operations; desired effects; timeframe; and recommendations. , Capability Development Document (CDD)  A document that captures the information necessary to develop a proposed program(s), normally using an evolutionary acquisition strategy. The CDD outlines an affordable increment of militarily useful, logistically supportable, and technically mature capability. The CDD may define multiple increments if there is sufficient definition of the performance attributes (key performance parameters, key system attributes, and other attributes) to allow approval of multiple increments. The CDD supports a Milestone B decision review., or Capability Production Document (CPD) A document that addresses the production elements specific to a single increment of an acquisition program. The CPD must be validated and approved before a Milestone C decision review. The refinement of performance attributes and Key Performance Parameters is the most significant difference between the Capability Development Document (CDD) and CPD. The CPD format is contained in DoD 5000.02 and CJCSI 3170.01H, the text will use the generic terms, “validation 1. The review and approval of capability requirement documents by a designated validation authority. 2. The process by which the contractor (or as otherwise directed by the DoD Component procuring activity) tests a publication/technical manual for technical accuracy and adequacy. 3. The process of evaluating a system or software component during, or at the end of, the development process to determine whether it satisfies specified requirements. capability requirements document” or “equivalent requirements document.”

(d) Capability requirements A capability required to meet an organization’s roles, functions, and missions in current or future operations. To the greatest extent possible, capability requirements are described in relation to tasks, standards, and conditions in accordance with the Universal Joint Task List or equivalent DOD Component Task List. If a capability requirement is not satisfied by a capability solution, there is also an associated capability gap. A requirement is considered to be ‘draft’ or ‘proposed’ until validated by the appropriate authority. 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 Established by CAE to review all requirements and significant technical configuration changes that have potential to impact cost and schedule of ACAT I and IA programs. Generally, changes will be rejected and deferred to future increments unless funds are identified and schedule impacts are addressed. The Program Manager, in consultation with the PEO, will on at least an annual basis, identify and propose to the CSB a set of descoping options that reduce program cost and/or moderate requirements. Final decisions on descoping option implementation will be coordinated with the capability requirements officials. Required by DoDI 5000.02 for ACAT I and IA programs; required by public law (FY 2009 NDAA, section 814) for ACAT I programs., 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 The individual responsible for supervising the Defense Acquisition System. The DAE takes precedence on all acquisition matters after the Secretary of Defense and the Deputy Secretary of Defense.  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 The Office of the Secretary of Defense; the military departments; the Chairman, Joint Chiefs of Staff and the Joint Staff; the combatant commands; the Office of the Inspector General of the DoD; the defense agencies; DoD field activities; and all other organization entities within the DoD. , 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.

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. image (b) Generic Acquisition Milestones The point at which a recommendation is made and approval sought regarding starting or continuing an acquisition program, i.e., proceeding to the next phase. Milestones established by DoDI 5000.02 are: Milestone A that approves entry into the Technology Maturation and Risk Reduction phase; Milestone B that approves entry into the Engineering and Manufacturing Development phase; and Milestone C that approves entry into the Production and Deployment phase. and Decision Points

(1) Need Identification, called the Materiel Development Decision A review that is the formal entry point into the acquisition process and is mandatory for all programs. A successful MDD may approve entry into the acquisition management system at any point consistent with phase-specific and statutory requirements but will normally be followed by a MSA phase. The principal documents at this decision point are the ICD and Analysis of Alternatives Study Guidance and Plan. A successful MDD normally does not mean that a new acquisition program has been initiated. 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) The third phase of the Defense Acquisition System, usually beginning after MS B, as defined and established by DoDI 5000.02. The purpose of the EMD Phase is to develop, build, and test a product to verify that all operational and derived requirements have been met and to support production or deployment decisions. EMD completes all needed hardware and software detailed design; systemically retires any open risks; builds and tests prototypes or first articles to verify compliance with capability requirements; and prepares for production or deployment. It includes the establishment of the initial product baseline for all configuration items. 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 Key decision point 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 provide a basis for preliminary design activities and the PDR that will occur prior to Milestone B (unless waived by the MDA). The MDA (and CAE when the MDA is the DAE) will participate in the validation authority’s 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. Decision by DoD); (2) a decision to release a solicitation for development to industry, called the Development Request for Proposals (RFP) Release Decision Point Considered the critical decision point in an acquisition program in the sense that this is the last point at which significant changes can be made without a major disruption. The MDA reviews the results of the TMRR Phase prototyping effort and key related planning documents for the EMD phase. Following a successful Development RFP Release decision, the MDA authorizes release of the final RFP and source selection for the EMD contract. (The EMD contract cannot be awarded until after a successful Milestone B.) The MDA may also authorize the release of the RFP for LRIP or Limited Deployment options for applicable programs. ; 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 The process of converting raw materials by fabrication into required material. It includes the functions of production-scheduling, inspection, Quality Control, and related processes. 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 1. A determination that the Life Cycle Cost of an acquisition program is in consonance with the long-range investment and force structure plans of the DoD or individual DoD components. 2. Conducting a program at a cost constrained by the maximum resources that the DoD or DoD component can allocated to that capability. and executable.

a. Requirements Decision Point (CDD Validation Key decision point 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 provide a basis for preliminary design activities and the PDR that will occur prior to Milestone B (unless waived by the MDA). The MDA (and CAE when the MDA is the DAE) will participate in the validation authority’s 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. 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 Considered the critical decision point in an acquisition program in the sense that this is the last point at which significant changes can be made without a major disruption. The MDA reviews the results of the TMRR Phase prototyping effort and key related planning documents for the EMD phase. Following a successful Development RFP Release decision, the MDA authorizes release of the final RFP and source selection for the EMD contract. (The EMD contract cannot be awarded until after a successful Milestone B.) The MDA may also authorize the release of the RFP for LRIP or Limited Deployment options for applicable programs. . 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 The defense industry (private sector contractors) includes large and small organizations providing goods and services to DoD. Their perspective is to represent interests of the owners or stockholders. .

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) The first part of the P&D phase. LRIP is intended to result in completion of manufacturing development in order to ensure adequate and efficient manufacturing capability and to produce the minimum quantity necessary to provide production or production-representative articles for IOT&E; establish an initial production base for the system; and permit an orderly increase in the production rate for the system, sufficient to lead to Full Product Rate upon successful completion of operational testing., called Milestone C by DoD, or Limited Deployment; and (2) the Full-Rate Production 1. The second effort part of the P&D phase as defined and established by DoDI 5000.02 after Low-Rate Initial Production and following a successful Full-Rate Production Decision Review. The system is produced at rate production and deployed to the field or fleet. This phase overlaps the O&S phase since fielded systems are operated and supported (sustained) while Full-Rate Production is ongoing. 2. The production level contracted for once the production process has been stabilized. Ideally, it would coincide with the Economics Production Rate. 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 The point at which a recommendation is made and approval sought regarding starting or continuing an acquisition program, i.e., proceeding to the next phase. Milestones established by DoDI 5000.02 are: Milestone A that approves entry into the Technology Maturation and Risk Reduction phase; Milestone B that approves entry into the Engineering and Manufacturing Development phase; and Milestone C that approves entry into the Production and Deployment phase. 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), Urgent Capability Acquisitions (described in Enclosure 13); cybersecurity is described in Enclosure 14.

(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 The manner in which certain core issues (program definition, program structure, program design, program assessments, and periodic reporting) are addressed in a particular program. The Milestone Decision Authority seeks to minimize the time it takes to satisfy an identified need consistent with common sense, sound business management practice, applicable laws and regulations, and the time-sensitive nature of the requirement itself. Tailoring may be applied to various aspects of the acquisition process, including program documentation, acquisition phases, the time and scope of decision reviews, supportability analysis, and decision levels consistent with all applicable statutory requirements. 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). figure3 (c) Model 2: Defense Unique Software Intensive Program A system in which software represents the largest segment in one or more of the following criteria: system development cost, system development risk, system functionality, or development time. . 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 Fielding a weapon system by placing it into operational use with units in the field/fleet. 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. figure4 (d) Model 3: Incrementally Deployed Software Intensive Program A system in which software represents the largest segment in one or more of the following criteria: system development cost, system development risk, system functionality, or development time. . Figure 5 is a model that has been adopted for many Defense Business Systems An information system, other than a national security system, operated by, for, or on behalf of DoD, including financial systems, management information systems, financial data feeder systems, and the information technology and cybersecurity infrastructure used to support business activities, such as contracting, pay and personnel management systems, some logistics systems, financial planning and budgeting, installations management, and human resource management. . It also applies to upgrades to some command and control systems or weapons systems software where deployment Fielding a weapon system by placing it into operational use with units in the field/fleet. of the full capability will occur in multiple increments In the context of Joint Capabilities Integration and Development System, a militarily useful and supportable operational capability that can be effectively developed, produced, acquired, deployed and sustained. Each increment of capability will have its own set of threshold and objective values set by the user. 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. figure5 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 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 The point at which a recommendation is made and approval sought regarding starting or continuing an acquisition program, i.e., proceeding to the next phase. Milestones established by DoDI 5000.02 are: Milestone A that approves entry into the Technology Maturation and Risk Reduction phase; Milestone B that approves entry into the Engineering and Manufacturing Development phase; and Milestone C that approves entry into the Production and Deployment phase. 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 Program-specific accomplishments that must be satisfactorily demonstrated before a program can progress further in the current acquisition phase or transition to the next acquisition phase. Exit criteria normally are selected to track progress in important technical, schedule, or management risk areas. They serve as gates that, when successfully passed or exited, demonstrate that the program is on track to achieve its final program goals and should be allowed to continue additional activities within an acquisition phase or be considered for continuation into the next acquisition phase. Exit criteria are some level of demonstrated performance outcome, the accomplishment of some process at some level of efficiency, or successful accomplishment of some event, or some other criterion that indicates that aspect of the program is progressing satisfactorily. Exit criteria are documented in the ADM. , 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 1. Series of things to be done in a specific sequence within a given period of time. 2. A timetable. 3. A listing of activities and events organized by time. 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 The manner in which certain core issues (program definition, program structure, program design, program assessments, and periodic reporting) are addressed in a particular program. The Milestone Decision Authority seeks to minimize the time it takes to satisfy an identified need consistent with common sense, sound business management practice, applicable laws and regulations, and the time-sensitive nature of the requirement itself. Tailoring may be applied to various aspects of the acquisition process, including program documentation, acquisition phases, the time and scope of decision reviews, supportability analysis, and decision levels consistent with all applicable statutory requirements. 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. figure6(f) Models 5 and 6: Hybrid Acquisition Programs

1. Figure 7 is a model depicting how a major weapon system Items that can be used directly by the Armed Forces to carry out combat missions. combines hardware development as the basic structure with a software intensive A system in which software represents the largest segment in one or more of the following criteria: system development cost, system development risk, system functionality, or development time. 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 The point at which a recommendation is made and approval sought regarding starting or continuing an acquisition program, i.e., proceeding to the next phase. Milestones established by DoDI 5000.02 are: Milestone A that approves entry into the Technology Maturation and Risk Reduction phase; Milestone B that approves entry into the Engineering and Manufacturing Development phase; and Milestone C that approves entry into the Production and Deployment phase., but software development will often dictate the pace of program execution and must be tightly integrated and coordinated with hardware development decision points. figure7 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) In general, attained when selected units and/or organizations in the force structure scheduled to receive a new system have received it and have the ability to employ and maintain it. The specifics for any particular system IOC are defined in that system’s Capability Development Document and Capability Production Document. . 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 The third phase of the Defense Acquisition System, usually beginning after MS B, as defined and established by DoDI 5000.02. The purpose of the EMD Phase is to develop, build, and test a product to verify that all operational and derived requirements have been met and to support production or deployment decisions. EMD completes all needed hardware and software detailed design; systemically retires any open risks; builds and tests prototypes or first articles to verify compliance with capability requirements; and prepares for production or deployment. It includes the establishment of the initial product baseline for all configuration items. 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.

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