Software Acquisition

Reference Source: USD(A&S) Guidance

This SWP quick start primer is to assist acquisition professionals in using the Software Acquisition Pathway.  It provides the core items needed to enter the Planning Phase and quickly move into the Execution Phase. Programs that are transitioning from another pathway may have already satisfied some of the below elements and can accelerate into the Execution Phase.  Those transitioning programs should consider adopting SWP artifacts in lieu of legacy documents if they are more compatible with the proposed acquisition.

1. Establish a program team.

The Decision Authority should establish a program team early – before requirements have been formally established or program artifacts developed – to generate the required program artifacts and establish the software development processes that will be used to manage the effort.

2. Train the program team.

The program team should obtain Agile and DevSecOps training to provide context for developing program artifacts and establishing program processes, and ultimately executing a modern software development program. DAU offers relevant courses to start: Training (see Resources) See also: Agile 101 Primer and DoD DSO Strategy Guide.

3. Define overarching requirements.

The program should collaborate with Operational Sponsor(s) to define the initial set of overarching requirements.  These requirements should be high-level enough to provide the vision for the program and enable prioritization of more granular needs as part of the user governance processes.  This can be captured in a Capability Needs Statement, Software Initial Capabilities Document or other document.  If a program has an existing requirements document that is still current, it can be used to enter the Execution Phase.  Additional details, including templates, can be found here:  Define Capability Needs

4. Set user governance process.

The program should collaborate with Operational Sponsor(s) to establish the user engagement processes that will be used to manage and execute the program and document in a User Agreement.  Early and often user feedback is critical for an agile software program and time spent setting these expectations will pay dividends later.  More details can be found here: User Agreement

5. Identify architectural approach.

The program should identify the high-level software architecture that will be leveraged to support the continuous engineering of capability. The team should employ experienced software architects who will help implement architectural principles and patterns critical for software programs, such as open systems, modularity, and security patterns. The architecture may be captured in various internal technical documents but only needs to be formal approved as part of the Information Support Plan.  Additional details can be found here:  Architecture and Interoperability

6. Define the cybersecurity strategy.

The program should collaborate with the cybersecurity community on a balanced approach that will ensure secure development, software assurance and secure lifecycle management while retaining the ability to rapidly deploy capability.  The goal should be to move towards gaining a continuous or near-continuous Authority to Operate.  More details here: Cybersecurity

7. Capture the testing plan.

The program should begin collaborating with the appropriate test organizations to gauge expectations, identify the resources required, and craft streamlined processes to ensure rapid, high-quality, and secure software releases are delivered to military users.  More details here: Test Strategy

8. Articulate the infrastructure.

The program should identify the infrastructure required to implement the architecture, cybersecurity strategy and test plans to include cloud infrastructure, software development platforms, containers, virtual machines, monitoring tools, and test automation tools.  The SWP encourages using enterprise services to accelerate program stand-up.  More details here: Enterprise Services & DevSecOps

9. Craft the contracting strategy.

The program should work closely with the contracting office supporting the acquisition to craft a flexible and modular approach to acquire the right expertise to develop the necessary software capabilities.  The contracting strategy may use multiple approaches and evolve with the program.  More details here: Contracting Strategy

10. Mold a product support strategy.

The program should recognize that there is no clear sustainment phase on an agile software program.  However, each program will have unique considerations and the long-term strategy should be factored into program planning. More details here:  Product Support Strategy

11. Shape intellectual property approach.

The program should develop a clear approach for managing different types of intellectual property.  It should require delivery of key artifacts and technical data at defined points to the government.  A preference should be maintained for unrestricted or open-source software.  More details here:  IP Strategy

12. Scope the MVP / plan for MVCR.

The program should develop an initial backlog based on known requirements and work with the user community to scope an MVP that will be used to gain feedback and inform the development process.  The program should also begin planning for the MVCR after prioritizing the backlog and establishing a near-term roadmap for the Execution Phase.  The processes used to do this should be documented in the User Agreement.  This does not need to be a comprehensive plan but should provide insight to the Decision Authority on what software features the program would immediately work towards in the Execution Phase.  More details here: MVP and MVCR

13. Develop initial cost estimate.

The program should work with the cost estimating team as early as possible to begin drafting an initial cost estimate that reflects Agile cost estimating principles and captures work to inform the 5-year budget planning cycle.  Larger programs may have to work with OSD CAPE to either request delegation or to conduct the Independent Cost Estimate.  More details here:  Cost Estimation

14. Identify program metrics.

The program should identify metrics to manage the performance, progress, speed, cybersecurity, and quality of the development.  These should be initially captured in the acquisition strategy and then incorporated into program execution processes.  These metrics are intended to provide the technical team, the PM and the Decision Authority with insight into software development performance.  There is no standardized approach here and different metrics may be applicable for different levels of reporting (i.e. the technical team will probably have different needs than the PEO or SAE).  Expectations should be discussed as part of crafting the acquisition strategy.  More details here: Metrics and Reporting

15. Address oversight.

While not every program will be able to choose the level of oversight demanded by Decision Authorities, SWP programs should strive to make the case for delegation of certain decisions to maximize the effectiveness of agile methodologies.  Programs can propose interim progress reviews to encourage delegation while also ensuring Decision Authorities have the appropriate level of insight into program progress.

16. Coalesce acquisition strategy.

The program needs to work collaboratively with the respective functional communities to coalesce individual strategies and plans into a cohesive acquisition strategy that captures the key processes that will be used to execute the program.  More details here: Acquisition Strategy

17. Program registration.

The OSD SWP team requests that any program approved to use the SWP, complete the SWP Registration Form (CAC required) with basic program information for OSD and Congressional insight into pathway usage and emailing to the OSD SWP mailbox at [email protected]. This is for tracking purposes only and once Service acquisition reporting systems capture SWP data elements, will no longer be necessary. Requested information includes:

• Program Name (Long Name and Short Name)
• SWP Entry Approval Date
• Lead Component
• Program Description
• Decision Authority (Organization, not Name)
• Program Manager (Name and Contact Info)
• Software Path (Application, Embedded, Business System)
• Planned First Funds Obligated Date (Month/Year)
• Planned MVCR Date (Month/Year)
• Program Estimate Total (ROM)

18. Semi-annual reporting.

The OSD SWP team has minimized reporting requirements to those data elements that provide enterprise-level insight to senior acquisition leaders and external stakeholders.  The OSD SWP team requests programs complete the Semi-Annual Reporting Form (CAC required) and email to [email protected] on a semi-annual basis (April and October).  Any other metrics adopted by programs are for their internal use and do not need to be reported.

Documentation Requirements

Planning Phase

Only an Acquisition Decision Memorandum (ADM) and a draft requirements document are needed to enter the Planning Phase.

Execution Phase

The following documents for the Execution Phase should represent an initial program position but be regularly updated as the program matures.