Software Acquisition

Reference Source: DODI 5000.87 Section 3.2.d

 

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. Key elements of the acquisition strategy include, but are not limited to:

 

Flexible and modular contract strategy that enables software development teams to rapidly design, develop, test, integrate, deploy, and support software capabilities.

Key SW Fundamentals | How SW Programs Are Different | Modular Contracting | Contracting for DevSecOps | Contracting for Agile SW Dev | Industry Perspective for Agile SW Dev Contracts | Tech Data Rights and IP | Open Architecture Contract Considerations |  Acquiring Innovative SW Solutions | Streamlining Evaluation and Selection | Resources

Understand Key Software Development Fundamentals

Reference Source: OUSD (A&S) Guidance

Contracting for software development solutions requires program and contracting teams to understand fundamental modern software development principles and processes (e.g., Agile software development and DevSecOps) to successfully collaborate to develop and implement contracts and business arrangements to rapidly deliver capability to users.

Understanding the following elements of modern software development is key for executing SWP programs. Together, these elements enable SWP programs to iteratively deliver capability to the warfighter:

The Software Acquisition Pathway (SWP) provides a policy and guidance framework that facilitates rapid and iterative deliver of software capability to users by integrating modern software development practices, tightly coupled government-industry teams, and active user engagement.

DevSecOps (DSO) is a culture and philosophy, realized through a collection of people, processes, automation tools, and standards (e.g., DSO Reference Design, Application Program Interfaces (APIs)) enabling programs to develop, secure, deploy, and operate applications in a secure, flexible, and interoperable fashion. There is not a standard or uniform DevSecOps offering; this will vary program to program. See the DoD Enterprise DevSecOps Fundamentals for more details on DevSecOps.

Agile Development is a software development methodology based on a set of values and principles focused on flexibility, collaboration, and efficiency to deliver quality products that provide value to users. See the Agile 101 Primer for more details on Agile Software Development in the DoD.

Comprehending these fundamental elements of modern software development is key to understanding how to structure contracts for software development solutions. Contracts that enable DevSecOps and Agile development processes are critical to success.

Understand How Software Development Programs are Different

Software Development Processes Are Different!

Traditional hardware focused acquisition follows a sequential development process where requirements are fully defined upfront and a contract is awarded to a single contractor to design, develop, test, deploy, and maintain the solution.

The traditional acquisition process does not align with software development principles and processes predicated on high level requirements that enable iterative development to achieve solutions desired by the user. Agile software development is a continuous cycle to design, develop, test, and deliver small increments of capability in much shorter timeframes that traditional development processes.

SWP programs are required to deliver capability no less than annually, but higher delivery frequency is ideal and encouraged.

Software Development Program Requirements Are Different!

For SWP programs, high level requirements are documented in a Capability Needs Statement (CNS) or Software Initial Capabilities Document (SW-ICD) that capture the scope of the user’s operational needs, threats, and environments but does not detail specific development activities.

Product roadmaps provide a high-level visual summary that maps out the vision and direction of product offerings over time. Roadmaps describe the goals and features of each software iteration and increment but does not detail a specific project schedule as an Integrated Master Schedule (IMS) would.

Program or Product Backlogs are dynamic prioritized lists of tactical user needs of capability to be developed. Backlogs are leveraged to manage workflow and communicate detail on what will be delivered in next development cycle. Backlogs contain the work that will be developed by software development teams.

Software Development is Never Done!

Software development is never complete and software development programs do not enter a “sustainment” phase in the way that traditional hardware programs do once development is complete and the solution moves into operation.

Contracting for Software Development Programs is Different!

For a program to embrace the software development principles and processes discussed above, contracting for software development solutions necessitates a shift from approaches used for acquiring traditional hardware intensive solutions – mainly shifting away from a singular “monolithic contract” to deliver a solution against a specific set of requirements.

Instead of a single all-emcompassing contract, software development efforts are best acquired by leveraging a portfolio of contracts (managed and integrated by the Government) where individual contracts are crafted with specific and distinct scopes of work. This construct provides a program with flexibility to adapt to evolving requirements and increases competitive opportunities for smaller pieces of the larger solution. A portfolio of contracts may be achieved by leveraging a modular contracting strategy that is focused on the elements enabling software development. Modular contracting is discussed in the next section.

Modular Contracting

Reference Source: OUSD (A&S) Guidance

Modular contracting, leveraging Commercial Solutions Opening (CSO) procedures and Other Transaction (OT) agreements, is the preferred approach for acquiring major information technology systems in accordance with 41 U.S.C. §2308. Modular contracting for information technology is implemented at FAR 39.103. Modular contracting is an approach that divides an acquisition into smaller increments with the intended outcomes of reducing program risk, continuously acquiring rapidly-changing technology, and enabling flexibility for programs to scale.

