Define Capability Needs
Engage Users, Assess Value
MVP, MVCR, Deployment
Ent Services, DevSecOps
Metrics and Reporting
DBS in SWP
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 Planning Phase
Acquisition Decision Memorandum (ADM)
Reference Source: DODI 5000.87 Section 3.1
The DA will document the decision and rationale for a program to use the software acquisition pathway in an acquisition decision memorandum.
Reference Source: OUSD(A&S) Guidance
An Acquisition Decision Memorandum (ADM) captures the decision authority’s key decisions, program direction, and action items. While there are no milestone reviews in the SWP, there are two key points where an ADM will commonly be used.
- The decision for an acquisition program to use the SWP requires an ADM (and draft CNS) per DODI 5000.87.
- Proceeding to the Execution Phase within the SWP requires the decision authority validate a program has done the appropriate planning, met statutory requirements, and is resourced to effectively begin (or continue) software development. This is done in an ADM.
Embracing the key tenets of the Adaptive Acquisition Framework, a decision authority is encouraged to simplify and tailor acquisition approaches while empowering program managers. The ADM may capture unique direction for the program to address high risk areas or provide additional details to its strategies and analysis. The strategic intent of the SWP is to balance speed with rigor, to proceed with sufficient strategies and risk without waiting for an exhaustive list of documentation. Therefore, a decision authority may authorize proceeding with a draft strategy and set expectations for a final version within a certain timeframe.
A decision authority may issue an ADM at any other point within a program’s lifecycle as conditions warrant. These may include, but are not limited to:
- Major pivot in program strategies due to change in requirements, contractors, performance, technologies, platforms, development approaches, budget/costs, or other factors.
- Additional direction or expectations following an Independent Program Review, audit, or related review that identified critical issues.
- Integration or merging with other programs, initiating a major new scope of work (with validated needs), or program termination.
The ADM Template provides two examples for SWP programs and decision authorities to tailor to capture the key decisions, direction, and actions.
The best way to get a project done faster is to start sooner.