Software Acquisition

AAF  >  Software Acquisition  >  Develop Strategies

Develop Strategies

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.3.b.(6)


Programs will continuously improve or refine software development processes, practices, tools, and program strategies to reflect them.

Reference Source: USD(A&S) Guidance

FY20 NDAA Section 800 directs Software Acquisition Pathway programs are not to be treated as MDAPs. Further, the Adaptive Acquisition Framework transformed the policies, processes, and culture to: empower PMs; delegate decisions; tailor in processes; and focus on data driven decisions. This context provides PMs freedom to tailor the AAF in accordance with their Decision Authorities’ direction which can impact acquisition reporting requirements (statute and policy).

Strategic intent. The SWP is intended to balance speed with rigor. It values working software over comprehensive documentation, but requires proper planning and coordination of strategies and designs commensurate with size and risk. Documentation isn’t developed for compliance purposes to pass the next milestone (as there are none in the SWP), but rather to proceed with managed risk and continuous improvement throughout development.

The risk of providing an information requirements checklist is the potential unintended consequence of reducing the creative compliance mindset of the DoD.  DoD is very contextual – we have the largest, most diverse software ecosystem and portfolio on Earth.  The PM and PEOs have the flexibility to tailor in processes and documents based on the unique needs of their portfolio, as opposed to a universal standard.  This reduces bureaucratic overhead and red tape that limits agility, and drives cost and schedule duration increases.

Principles based framework:

What follows is a draft framework to guide services and PEOs on expectations for tailoring-in processes and information-needs/documents for DODI 5000.87.  Ultimately, a review of statutory requirements applicability by the Service and OSD OGC must confirm which statutes and MDAP requirements do not apply, given the MDAP treatment prohibition from FY20 NDAA Section 800, included here:

TREATMENT NOT AS MAJOR DEFENSE ACQUISITION PROGRAM.— Software acquired or developed using the authority under this section shall not be treated as a major defense acquisition program for purposes of section 2430 of title 10, United States Code, or Department of Defense Directive 5000.01 without the specific direction of the Under Secretary of Defense for Acquisition and Sustainment or a Senior Acquisition Executive.

Statutory Requirements: The Software Pathway intent is to reduce bureaucracy to maximize taxpayer investment and accelerate capability to our Warfighters.  In turn, the intent is to reduce the documentation requirements and focus the program’s efforts on planning and producing working software to enable rapid and continuous delivery. It is recognized that there are some statutory and regulatory information requirements that must be met such as a Component cost position, cybersecurity strategy, or bandwidth requirements review. (Note: a hybrid pathway adoption may require statutory requirements for associated hardware of the parent program). However, we take the view that many of the statutory requirements are information requirements that can be included in the Acquisition Strategy and not as stand-alone documents. (The team has not assessed the distinction between application and embedded software acquisition/pathway use wherein certain safety requirements may apply; e.g., nuclear surety.)

Regulatory Requirements: Regulatory documents should be developed only if deemed essential to program execution.  Some document content will be combined.  Many regulatory information requirements are covered in the CNS, User Agreement, Acquisition Strategy, and Cost Estimates.  Some regulatory information may still be required on a case by case basis, based on capabilities being delivered (e.g., waveform assessment if delivering new or modified signal formats). Decision Authorities as have discretion in the regulatory arena on what to require and when to require it.

The buttons below provide further details on the core strategy documents for the Software Acquisition Pathway.

The tables below provide an initial pass on statutory and regulatory information requirements for Programs using the Software Acquisition Pathway

Information Required for Software Acquisition Pathway Programs

Reference Source: USD(A&S) Guidance

Information Required Applicability Source
Entering the Planning Phase
Acquisition Decision Memorandum (ADM) signed by Decision Authority authorizing use of SWP. Regulatory DODI 5000.87
Draft Capability Needs Statement Regulatory DODI 5000.87
Entering the Execution Phase
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

10 USC 2431a

DODI 5000.87

Cybersecurity Strategy (may be part of Acquisition Strategy or standalone document)

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)

Programs on DOT&E Oversight list may require a Test and Evaluation Management Plan (TEMP)

Regulatory 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 (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
During the Execution Phase
System Architecture Regulatory DODI 5000.87
Product Roadmap or equivalent Regulatory DODI 5000.87
Program Backlog or equivalent Regulatory DODI 5000.87
Periodic updates to strategies (acquisition, contracting, test, cybersecurity, IP, product support) Statutory/ Regulatory DODI 5000.87
Periodic updates to cost estimate and CARD Regulatory DODI 5000.87
Value Assessment (at least annually) Regulatory DODI 5000.87
Clinger Cohen Act (CCA) Compliance (see CCA table) Statutory DODI 5000.82, Subtitle III of Title 40
Core Logistics Determination (CLD)/Core Logistics and Sustaining Workloads Estimate (CLSWE) Statutory for programs with “software maintenance” 9 USC 2464
Post Implementation Review 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

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)

Clinger Cohen Act Compliance

Reference Source: USD(A&S) Guidance

Clinger-Cohen Act Requirement 40 USC 1401 Applicable SWP Documentation
Determination that the acquisition supports core, priority functions of the DoD. Capability Needs Statement (Capabilities section)
Establish outcome-based performance measures linked to strategic goals Capability Needs Statement (Performance Attributes section)
Redesign the processes that the system supports to reduce costs, improve effectiveness and maximize the use of commercial off-the-shelf technology Capability Needs Statement (Program Summary section)
Determine that no private sector or government source can better support the function Acquisition Strategy
Conduct an analysis of alternatives Acquisition Strategy (Business Strategy section)
Conduct an economic analysis that includes a calculation of the return on investment; or for non-AIS programs, conduct a life-cycle cost estimate. Component Cost Estimate, Component Cost Position
Develop clearly established measures and accountability for program progress. Acquisition Strategy (Program Metrics, Value Assessment)
Ensure that the acquisition is consistent with the DoD Information Enterprise policies and architecture, to include relevant standards. System Architecture
Ensure that the program has a Cybersecurity Strategy that is consistent with DoD policies, standards and architectures, to include relevant standards. Cybersecurity Strategy
Ensure, to the maximum extent practicable, (1) modular contracting has been used, and (2) the program is being implemented in phased, successive increments, each of which meets part of the mission need and delivers measurable benefit, independent of future increments. Acquisition Strategy (Contracting Strategy section)
Register Mission-Critical and Mission-Essential systems with the DoD CIO. DoD Information Technology Portfolio Repository