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:
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 |
|
Cybersecurity Strategy (may be part of Acquisition Strategy or standalone document) |
Statutory for Mission Critical and Mission Essential IT programs Regulatory for others |
|
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 | |
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 |
Continuous Learning Modules
- Introduction to Agile Software Acquisition
- Introduction to DoD Software Lifecycle Management
- Practical Software and Systems Management
- Software Acquisition for the Program Office Workforce
- Continuous Process Improvement
Program Management Resources
- 10 Commandments for Software, Defense Innovation Board
- Detecting Agile BS, Defense Innovation Board
- Dos and Don’ts for Software, Defense Innovation Board
- Metrics for Software Development, Defense Innovation Board
- Software Acquisition Practice Study, Defense Innovation Board
- Continuous Iterative Development (Agile) Measurement Framework, PSM
- 7 Traits of High Performing Acquisition Teams, DAU
- Changing Software Acquisition in DoD, DAU