Software Acquisition

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

Agile software methodologies require users to make a commitment to the program to enable successful execution.  Effective software acquisition requires engagement with users to understand their concepts of operations, environment, existing capabilities, external systems with which the required capability must interface, interoperability requirements, threats, and other specific needs. This may require additional and/or separate funding to ensure users have the resources to support as needed.

Agile software acquisition also requires decentralized decision-making authority to meet delivery timelines.  This requires alignment of roles and responsibilities by the sponsor, project/product team, and user communities. The specifics of these commitments should be captured in a User Agreement (UA) signed by all relevant stakeholders before a software program enters the execution phase.  The UA is developed and signed by the Operational Sponsor and the Program Manager with input from other key stakeholders to:

• Ensure developments address user priority needs
• Support active collaboration between the operational users, acquisition community and software development teams.
• Support the role of an empowered Product Owner to shape and prioritize requirements.
• Establish roles and responsibilities for the key stakeholders to achieve these objectives
• Ensure sponsor, users, and stakeholder inputs are captured and integrated into Value Assessments

More specifically, the UA ensures each user community is properly represented and engaged throughout software development and delivery. It defines responsibilities and expectations for:

• Anticipated developer and user ceremonies, events, and interactions.
• Prioritizing features and stories in roadmaps and backlogs against the overarching Capability Needs Statement.
• Determining Minimum Viable Product (MVP), Minimum Viable Capability Release (MVCR), and other releases.
• Developing and participating in user training and knowledge sharing.
• Performing user testing and software demonstrations.
• Decision-making regarding software release and deployment.

Finally, the UA includes specific user engagement events and activities to ensure:

• All user communities are identified, represented, and engaged.
• Users have a shared understanding of the product, service, or problem.
• Developers understand the operational environment from a users’ perspective.
• Approaches to engaging each user community are clearly elaborated.
• Users have clear expectations about when and how to engage with the program.

Reference Source: USD(A&S) Guidance

The program commits to working closely with user communities, who will in turn commit personnel (user representatives) to participate as needed in appropriate acquisition and program responsibilities. To deliver capabilities that address user priority needs and generate mission impact, it is critical to have users actively involved throughout development and that the operational, requirements, acquisition, development, security, and test communities work closely together to apply DevSecOps best practices.

Further, it is critical that the Product Owner and Program Manager commit to a clear delineation of responsibilities that will allow them to work together effectively for the benefit of the program. Similarly, the roles of the Sponsor and Decision Authority will need to be clearly defined to ensure that there are not overlapping responsibilities. Additional technical roles (including those of the Integrated Product Teams (IPT) noted in the diagram that follows) will be addressed in other documents, so that this document focuses primarily on roles that will engage end-users.  The following is a notional outline of key roles.

The following are notional roles and responsibilities of the key stakeholders involved in requirements, design, user engagements, and value assessments. This is not intended to be a comprehensive document capturing the responsibilities of all stakeholders in the program community, but rather the key relationship between operations/requirements and acquisition leaders. Each organization will often have unique processes and roles. Programs are encouraged to tailor responsibilities to their unique needs. Some of the key players include, but are not limited to:

Reference Source: USD(A&S) Guidance

Engaging user communities is critical to the success of Agile software development efforts.  Therefore, the UA should identify the technique(s) that the program will use to select and engage user representatives.  Some recommendations on selecting and engaging user representatives include:

• Select user representatives from all user communities.
• Balance the user population to ensure the product is optimized for all user communities.
  • Note: If a program has too many representatives from a specific community (e.g., a single Military Occupational Skill (MoS) or a single military unit), the software may become optimized for that user community, but sub-optimal for other communities.
• Select user representatives that provide proportional representation based on program objectives/goals.
  • Note: If software is for command and control, anticipate having more user representation from that population.
• Select user representatives with both a deep understanding of the mission and familiarity with modern software development methods.
  • Note: If users lack familiarity with modern software development methods, training will be required and should be factored into the program budget.
• Consider the use of test detachments that are specially designated to work with software programs to prioritize features and evaluate early versions of software.
  • Note: Test detachments are typically populated with operational users who return from deployment and spend a rotation in the test detachment.
• Embed end-users within the software development team or (if not possible) consider other methods to actively engage with end-users.
• Collocate users and developers and establish virtual/remote tools to fosters a holistic team environment, active collaboration, and information exchange.

Reference Source: USD(A&S) Guidance

The UA identifies the types of activities that require user engagement and sets clear expectation of decision-making authorities, which may include regular user input and feedback on:

• Context of operational environment – understanding the people, processes, systems, and evolving needs/capabilities. This should also include any assumptions, constraints, priorities, or threats.
• Feature identification and prioritization.
• Appropriate MVP and MVCR.
• The Product Roadmap.
• Development activities and assessment of working software.
• CNS development, refinement, and maintenance.
  • Note: the initial CNS is refined during planning.
• Interface considerations and interoperability requirements to ensure a System of System view (technical and operational processes).
  • Note: This is especially true for software embedded on a weapon system for design, usability, and schedules.
• End user testing and validation – identify who is involved in demonstrations and testing, as well as how demonstrations and user testing will be accomplished (test plan, test environment) prior to deployment and rollout of the software.
• Deployment and rollout decisions – specify who has authority to make rollout decisions, what sites will receive new features/capabilities, sequencing of rollout locations, and the decision-making authorities for ‘go/no-go’ decisions.
• Human System Integration (HSI) –  incorporate HSI considerations to optimize total system performance, reduce total ownership costs and ensure that the system is designed to be operated, maintained, and supported while providing users with the ability to effectively complete their mission(s) in accordance with DoDI 5000.95 – Human Systems Integration in Defense Acquisition
• Value Assessments – how the sponsor will capture and integrate user and stakeholder inputs to shape value assessments.