How to use this site
Each page in this pathway presents a wealth of curated knowledge from acquisition policies, guides, templates, training, reports, websites, case studies, and other resources. It also provides a framework for functional experts and practitioners across DoD to contribute to the collective knowledge base. This site aggregates official DoD policies, guides, references, and more.
DoD and Service policy is indicated by a BLUE vertical line.
Directly quoted material is preceeded with a link to the Reference Source.
Reference Source: DODI 5000.87 Section 3.2
The purpose of this phase is to better understand the users’ needs and plan the approach to deliver software capabilities to meet those needs. The planning phase will be guided by a draft CNS developed by the operational community. The sponsor will approve the CNS before the execution phase starts.
- The program office and related stakeholders will actively engage users throughout the software lifecycle to understand their mission deficiencies, required enhancements to existing operational capabilities, cybersecurity requirements, features, interoperability needs, legacy interfaces, intelligence needs, threat intelligence, and other desired attributes.
- All required capabilities in the CNS should be prioritized to effectively guide the software development.
- Periodic review of the CNS should occur at least as often as each value assessment to determine if updates are warranted.
During the planning phase, the DA will select a PM and may establish a new program office or assign an existing program office to shape and plan the software acquisition. The PM will develop a constrained, tailored set of strategies to acquire, develop, and deliver the software capabilities, and will obtain the necessary resources (e.g., people, funding, technology) to effectively execute the strategies.
The program should begin developing the software design and architecture, leveraging existing enterprise services as much as possible.
- The program will also consider the development environment, processes, automated tools, designs, architectures, and implications across the broader portfolio, component, and joint force.
- The chosen software development methodology will incorporate continuous testing and evaluation, resiliency, and cybersecurity, with maximum possible automation, as persistent requirements and include a risk-based lifecycle management approach to address software vulnerabilities, supply chain and development environment risk, and intelligence threats throughout the entire lifecycle.
- The program may develop prototypes or initial capabilities to explore possible solutions, architecture options and solicit user and stakeholder feedback.
The DA will validate there are appropriate strategies, analysis, and resources are in place to successfully transition from the planning phase to the execution phase. The approved artifacts required to enter the execution phase include the CNS, user agreement (UA), acquisition strategy, test strategy, and cost estimate. The DA may have a meeting with key stakeholders to review the program’s strategies to make the decision. Programs using the embedded software
path align their strategies with the programs into which they will be integrated.
Programs using the software acquisition pathway will be identified in component and DoD program lists and databases within 60 calendar days of initiating the planning phase in accordance with DoD’s implementation of Section 913 of Public Law 115-91 on acquisition data analysis.
Information Required to Enter the Execution Phase
Reference Source: USD(A&S) Guidance
|Capability Needs Statement||Regulatory||DODI 5000.87|
|User Agreement||Regulatory||DODI 5000.87|
|Acquisition Strategy (acquisition approach, risk management, business strategy, contract strategy, IP strategy, logistics/sustainment, etc.)||
Statutory for major programs (> ACAT II)
Regulatory for others
|Cybersecurity Strategy (may be part of Acquisition Strategy or standalone document)||
Statutory for Mission Critical and Mission Essential IT programs
Regulatory for others
Test Strategy (may be part of Acquisition Strategy)
Programs on DOT&E Oversight list may require a Test and Evaluation Management Plan (TEMP)
|Intellectual Property Strategy (may be part of Acquisition Strategy)||Regulatory||DODI 5000.87|
|Product Support Strategy including Business Case Analysis (may be part of Acquisition Strategy)||Regulatory||DODI 5000.87|
|Information Support Plan (may be part of Acquisition Strategy)||Regulatory||DODI 8330.01|
|Bandwidth Requirements Review (part of ISP or other related document)||Statutory for Major Systems
Regulatory for Others
|§1047, P.L. 110-417|
|Program Cost Estimate and Independent Cost Estimate||CAPE ICE for programs > ACAT II unless delegated||DODI 5000.87 DODI 5000.73|
|Cost Analysis Requirements Document||Regulatory||DODI 5000.73|
|Clinger Cohen Act (CCA) Compliance (see CCA table)||Statutory||DODI 5000.82, Subtitle III of Title 40|
Under certain scenarios, some statutory information may be required; e.g.:
- Benefit Analysis and Determination (Part of ACQ Strat)
- Consideration of Technology Issues (Part of ACQ Strat)
- Contract-type Determination (Part of ACQ Strat)
- Cooperative Opportunities (Part of ACQ Strat)
- Cybersecurity Strategy (required by 5000.87 regardless)
- DOT&E Report on Initial Operational Test and Evaluation (IOT&E)
- Independent Cost Estimate (required by 5000.87 regardless)
- IP Strategy (Part of ACQ Strat)
- Market Research (Part of ACQ Strat)
- Operational Test Plan (OTP)