Modular contracting enables a SWP program to establish contracts with different objectives to best meet the many requirements and objectives throughout a program’s lifecycle. Modular contracting differs from contracting for traditional solutions/system as follows:

A well-planned modular contracting strategy can enable SWP programs to establish and maintain software development/test environments and separately acquire software development teams to deliver capability and enable programs to scale and evolve over time.

By contracting separately for the development environment and individual development teams the program can specifically address issues with individual contracts through a variety of actions ranging from adjusting the skill/labor mix of a contractor development team to outright replacing a contractor if there is a performance issue. This is a risk reduction strategy for a SWP program.

What Should a Modular Contracting Strategy Look Like for a SWP Program?

There is not a singular model for a SWP program modular contracting strategy. The goal of a modular contracting strategy is to award distinct contracts for distinct efforts, but strategies should be tailored to the specific needs of a program. A modular contracting strategy for one SWP program is likely to look different from another program and may evolve throughout a program’s lifecycle, especially as scaling occurs and more development activities are added. When determining necessary contracts, a SWP program should consider the following:

• Will the government assume the role as integrator, or will an integrator contractor be required?
• What are program office skills, expertise, and resources to manage software development/deployment/operations activities?
• Does the program have access to appropriately skilled resources for software development/deployment/operations (e.g., Product Owner, Software/DevSecOps engineers, appropriately skilled Contracting Officer’s Representative)?
• Are there existing enterprise contracts and solutions (e.g., Joint Warfighting Cloud Capability (JWCC), PlatformOne Marketplace, Navy Overmatch Software Armory, Army CReATE) the program can access or is required to use? What are the synergies with other existing (or planned) contracts and programs?
• Are there existing legacy contracts? How will or won’t they be leveraged for software development?

Considerations for a modular contracting strategy include, but are not limited to the following:

While there isn’t a correct number of contracts to pursue when developing a modular contracting strategy, more modularity generally enhances a program’s ability to reduce risk and evolve (i.e., adding and removing contracts as requirements/technology change or contractor performance isn’t satisfactory).

Programs should be prepared to manage the interfaces and dependencies between contracts and the different “modules” of the program. These can be addressed using DevSecOps principles as part of a development environment offering a standardized development environment with automated tools and processes. See Open Architecture/API section below.

While the implementation of a modular strategy may appear daunting, the benefits enable a program to granularly target needed expertise, products, and services to continuously deliver a superior solution to the warfighter.

Existing SWP programs have unique contracting strategies, some more modular than others. Some programs are transitioning to more modular approaches as the program evolves and becomes more skilled and capable of managing multiple contracts, especially for multiple software development teams. An example of a program leveraging an Other Transaction is as follows:

Contracting for a DevSecOps Development Environment

Reference Source: OUSD (A&S) Guidance

The CIO Enterprise DevSecOps Reference Design documents define specific tools, technologies, constructs, and architectures for DoD DevSecOps development environments for Agile software development. Key elements of a DevSecOps development environment include automated tools and processes tailored for the program’s mission, continuous Authorization to Operate (cATO), and open Application Program Interface (API) architecture.

The DoD often refers to a DevSecOps development environment as a Software Factory (SWF) or CI/CD Pipeline, to enable continuous integration and delivery of software capability to warfighters. The DoD Software Modernization Implementation Plan refers to Software Factories as collections of people, tools, and processes that enable teams to continuously deliver value by deploying software to meet the needs of a specific community of end users while enabling continuous rollout and cutting-edge cyber resilience.

The following are examples of existing enterprise DevSecOps contract solutions providing access to vendors (small and large) that have demonstrated their ability to establish and manage software development environments for the DoD:

• • • PlatformOne Marketplace (Air Force)
    • BESPIN Cloud Operations and Mission Delivery-as-a-Service (MDaaS) (Air Force)
    • Enterprise Cloud Management Agency (ECMA) (Army)
    • Overmatch Software Armory (OSA) (Navy)

_____________________________________________________________________________

Contracting Strategies to Consider for Development Environment

A program may need to contract for a development environment solution if not using an enterprise offering. Development environment or DevSecOps solutions are often “as-a-Service” based for automated tool sets and processes to meet program objectives as well as DevSecOps expertise to implement and manage the development environment.

Contracting strategies to consider for DevSecOps/Software Factory include the following:

Commercial Solutions Opening (CSO)

CSO solutions offer streamlined procedures that can be leveraged to procure innovative commercial solutions that could include a DevSecOps development environment. CSO procedures can be used to award FAR-based contracts or agreements, to include Other Transaction agreements.

 SBIR Phase III

