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

Market Research (part of Acquisition Strategy) Statutory

10 USC 2377

41 USC 3306(a)(1)

41 USC 3307(d)

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 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 Regulatory DODI 8330.01
Bandwidth Requirements Review (part of ISP or related document)

Statutory for programs > ACAT II

Regulatory for Others

§1047, P.L. 110-417
Program Cost Estimate and Independent Cost Estimate 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
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” 10 USC 2464
DOT&E Report on Initial Operational Test and Evaluation (IOT&E) Statutory for programs on the DOT&E Oversight List

10 U.S.C. 2399

10 U.S.C. 139

Operational Test Plan Statutory for programs on the DOT&E Oversight List 10 U.S.C. 2399
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

Clinger Cohen Act Compliance Considerations

Reference Source: USD(A&S) Guidance

While the Clinger-Cohen Act is statutory for all IT programs (in the broadest use of that term), there may be creative ways to achieve compliance using alternative SWP artifacts.  Consult with your CCA Approver early so you can understand the options you have to tailor compliance in this area.

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

Modern Software Management Approaches to Baselines and Progress

Reference Source: USD(A&S) Guidance

BLUF: Programs using the Software Acquisition Pathway (SWP) should not baseline cost, schedule, and performance.  An Acquisition Program Baseline (APB) is not required and in fact is highly discouraged.

  • This includes programs transitioning from other AAF pathways or legacy 5000.02 models. When requesting Decision Authority approval to enter the Software Pathway, programs transitioning should also request closeout of current APBs.
  • Traditional baselines are associated with (and required for) hardware intensive systems using the Major Capability Acquisition pathway. Congress established the SWP with explicit exemption from MDAP processes in order to drive more dynamic, modern software development.
    • Generally APBs can drive behaviors which run counter to modern digital product delivery. This includes over definition of upfront requirements and associated long range cost estimates that do not allow for discovery and are not informed by small batch, iterative deliveries. In addition to running counter to these desired approaches, APBs cannot keep pace with dynamic changes to needs — and therefore the corresponding financial resources and delivery timelines – that will be increasingly expected in a volatile, uncertain and complex tech and threat environment.
    • Understanding cost efficient and timely deliveries remains important, but there are more modern management approaches and controls suited for dynamic executions at the speed of relevance and SWP.
  • Instead of establishing a baseline, SWP programs should apply modern software development practices (Agile, DevSecOps, Lean, and Human Centered Design) which promotes delivery of iterative and frequent software upgrades to satisfy user’s current highest priorities.


  • Conduct extensive analysis of alternatives and technology maturity
  • Define program requirements upfront and lock them down in perpetuity
  • Develop lifecycle cost estimates based on long-term program requirements
  • Develop and coordinate extensive acquisition, contracting, systems engineering, test and evaluation, product support and related plans that are rarely, if ever, updated.
  • Baseline costs, schedule, and performance in an APB before any insights from development
  • Measure a program’s performance against APB baselines and declare breaches if exceeded
  • Track contractor performance via Earned Value Management against rigid plans and schedules.
  • Programs punished when poor predictions lead to changes and cost and schedule impacts


  • Scope, requirements, budgets, cost estimates, and designs expected to change based on changing operational needs, threat changes, and cybersecurity upgrades.
  • Programs deliver capability on a regular cadence maintaining a focus on addressing highest priority user requirements first.
  • Progress is measured by user perception of the value delivered (conveyed in value assessments) and specific performance metrics (determined by the DA) in lieu of milestone progress. Metrics can be used to measure
    • Speed of delivery
    • Frequency of releases
    • Quality of software
    • Responsiveness to cyber threats
  • Acquirers and developers actively engage user community throughout development to understand environment, priorities, performance and feedback on earlier releases/demos.
  • Program sponsor (with user input) provides written value assessment at least annually.
  • Continuously evolve program scope, budgets, designs, strategies, and functionality.

DODI 5000.87 does not require SWP programs to develop/manage to an APB.

  • Acquisition executives and decision authorities should not impose constraints and risks on programs by mandating an APB and managing via legacy major hardware-centric programs.

Many SW Pathway elements