Software Acquisition

AAF  >  Software Acquisition  >  SWP Quick Start Primer

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 relevant courses to start: Training (see Resources) See also: Agile 101 Primer and DoD DSO Strategy Guide.

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. Program registration.

The OSD SWP team requests that any program approved to use the SWP, complete the SWP Registration Form (CAC required) with basic program information for OSD and Congressional insight into pathway usage and emailing to the OSD SWP mailbox at [email protected]. This is for tracking purposes only and once Service acquisition reporting systems capture SWP data elements, will no longer be necessary. Requested information includes:

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

18. Semi-annual reporting.

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 programs complete the Semi-Annual Reporting Form (CAC required) and email to [email protected] on a semi-annual basis (April and October).  Any other metrics adopted by programs are for their internal use and do not need to be reported.

Documentation Requirements

Planning Phase

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.

  1. The decision for an acquisition program to use the SWP requires an ADM (and draft CNS) per DODI 5000.87.
  2. 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.

Execution Phase

The following documents for the Execution Phase should represent an initial program position but be regularly updated as the program matures.

Documentation Required to ENTER the Execution Phase

Reference Source: USD(A&S) Guidance

Applicability Source
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

10 USC 2431a

DODI 5000.87

Market Research (part of Acquisition Strategy) Statutory

10 USC 2377

41 USC 3306(a)(1)

41 USC 3307(d)

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

40 USC 11313

DODI 5000.87

DODI 8500.01

DODI 5000.82

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.

DODI 5000.87
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 considerations below) 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

Applicability Source
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 (See CCA table below) 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 10 U.S.C. 2399

10 U.S.C. 139

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 40 USC 11313

DoDI 5000.82

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
Maintenance and Repair Parts Data Report ($100M+ Programs) Regulatory DODI 5000.73


SWP Points of Contact

Reference Source: USD(A&S) Guidance

For general SWP inquiries: OSD SWP Organizational E-mail:  [email protected]


OSD SWP Lead: Scott Smith, OUSD(A&S): [email protected]

Army SWP HQ Lead: Ken Waldrop, ASA/ALT: [email protected]

Navy SWP HQ Lead: Melissa Naroski-Merker: ASN(RDA) [email protected]

Air Force SWP HQ Lead: Derek Jaquish, SAF/AQXE: [email protected]

SOCOM SWP HQ Lead: Christina Bell, USSOCOM: [email protected]


OSD SWP Advisors:

Matt MacGregor, MITRE: [email protected]

Dr Forrest Shull, SEI: [email protected]

Shane Smith, MITRE: [email protected]

Julie Cohen, SEI: [email protected]

Brigid O’Hearn, SEI: [email protected]

Colleen Murphy, MITRE: [email protected]

Michael Spead, MITRE: [email protected]

Justin Raines, MITRE: [email protected]