SBIR Phase III Other Transaction agreements can be awarded non-competitively to any contractor that has completed SBIR Phase I or Phase II work. There is no limit on the dollar value, contract type, or appropriation.

Prototype Other Transactions (OTs)

Prototype OTs and subsequent follow-on Production OTs are applicable to SWP program requirements that meet the definition of prototype projects.

When considering OTs, consider the core purposes:

• Provide government with access to state-of the art technologies, processes, and solutions from innovators.
• Leverage business practices that are common in industry to achieve speed and relevance.
• Provide flexible business arrangements that are tailored to project and stakeholder needs.

Other Transactions may be awarded by DoD organizations with warranted Agreements Officers OR by leveraging existing Other Transaction Consortia. Other Transactions may also be awarded to solution providers on the CDAO Tradewinds Solutions Marketplace and PlatformOne Marketplace.

The following use of Prototpye OT to follow-on Production OT is provided as an example. Tailor accordingly based on program specific needs.

_____________________________________________________________________________

DevSecOps Contract Metrics

Focus on the warfighter needs and establish metrics that matter to their mission. Metrics may change throughout the life of a program, but it is important to measure contractor effectiveness against programmatic goals.  Contractors must be incentivized and rewarded based on this value construct.

See also the SWP Metrics and Reporting page.

Contracting for Agile Software Development

Reference Source: OUSD (A&S) Guidance

Agile software development is characterized by continuous change and reprioritization of requirements. This is a value driven approach where cost and schedule are fixed to allow the scope to change. This is a shift from contracts for traditional development that are plan driven, where the scope is a defined set of requirements that is fixed and does not change without an engineering change proposal and subsequent contract modification. A value driven approach for Agile software development calls for flexible software development contracts that allow the scope (prioritized capability needs in the government managed product backlog) to change in order to develop and deliver functional capability.

Traditional development contracts are written for contractors to deliver against a wholistic and specific set of requirements. Changes to requirements after contract award require an engineering change proposal and subsequent negotiation and contract modification. Changes can be costly and disruptive to the development process as work is continuously repriced and replanned.

Contracts for Agile software development are based on dynamic requirements (contained in the Product Backlog) enabled by modern software development practices (Agile and DevSecOps) and active user engagement to achieve iterative deliveries. Contracts with flexibility allow a contractor to develop capability in response to continuously evolving requirements.

Agile development methods such as daily collaboration between Government and contractor teams, a mutually agreed-upon definition of “done” for each sprint/release cycle, and metrics informing the Government about the quality of capability developed and delivered allow the Government to continually assess contractor performance.

_____________________________________________________________________________

What is a Flexible Contract for Agile Software Development?

Contracts that are flexible are built to be resilient to an evolving Product Backlog without requiring formal contract modifications. Examples of flexibility include:

• A variety of labor categories (LCATs) and functions with sample hours to establish a ceiling from which to consume future, variable, undocumented, or surge needs. LCATs can allow for variability within a ceiling that can be adjusted on a development sprint basis without the need for contract modifications.
• Non-CDRL ‘swaps’ of deliverables (based on Contracting Officer’s Representative written approval) using completion-based outcomes.

Flexible contracts for software development teams can be created using all contract types. See the Contract Types section below.

_____________________________________________________________________

Contracting Strategies for Agile Software Development

As part of a modular contracting construct, multiple contracts for software development can be executed to develop discrete capabilities of the overall solution managed by the program. When contracting for multiple development teams, the Government should have the integrator role (or hire a software integrator to perform this function in close collaboration with the Government) and be in full control of prioritizing the product backlog and managing the development process to ensure individual development contract activities align with program architecture, vision, and other development activities. Contracting strategies to consider for software development include the following:

Commercial Solutions Opening (CSO)

CSO solutions offer streamlined procedures that could be leveraged to procure innovative commercial solutions that could include software development solutions. CSO procedures can be used to award FAR-based contracts or agreements, to include Other Transaction agreements.

Prototype Other Transactions (OTs)

Prototype OTs may be considered for efforts that meet the definition of a prototype project.

When considering Prototype OTs, consider the core purposes:

• Provide government with access to state-of the art technologies, processes, and solutions.
• Leverage business practices that are common in industry to achieve speed and relevance.
• Provide flexible business arrangements that are tailored to project and stakeholder needs.

Other Transactions may be awarded by DoD organizations with warranted Agreements Officers OR by leveraging existing Other Transaction Consortia. Other Transactions may also be awarded to solution providers on the CDAO Tradewinds Solutions Marketplace and PlatformOne Marketplace.

SBIR Phase III

SBIR Phase III OT agreements can be awarded non-competitively to any contractor that has completed SBIR Phase I or Phase II work. There is no limit on the dollar value, contract type, or appropriation.

