Define Capability Needs
Engage Users, Assess Value
MVP, MVCR, Deployment
Ent Services, DevSecOps
Metrics and Reporting
DBS in SWP
SWP Quick Start Primer
SWP Artifact Templates
SW In NDAAs
SWP Quick Start Primer
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: USD(A&S) Guidance
This SWP quick start primer is to assist acquisition professionals in using the Software Acquisition Pathway. It provides the core items needed to enter the Planning Phase and quickly move into the Execution Phase. Programs that are transitioning from another pathway may have already satisfied some of the below elements and can accelerate into the Execution Phase. Those transitioning programs should consider adopting SWP artifacts in lieu of legacy documents if they are more compatible with the proposed acquisition.
1. Establish a program team.
The Decision Authority should establish a program team early – before requirements have been formally established or program artifacts developed – to generate the required program artifacts and establish the software development processes that will be used to manage the effort.
2. Train the program team.
The program team should obtain Agile and DevSecOps training to provide context for developing program artifacts and establishing program processes, and ultimately executing a modern software development program. DAU offers some relevant courses to start: Training (see Resources)
3. Define overarching requirements.
The program should collaborate with Operational Sponsor(s) to define the initial set of overarching requirements. These requirements should be high-level enough to provide the vision for the program and enable prioritization of more granular needs as part of the user governance processes. This can be captured in a Capability Needs Statement, Software Initial Capabilities Document or other document. If a program has an existing requirements document that is still current, it can be used to enter the Execution Phase. Additional details, including templates, can be found here: Define Capability Needs
4. Set user governance process.
The program should collaborate with Operational Sponsor(s) to establish the user engagement processes that will be used to manage and execute the program and document in a User Agreement. Early and often user feedback is critical for an agile software program and time spent setting these expectations will pay dividends later. More details can be found here: User Agreement
5. Identify architectural approach.
The program should identify the high-level software architecture that will be leveraged to support the continuous engineering of capability. The team should employ experienced software architects who will help implement architectural principles and patterns critical for software programs, such as open systems, modularity, and security patterns. The architecture may be captured in various internal technical documents but only needs to be formal approved as part of the Information Support Plan. Additional details can be found here: Architecture and Interoperability
6. Define the cybersecurity strategy.
The program should collaborate with the cybersecurity community on a balanced approach that will ensure secure development, software assurance and secure lifecycle management while retaining the ability to rapidly deploy capability. The goal should be to move towards gaining a continuous or near-continuous Authority to Operate. More details here: Cybersecurity
7. Capture the testing plan.
The program should begin collaborating with the appropriate test organizations to gauge expectations, identify the resources required, and craft streamlined processes to ensure rapid, high-quality, and secure software releases are delivered to military users. More details here: Test Strategy
8. Articulate the infrastructure.
The program should identify the infrastructure required to implement the architecture, cybersecurity strategy and test plans to include cloud infrastructure, software development platforms, containers, virtual machines, monitoring tools, and test automation tools. The SWP encourages using enterprise services to accelerate program stand-up. More details here: Enterprise Services & DevSecOps
9. Craft the contracting strategy.
The program should work closely with the contracting office supporting the acquisition to craft a flexible and modular approach to acquire the right expertise to develop the necessary software capabilities. The contracting strategy may use multiple approaches and evolve with the program. More details here: Contracting Strategy
10. Mold a product support strategy.
The program should recognize that there is no clear sustainment phase on an agile software program. However, each program will have unique considerations and the long-term strategy should be factored into program planning. More details here: Product Support Strategy
11. Shape intellectual property approach.
The program should develop a clear approach for managing different types of intellectual property. It should require delivery of key artifacts and technical data at defined points to the government. A preference should be maintained for unrestricted or open-source software. More details here: IP Strategy
12. Scope the MVP / plan for MVCR.
The program should develop an initial backlog based on known requirements and work with the user community to scope an MVP that will be used to gain feedback and inform the development process. The program should also begin planning for the MVCR after prioritizing the backlog and establishing a near-term roadmap for the Execution Phase. The processes used to do this should be documented in the User Agreement. This does not need to be a comprehensive plan but should provide insight to the Decision Authority on what software features the program would immediately work towards in the Execution Phase. More details here: MVP and MVCR
13. Develop initial cost estimate.
The program should work with the cost estimating team as early as possible to begin drafting an initial cost estimate that reflects Agile cost estimating principles and captures work to inform the 5-year budget planning cycle. Larger programs may have to work with OSD CAPE to either request delegation or to conduct the Independent Cost Estimate. More details here: Cost Estimation
14. Identify program metrics.
The program should identify metrics to manage the performance, progress, speed, cybersecurity, and quality of the development. These should be initially captured in the acquisition strategy and then incorporated into program execution processes. These metrics are intended to provide the technical team, the PM and the Decision Authority with insight into software development performance. There is no standardized approach here and different metrics may be applicable for different levels of reporting (i.e. the technical team will probably have different needs than the PEO or SAE). Expectations should be discussed as part of crafting the acquisition strategy. More details here: Metrics and Reporting
15. Address oversight.
While not every program will be able to choose the level of oversight demanded by Decision Authorities, SWP programs should strive to make the case for delegation of certain decisions to maximize the effectiveness of agile methodologies. Programs can propose interim progress reviews to encourage delegation while also ensuring Decision Authorities have the appropriate level of insight into program progress.
16. Coalesce acquisition strategy.
The program needs to work collaboratively with the respective functional communities to coalesce individual strategies and plans into a cohesive acquisition strategy that captures the key processes that will be used to execute the program. More details here: Acquisition Strategy
17. Complete reporting.
The OSD SWP team requests that any program approved to use the SWP, send an e-mail to their Service HQ SWP representative and the OSD SWP mailbox at email@example.com with the below information. This is for tracking purposes only and once Service acquisition reporting systems capture SWP data elements, will no longer be necessary.
- Program Name (Long Name and Short Name)
- SWP Entry Approval Date
- Lead Component
- Program Description
- Decision Authority (Organization, not Name)
- Program Manager (Name and Contact Info)
- Software Path (Application, Embedded, Business System)
- Planned First Funds Obligated Date (Month/Year)
- Planned MVCR Date (Month/Year)
- Program Estimate Total (ROM)
The OSD SWP team has minimized reporting requirements to those data elements that provide enterprise-level insight to senior acquisition leaders and external stakeholders. The OSD SWP team requests submission on a semi-annual basis for those data elements (April and October). Any other metrics adopted by programs are for their internal use and do not need to be reported.
Only an Acquisition Decision Memorandum (ADM) and a draft requirements document are needed to enter the Planning Phase.
Acquisition Decision Memorandum (ADM)
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 following documents for the Execution Phase should represent an initial program position but be regularly updated as the program matures.
Documentation needed to ENTER the Execution Phase
Reference Source: USD(A&S) Guidance
|Capability Needs Statement or Other Approved Requirements Document||Regulatory||DODI 5000.87|
|User Agreement||Regulatory||DODI 5000.87|
|Acquisition Strategy (includes market research findings, acquisition approach, business strategy, contract strategy, intellectual property strategy, product support strategy, metrics plan, risk management, etc.)||
Statutory for major programs (> ACAT II)
Regulatory for others
|Market Research (part of Acquisition Strategy)||Statutory|
|Cybersecurity Plan (may be part of Acquisition Strategy or standalone document). Should suffice for purposes of obtaining an Authority to Operate (ATO) and meeting the requirements for Clinger-Cohen compliance.||
Statutory for Mission Critical and Mission Essential IT programs
Regulatory for others
|Test Strategy (may be part of Acquisition Strategy) Should ensure that the general approach for DT/OT is understood among the test community.||
Programs on DOT&E Oversight list may require a 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 (includes system architecture)||Regulatory||DODI 8330.01|
|Bandwidth Requirements Review (part of information support plan or related document)||
Statutory for programs > ACAT II
Regulatory for Others
|§1047, P.L. 110-417|
|Program Cost Estimate (for applicable programs, an Independent Cost Estimate (ICE) is required iaw DoDI 5000.73. This requires coordination with CAPE who may/may not delegate)||Regulatory. 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|
|Initial Product Roadmap (to convey intial-near term plan to the Decision Authority)||Regulatory||DODI 5000.87|
|Acquisition Decision Memorandum (for the Execution Phase)||Regulatory||DODI 5000.87|
Information/Documentation to be Compiled and/or Approved DURING the Execution Phase
Reference Source: USD(A&S) Guidance
|System Architecture||Regulatory||DODI 5000.87|
|Product Roadmap (approved by the user community in terms of near-term priorities to pursue)||Regulatory||DODI 5000.87|
|Program Backlog||Regulatory||DODI 5000.87|
|Periodic updates to strategies (acquisition, contracting, test, cybersecurity, IP, product support) as needed||Statutory/ Regulatory||DODI 5000.87|
|Periodic updates to cost estimate and CARD if applicable||Regulatory||DODI 5000.87|
|Value Assessment (at least annually) to meet intent of Post-Implementation Review||Regulatory||DODI 5000.87|
|Clinger Cohen Act (CCA) Compliance||Statutory||DODI 5000.82, Subtitle III of Title 40|
|Core Logistics Determination (CLD)/Core Logistics and Sustaining Workloads Estimate (CLSWE) if applicable||Statutory for programs with “software maintenance”||10 USC 2464|
|DOT&E Report on Initial Operational Test and Evaluation (IOT&E) if applicable||Statutory for programs on the DOT&E Oversight List|
|DOT&E Operational Test Plan if applicable||Statutory for programs on the DOT&E Oversight List||10 U.S.C. 2399|
|Post Implementation Review (may be satisfied by Value Assessments)||Statutory|
|Program Metrics||Regulatory||DODI 5000.87|
|Semi-Annual Data Reporting to OUSD(A&S)||Regulatory||DODI 5000.87|
|Contractor Cost Data Report ($100M+ contracts)||Regulatory||DODI 5000.73|
|Software Resources Data Report ($100M+ Programs)||Regulatory||DODI 5000.73|
|Technical Data Report ($100M+ Programs)||Regulatory||DODI 5000.73|
|Contractor Business Data Report (CTRs with $250M)||Regulatory||DODI 5000.73|
SWP Points of Contact
Reference Source: USD(A&S) Guidance
For general SWP inquiries: OSD SWP Organizational E-mail: firstname.lastname@example.org
OSD SWP Lead: Sean Brady, OUSD(A&S), email@example.com
Army SWP HQ Lead: Ken Waldrop, ASA/ALT, firstname.lastname@example.org
Navy SWP HQ Lead: Melissa Naroski-Merker, ASN(RDA) email@example.com
Air Force SWP HQ Lead: Derek Jaquish, SAF/AQXE, firstname.lastname@example.org
SOCOM SWP HQ Lead: Christina Bell, USSOCOM, email@example.com
OSD SWP Advisors:
Pete Modigliani, MITRE, firstname.lastname@example.org
Dr Forrest Shull, SEI, email@example.com
Shane Smith, MITRE, firstname.lastname@example.org
Julie Cohen, SEI, email@example.com
Matt MacGregor, MITRE, firstname.lastname@example.org
Brigid O’Hearn, SEI, email@example.com
Colleen Murphy, MITRE, firstname.lastname@example.org
Michael Spead, MITRE, email@example.com
Justin Raines, MITRE, firstname.lastname@example.org