Software Acquisition

AAF  >  Software Acquisition  >  Develop Strategies  >  Acquisition Strategy

Acquisition Strategy

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.1.d


Existing acquisition programs may elect to update their acquisition strategy to transition to the software acquisition pathway or use it in addition to their current acquisition pathway.  The PM and applicable stakeholders will identify, and the DA will approve, a transition approach to tailor processes, reviews, and documentation to effectively deliver software capabilities.


Reference Source: DODI 5000.87 Section 3.2.d


Program managers will develop and execute an approved acquisition strategy.  The acquisition strategy is an integrated plan that identifies the overall approach to rapidly and iteratively acquire, develop, deliver, and sustain software capabilities to meet the users’ needs. Consistent with modern software development practices, the acquisition strategy and related program documentation will be tailored to what is needed to effectively manage the program.

  • The PM will actively collaborate with program stakeholders and functional experts in developing the acquisition strategy given the current environment, priorities, risks, and approach.
  • The DA will approve the acquisition strategy to include process and documentation tailoring.
  • The acquisition strategy for an embedded software system must align with and may be included as part of the platform acquisition strategy.
  • The PM will mature the strategy to the point where it has sufficient rigor for the DA to approve beginning development, and will continuously refined it throughout the acquisition lifecycle.


Key elements of the acquisition strategy include, but are not limited to:

  • Risk-based business and technical management approach to rapidly and iteratively deliver software capabilities balanced against quality, security, intelligence threats, system safety, performance, and other factors.
  • Roadmap and cadence for software deliveries to operations including:
    1. Demonstrating the viability and effectiveness of capabilities for operational use not later than 1 year after the date on which funds are first obligated
    2. Continuously delivering capabilities to operations at least annually thereafter.
    3. If using the embedded software path, aligning and integrating with the development and fielding for the systems in which the software is embedded.
  • Flexible and modular contract strategy that enables software development teams to rapidly design, develop, test, integrate, deploy, and support software capabilities.
  • Planned use of government personnel and resources for software activities.
  • Tailoring of acquisition processes to adopt modern software development practices (e.g., lean, agile, DevSecOps).
  • Planned use of existing enterprise services, infrastructure, and resources.
  • High level test strategies, coordinated with the test and evaluation community, to validate software quality, integration and automation of testing, along with planned test platforms, resources, and infrastructure.
  • Architecture strategies to enable a modular open systems approach that is interoperable with required systems.
  • Cybersecurity strategies in accordance with the applicable cybersecurity policies and issuances which include recurring assessment of the supply chain, development environment, processes and tools, continuous automated cybersecurity test and operational evaluation to provide a system resilient to offensive cyber operations.
  • IP, training, and product support strategies; and records management requirements in accordance with the appropriate DoDIs to ensure lifecycle supportability.
  • The PM’s strategy to ensure that the program is conducted in accordance with all applicable laws and regulations (e.g., Division E of Public Law 104-106, safety, sustainment, communication waveform management and standardization, and airworthiness) throughout the lifecycle..

Acquisition Strategy Guidance

Reference Source: USD(A&S) Guidance

The acquisition strategy for a software program must address traditional functional areas such as Test and Evaluation, Risk Management, Funding, Contracting, Acquisition Approach, etc. The strategy must describe a plan for acquiring software at a level of detail that is suitable for justifying the investment decision. Constructing the acquisition strategy for an iterative software development program also requires the following activities:

  • Develop the roadmap: The roadmap must identify how often to deliver working software to operational users, based on a cadence that is appropriate to meet user needs. The roadmap must also describe the overall approach for managing iterative software development, showing how the software iterations fit with any constraints from interfacing systems or hardware dependencies. The program must describe how it will allow detailed requirements to be prioritized and developed with user involvement while ensuring progress toward implementing the high-level features needed.
  • Select a software development framework to guide the work: Based on technical constraints, prior experience and other considerations, the program should state whether it has already selected an Agile framework (e.g., SAFe, Scrum, XP) as a way to organize the work, or describe the considerations that will influence the choice once implementation starts.
  • Develop a plan for obtaining competencies in modern software development practices on the government team: The program should describe what gaps exist, in terms of bringing sufficient expertise in modern software practices into the team, and have a plan for filling those gaps in a way that scales up realistically (e.g., leveraging expertise available from the enterprise, or contracting for consulting, coaching, or training).
  • Develop a pathway to an MVP: Working with the users, the Program Manager must either explicitly state the major capabilities that would be part of an MVP that can be used to collect relevant user feedback or describe the process by which that MVP will be defined.
  • Establish initial design solution constraints: Based on the technical vision, the acquisition program must describe the approach it will take to software design, highlighting any known constraints and identifying how the program will deal with emergent design issues as the system evolves across iterations. Design decisions should be informed by the current threat environment as assessed by the acquisition intelligence community.
  • Identify applicable enterprise services and infrastructure decisions: Programs must describe fundamental technical decisions related to cloud usage, networking, and the establishment of environments for software development, integration, and deployment (DevSecOps). Programs should identify likely commercial or government-provided solutions to these needs or be prepared to justify why existing enterprise services will not meet the needs and how the program will bear the recurring costs of keeping these solutions up to date.
  • Describe the necessary team size and budget for the work: Based on an estimate of the level of effort required over time to produce an MVP and continue working on the capability, programs must establish the team size, team organization, and budgetary needs.
  • Develop a contracting strategy: The program must describe the strategy for contracting for the needed software team, ideally in a way that lowers barriers to entry for organizations that can contribute innovative technical solutions. The discussion should cover topics such as incentivizing innovation and performance in an Agile context and protecting intellectual property while giving the government the access to source code needed to scan for issues in a DevSecOps environment.
  • Develop Software Transition Strategy: Prior to software transition to a different organization (e.g. a DoD Lifecycle Software Center), the PM should require delivery of the complete software technical baseline, including all software capability descriptions (e.g. features, story points, use cases, etc.) and all as-built architecture and design products, traceability products, interface definitions including interfaces to proprietary software elements, and any other requisite documentation. The baseline facilitates managing program risk, understanding intellectual property rights, and supports the software transition to another organization for sustainment..

Note: If the below video(s) show a “Website Blocked” banner, try accessing the video via a non-DoD network. No sensitive content is contained in this video. Current DoD network policies to conserve bandwidth may be impacting the ability to view this video.