Industry Perspectives for Agile Software Development Contracts

Reference Source: OUSD (A&S) Guidance

OSD partnered with DISA to conduct field research in an effort to understand industry perspectives and pain points contracting with the DoD for software development solutions as well as recommendations for improved contracts for software development. The following considerations and recommendations represent industry views for software development contracts.

Technical Data Rights and Intellectual Property (IP)

Reference Source: OUSD (A&S) Guidance

In accordance with DODI 5000.87 and DODI 5010.44, SWP programs are required to have IP strategies that identify and describe the management of delivery and associated license rights for all software and related materials necessary to meet operational, cybersecurity, and supportability requirements.  The IP strategy must support and be consistent with all other government strategies for design, development, test and evaluation, operation, modernization, and long-term supportability of the software, protection of the software supply chain, and must be implemented via appropriate requirements in the contracts.

Data Rights describe how the government can use, modify, reproduce, perform, display, release, or disclose the data and software provided by the contractor. Deliverables are the data and software a contractor is required to deliver to the government. Software deliverables provide no value without the appropriate license rights to use them. Once the program has identified and tailored the necessary technical data and software deliverables and license rights, ensure there is a requisite CDRL (or DAL) deliverable and those requirements are consistent with language in work statements and other contractual documents.

See the IP Strategy page for more details, including evaluating IP as part of the source selection process.

The DoD IP Cadre offers program advising and other resources to support DoD acquisition programs.

DAU hosts an IP & Data Rights Community of Practice and offers a set of courses leading to an IP Credential.

Open Architecture/Application Program Interface (API)

Reference Source: OUSD (A&S) Guidance

The DoD is transforming from a closed architectural approach that challenges collaboration and integration of systems to a one that anticipates software integration through standards-based Application Program Interfaces (APIs). An API is a system access point that allows application programs to provide well-defined functionality and to promote interoperability, security, and scalability. The OUSD Research & Engineering (R&E) organization published the Application Programming Interface (API) Technical Guidance providing an overview of API concepts in software development.

APIs facilitate interoperability, data sharing, collaboration, and integration of systems and capabilities across different branches and units within the Department and with allies. Interoperability is critical to modern software systems, joint warfighting, artificial intelligence (AI) superiority, and achieving the DoD Data Decrees:

SWP programs are required to develop an API Strategy to lay out the planned approach to interoperability including identifying key data and services that can be offered through APIs, driving architectures, establishing API governance, and establishing API metrics.

SWP program contracts should include applicable API guidance from the program’s API strategy and clearly state that the government retains ownership of its data, even when it is accessed or manipulated through the APIs.

Additionally, programs may consider developing a Section H Clause to ensure that necessary rights to data, data products, applications, code, or other content developed by the government or third parties remain with the government.

Acquiring Innovative Software Solutions

Reference Source: OUSD (A&S) Guidance

There is a continuing need for DoD to acquiring innovative solutions, especially in the continously evolving software development space. This includes incentivizing non-traditional contractors (NDCs) to do business with the Department. Modular contracting strategies (in conjunction with open architectures & APIs) create opportunities for NDC innovators to contribute individual capabilities to larger program objectives. The DoD can create opportunities to maximize participation by NDCs that will benefit SWP programs and foster innovation by:

Streamlining Evaluation and Vendor Selection

Reference Source: OUSD (A&S) Guidance

There are numerous approaches that can be used to help ensure that the contractor/s selected for award will have the expertise to deliver the highest value solutions.  These approaches are applicable beyond software development solutions, but are particularly helpful in assessing the capabilities of contractors in the software development space where requirements are less defined that those of traditional waterfall development projects. Some of the below examples are detailed in greater depth by the DHS Procurement Innovation Lab’s Bootcamp Workbook.

Standard written proposals are often not optimized for software development contract source selections. Although it may require more upfront planning, using an array of interactive source selection techniques (e.g., oral presentations, demonstrations, and/or challenges) offers a superior approach. These methods enable the Government to acquire better solutions by evaluating the technical expertise of contractors versus rewarding firms who can articulate a proposal well. These techniques also enable vendors to demonstrate their portfolio of technical capabilities.

Industry has a strong preference for well-designed and meaningful challenge events, including technical demonstrations and oral presentations, instead of delivering traditional paper proposals and enduring lengthy source selections. Meaningful challenges and oral proposals focus on the Agile and DevSecOps process. They enable the government to evaluate vendors in action and often to interact with the key technical persons that will be supporting the effort in execution. They can also streamline source selection timeframes and accelerate time to contract award by reducing the number of full proposals the government must evaluate.

The following techniques may be used individually or combined to craft an approach tailored for a program’s specific objectives.

Resources