Software Acquisition

AAF  >  Software Acquisition  > Develop Strategies  >  Contracting Strategy

Contracting 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.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.

A deliberate and well-planned Modular Contracting strategy can provide SWP programs with flexible contracting options for establishing and maintaining software development/test environments and separately acquiring software development teams to deliver capability and enable programs to scale and evolve over time. The following sections provide guidance regarding modular contracting and choosing contract strategies for specific needs.

 It is strongly recommended that Contracting Officers take the Digital DNA course (currently a pilot initiative) offered by OUSD A&S to establish a software development knowledge foundation.

Modular Contracting

Reference Source: OUSD (A&S) Guidance

Modular contracting is the preferred approach for acquiring major information technology systems in accordance with 41 U.S.C. §2308. Modular contracting for information technology and 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 a collection of contracts with different objectives to best meet the many requirements and objectives throughout a program’s lifecycle. For each individual contract in a modular strategy, Contracting Officers have flexibility to pursue contracting strategies that best fit the specific requirement.

Instead of a single monolithic contract –> A portfolio of contracts enabling a program to
scale and evolve over time

FAR 39.103 - Modular Contracting

Reference Source: FAR 39.103 – Modular Contracting

Modular contracting is intended to reduce program risk and to incentivize contractor performance while meeting the Government’s need for timely access to rapidly changing technology. When using modular contracting, an acquisition of a software system may be divided into several smaller acquisition increments that:

  • Are easier to manage individually than would be possible with one comprehensive acquisition.
  • Address complex IT objectives incrementally in order to increase the likelihood of achieving workable systems or solutions for attainment of those objectives.
  • Provide for delivery, implementation, and testing of workable systems or solutions in discrete increments, each of which comprises a system or solution that does not depend on any subsequent increment in order to perform its principal functions.
  • Provide an opportunity for subsequent increments to take advantage of any evolution in technology or needs that occur during implementation and use of the earlier increments.
  • Reduce risk of potential adverse consequences for the overall project by isolating and avoiding custom-designed system components.

Solutions acquired through modular contracting for each increment should comply with common or commercially acceptable information technology standards when available and appropriate and conform to organization/program IT architectures.

Performance requirements of each increment should be consistent with the performance requirements of the overall system within which the solution will function and should address interface requirements with succeeding increments.

For each increment, contracting officers shall choose an appropriate contracting technique that facilitates the acquisition of subsequent increments.

Contracting Strategies

Reference Source: Contracting Cone

The Contracting Cone presents the full spectrum of FAR and non-FAR based contracting solutions available for consideration.

Contract strategies to consider in developing a modular contracting strategy include (but are not limited to) the following:

Components of a Modular Contracting Strategy

Reference Source: OUSD (A&S) Guidance

Not all programs are starting from the same place and a modular contracting strategy for one program is likely to look different from another program. It’s important to understand what a program already has and what the program needs to acquire to develop a modular contracting strategy tailored to the unique needs of a program. This enables the program to develop a collection of contracts with different objectives to meet different requirements that support the overall program objectives. The collection of modular contracts should be expected to change and evolve throughout the program lifecycle, especially as scaling occurs and more development activities are added.

The following sections address contracting for two distinct areas applicable to software development: DevSecOps Environment and Agile Software Development. A program may or may not need to establish contracts for each of these areas depending on what it currently has (i.e., existing enterprise platform solutions, an existing Software Factory that will be leveraged, existing government or contractor development teams), and where the program is in its lifecycle (i.e., beginning a new program or transitioning an existing program to the SWP).

A program will likely have other requirements such as licensing for communication/ collaboration tools, data solutions to access and modify data, subject matter expertise to enable the program to design, secure, and scale its solution architecture (i.e., cloud enterprise architects, platform engineers, cybersecurity engineers, software engineers, DevSecOps engineers, Agile software development coaches), legacy system sustainment contracts, etc. An embedded software program will have other needs and requirements (i.e., weapons system hardware) that are not addressed as part of the SWP.

DevSecOps Environment

Reference Source: OUSD (A&S) Guidance

“Our initial contract was to build a complete product (big, multi-year Cost-Plus contract) on a high-visibility program. In order to implement Agile we had to create a prototype software factory that could serve as a key underpinning for taking the entire program and entire program office. This required us to figure out how to build a software factory and generate multiple smaller contracts over shorter time periods. This generates freedom of motion for the government and continuous competition between vendors. Further, the gov’t maintains ownership of the development pipeline, code base/end product (IP), related data, and can dictate DevSecOps principles and tools that vendors are required to leverage.”

– AEGIS (NDAA FY18 Sec. 873 Agile Pilot Program)

 

What is DevSecOps?

Reference Sources: DoD DSO Enterprise Strategy Guide 2.0 and
DoD DSO Enterprise Fundamentals 2.0

DevSecOps is a culture and philosophy, realized through a collection of software automated tools, services, and standards that enable programs to develop, secure, deploy, and operate applications in a secure, flexible, and interoperable fashion by reducing the gaps between a software developer team, a security team, and an operations team.

The DevSecOps lifecycle is an iterative closed loop that spans eight distinct phases: Plan, Develop, Build, Test, Release & Deliver, Deploy, Operate, and Monitor.

DevSecOps Lifecycle Phases

DevSecOps Lifecycle Phases

****There is not a uniform set of DevSecOps practices****


A program may need to contract for solutions such as the following to establish a DevSecOps Environment:

Infrastructure-as-a-Service (IaaS)

IaaS

Computing, storage, network resources, and additional managed services to enable function, cybersecurity, and non-functional capabilities.

  • IaaS provides a hosting environment for a DevSecOps Platform and Software Factory.
  • Typically an approved or DoD provisionally authorized environment provided by a Cloud Service Provider (CSP), but on-premise (on-prem) infrastructure solutions may be necessary to support some classified or secure enclave environments.
  • A program’s infrastructure solution may be a combination of CSP and on-prem IaaS subscriptions.
  • Leverage existing enterprise IaaS services before contracting for unique services.

 

IaaS Contracting Strategy Considerations

Leverage DISA ESI contract vehicles for cloud solutions and support services:

Leverage GSA Federal Supply Schedules (FAR Part 8.4) for cloud support services:

The DoD Cloud Computing Acquisition Guidebook offers additional guidance on acquiring cloud services.

DevSecOps Platform-as-a-Service (PaaS) / Software Factory

DevSecOps PaaS

Hardware and tools to establish the DevSecOps platform.

  • DevSecOps PaaS solutions provides distinct development environments for a Software Factory.
  • Leverage existing enterprise solutions if an organization is already pursuing DevSecOps.

Software Factory

Processes and practices to establish a development environment in which developers create custom software artifacts.

  • A Software Factory contains one or more Continuous Integration/Continuous Delivery (CI/CD) pipelines that provide automated processes and tools to support a specific program or mission through the Develop, Build, Test, Release, and Deliver phases of the DevSecOps lifecycle (refer to graphic in DevSecOps Toggle above).
  • CI/CD pipelines (or toolchains) provide automated processes and tools uniquely tailored to support a specific program or mission and are used by software application developers.
  • A DoD organization or program may need multiple CI/CD pipelines for different types of software systems, such as web applications or embedded systems

Note: Establishing a continuous Authority to Operate (cATO) for a Software Factory is the responsibility of the cognizant government Authorizing Official (AO). cATO is not provided by a contractor.

 

DevSecOps PaaS/Software Factory Contracting Strategy Considerations

Options include (but are not limited to) the following:

  • Leverage existing organization DevSecOps Platform/Software Factory offerings.
  • Leverage existing BOA or IDIQ vehicle to issue task order award for necessary solutions.

Existing DevSecOps PaaS/Software Factory solution offerings include:

 

Evaluating DevSecOps Solutions

Evaluate proposed DevSecOps solutions for alignment to the DoD DevSecOps reference design principles. Require vendors to develop a plan that aligns with key DSO documents such as: DoD DSO Enterprise Fundamentals 2.0

Another option is to evaluate the completeness of proposed approaches for establishing an enterprise solution with key components of a Software Factory:

Team Collaboration System Issue Tracking System Integrated Development Environment
Source Code Repository Build Tool Artifact Repository
Automated Test Development Tooling / Suite Alerting and Notification Strategy Static and Dynamic Application Security Test Tools
Log Strategy Continuous Monitoring Test Coverage Reporting Tool

 

Agile Software Development

Reference Source: OUSD (A&S) Guidance

The program narrowed the contract tasks to providing software development expertise and establishing a team and facilities capable of implementing Agile in an environment unavailable to the government, at the time. With the government team working alongside the contracted coders in their facility, the government was able to establish and maintain control over daily priorities and focus areas. This provided improved insight into the root cause of inevitable issues, and streamlined the implementation of necessary change to set the conditions for a collaborative, “one-team” culture[…]Adopt a level of effort type contract with industry, and establish the government as being responsible for software production…Create a development environment that includes industry…and government personnel habitually working side-by-side.”

– IAMD (NDAA FY18 Sec. 873 Agile Pilot Program)

 Agile software development is characterized by continuous change and reprioritization of requirements. This calls for flexible contracts that allow the scope (prioritized capability needs in the government managed product backlog) to change in order to develop and deliver functional capability. This is a shift from traditional contracts 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. 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.

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 and in full control of prioritizing the product backlog and managing the development process to ensure individual development contracts align with architecture, vision, and other development activities.

Agile Software Development Contracting Strategy Considerations

Contracting strategies to consider for Agile software development solutions include (but are not limited to) the following:

Federal Supply Schedules (FAR Part 8.4)

  • Leverage GSA’s Multiple Award Schedule (MAS) Information Technology for software development solutions.
  • Establish multiple-award BPAs offering similar flexibility to IDIQ contracts for accessing GSA schedule holders that offer software development solutions.
  • Enables an organization or program to have multiple teams aligned to a DevSecOps/Software Factory environment and architecture defined in the base contract.
  • Consider on/off ramps to maintain flexibility and access to new developers over time.

Commercial Items (FAR Part 12)

  • If pursuing software development teams as commercial solutions, awards under FAR Part 12 can provide access to a broader set of vendors using commercial terms and conditions.
  • Can be combined with FAR SubPart 13.5 to use simplified procedures under stated dollar threshold.

 Simplified Acquisition Procedures (FAR Part 13)

  • If pursuing software development teams as commercial solutions, awards using streamlined procedures provided by FAR SubPart 13.5 can provide access to a broader set of vendors using commercial terms and conditions, under stated dollar threshold.

Indefinite Delivery Indefinite Quantity (IDIQ) Contracts (FAR 16.5)

  • Leverage an existing IDIQ, GWAC, or MAC vehicle to issue task/delivery order award
  • Establish a new multiple award IDIQ contract to quickly execute task/delivery orders for new development activities to provide an avenue to scale and add more development teams as program evolves.
    • Enables an organization or program to have multiple teams aligned to a DevSecOps/Software Factory environment and architecture defined in the base contract.
    • Consider on/off ramps to maintain flexibility and access to new developers over time.

Basic Ordering Agreements (BOAs) (FAR 16.7)

  • Create new BOAs to establish negotiated terms and conditions (but not pricing) with a pool of vendors for uncertain future software development requirements.
    • Enables an organization or program to establish terms and conditions aligned to a DevSecOps/Software Factory environment and architecture defined in the agreement.
    • On/off-ramp vendors at any time to maintain flexibility and access to new developers.

Small Business Set-Asides (FAR 19.5)

  • Many small businesses are capable of providing software development services.
  • May provide access to developers with unique skill sets or technology focus areas that are not on existing IDIQ/GWAC/MAC contracts or GSA schedules.

 

Product vs Services Contracts for Agile Software Development

DoD programs have used both product and service contracts for software development teams. Both can be structured to describe objectives and desired outcomes (captured in Vision or Capability Needs Statement) rather than a detailed set of requirements.

A specific definition of “done” is not defined in the contract, but instead established at the beginning of each sprint or iteration, in collaboration with the government. The definition of “done” should mean that working software has been produced, meeting the criteria that has been has defined and agreed to by both government and contractor (i.e. documented, tested, verified, releasable).

Use a Statement of Objectives (SOO) or Performance Work Statement (PWS) to describe objectives and desired outcomes.

Software Development – Services Software Development – Product
Government contracts for the time and expertise of a developer team to develop and deliver applications or solutions.

 

Government contracts for delivery of a specific application or solution.

 

 

Tip: Pursuing commercial solutions for software development enables a program to pursue commercial contracting strategies leveraging FAR Parts 12 and 13.5.

Example Language for Agile Software Development

The following buttons provide example content for creating work statements for task orders awards or new IDIQ contracts for Agile software development. Though created for IDIQs, the language may also be leveraged to develop work statements for other contracting strategies.

Contract Types for Agile Software Development

Contracts for software development teams have been executed using all contract types. Contract type selection will depend on a variety of factors to include selected contract strategy, product or service contract, level of government involvement in development activities, etc.

The Contracting Cone provides a Matrix that maps the contract types that are allowed for each of the contract strategies.

Fixed-Price

Reference Source: OUSD A&S Contracting Considerations for Agile Solutions

Fixed-price contracts are most applicable in situations where performance estimates can be reasonably identified and estimated, usually informed by historical costs. Fixed-price contracts can and have been used to acquire Agile software development teams to accommodate the continuous reprioritization of requirements in the product backlog. One way to do this is by fixing the price of the level-of-effort that the contractor should provide over a specified time period and enabling requirements in the product backlog to continuously evolve. The price is negotiated using specified hours in specified labor categories (e.g., software engineer, software developer, software tester, product manager). Contract periods of performance (PoPs) can be short (e.g., 6-12 months) to align with release cycles and can include options to continue development support as needed. Alternatively, task orders or BPA calls can be executed on a recurring basis (e.g., per release) based on program objectives and desires.

Using a Services construct, the scope of the contract or task order is to provide Agile development services. The Agile requirements are identified in a dynamic product backlog that is regularly reprioritized by the Government. Contract modifications are not necessary to reprioritize, add, or delete Agile requirements from the product backlog. The order of development is ultimately determined by the government. A clearly stated and agreed-to definition of done, established at the start of each sprint and release cycle, ensures the Government receives the expected incremental value from the contractor.

The U.S. Digital Services (USDS) TechFAR provides scenarios for Agile software development using fixed-price contracts and offers notional line-item structuring iterations (sprint cycles) with the unit of measure being the iteration.

Another option is to use a capacity-team-based approach leveraging firm-fixed-price contracts to deliver Agile development services. Under this model, Agile teams deliver value within contractually defined technical constraints.

Time & Materials

Reference Source: OUSD A&S Contracting Considerations for Agile Solutions

DoD programs have used Time and Materials (T&M) contract types to acquire the services of Agile development teams by scoping increments into task requirements aligned to the product backlog. The Government must negotiate labor rates when using a T&M contract type, and establish a ceiling price.

T&M contracts can provide maximum flexibility for Agile development, especially at the start of a development effort when a team’s velocity (measure of amount of work completed in a given sprint for a given Agile team) has not yet been established. Since an Agile development strategy calls for daily interaction between the Government and contractor staff, a mutually agreed upon definition of done for each sprint/release cycle, and metrics informing quality of capability developed and delivered, the controls needed to monitor contractor performance are built into the Agile development process and provide oversight to ensure delivery of expected working capability and effective cost containment under a T&M arrangement.

Structuring around smaller, frequent releases (e.g., six months) limits the risks often associated with a T&M contract because of the shorter period of performance. Additionally, a T&M or Labor-Hour contract type may be beneficial if a program is using a modular contracting approach under which one vendor has no direct or exclusive control over the outcome of the products. The Government must be the integrator in this scenario.

An example is provided by 18F’s An Agile Software Development Solicitation Guide.

The 18F Federal Field Guide advocates for performance-based service contracts and recommends short periods of performance (6-12 months) with options that don’t exceed a contract length of three years. The guide also provides additional information such as an Agile contract format, evaluation considerations, sample T&M determination and finding, QASP samples for software development services, and other recommendations.

Cost-Reimbursement

Reference Source: OUSD A&S Contracting Considerations for Agile Solutions

Cost-reimbursement contracts may be appropriate when the necessary labor hours and labor mix are not well understood. The Software Engineering Institute’s (SEI) Contracting for Agile Software Development in the Department of Defense: An Introduction technical paper offers the following perspectives on cost-type contracts for Agile development:

Cost-reimbursement contracts potentially allow for refinement of the requirements based on the evolution of the working system and the priority for functionality defined by the Product Owner. To be effective, this type of contract requires adequate Product Owner capability to manage and oversee the contracted work. Effective Product Owner capability and active interaction and collaboration, focused on delivery of working software, increases the success of developing the right working software. The flexibility to adjust to changing operational system needs is built into the statement of work or objectives that accompanies the contractual funding constraint.

SEI noted that fixed work cycles and software release cycles, with constraints on the amount of work scheduled for the fixed work cycles, enabled the Government to prioritize work.

The following are noteworthy when considering cost-reimbursement contracts for Agile software development:

  • Cost-reimbursement contracts require contractors to have certified cost and accounting systems to be eligible for award. This can provide a barrier to entry for small and non-traditional contractors and can have the unintended consequence of limiting participation by smaller companies.
  • The use of cost-reimbursement contracts is prohibited for the acquisition of commercial items and when using GSA schedule contracts.
  • The Government assumes more risk in a cost-reimbursement arrangement than in a fixed-price contract, as the contractor is less incentivized to control cost.

Agile Software Development Deliverables

Traditional development contracts include a detailed perspective list of contract data requirements list (CDRL) deliverables. An extensive list of deliverable documents is not required for Agile software development. When applied appropriately, Agile software development is a structured and disciplined process that encourages an incremental approach to design and delivery. A program should request enough documentation to validate that capabilities are being delivered in compliance with governance and IT system lifecycle requirements.

CDRL Alternatives

To avoid excessive CDRL documentation, a program should:

  • Distinguish between high-value documents and those that simply “check the box” or do not contribute to the value or quality of the product being delivered.
  • Work with stakeholders to nominate traditional deliverable documents that do not add value to Agile development for exclusion.
  • Streamline the format of the required documents as appropriate and work with the decision authorities to align on an incremental and iterative approach to document completion (to follow the cadence of Agile delivery and align with emergent design principles).
  • Consider possible efficiencies that could be gained by changing the format and delivery of the artifact. For example, consider whether the artifact can be automatically generated from the project tools being used by the program.

There are some instances when it may make sense to retain a CDRL including:

  • The artifact is part of the government baseline (for example, the software architecture).
  • The document requires government approval (for example, the Software Development Plan).
  • Artifacts that will need to be shared with other contractors or government agencies outside the program (for example an ICD).

A program may also consider alternatives to the traditional CDRLs for Agile software development. All programs are different, but the following may be useful in minimizing the time and overhead associated with CDRLs.

One such alternative to a CDRL is the Data Accession List (DAL). Unlike a CDRL that a contractor is required to submit, the DAL provides a medium for identifying contractor internal data generated in compliance with the work statement that the government may request if the need arises. Some artifacts may not even need a DAL form. For example, if there is a Software Development Plan that states that test procedures are developed for unit tests, then those should automatically be posted to the DAL. If the contractor’s format and content are acceptable then the government would not likely need a CDRL or a DAL form. For large program, a DAL may be needed to ensure consistency in format and content across multiple development teams.

If a program is using a DevSecOps environment and the government has full access to the environment and the data generated within the environment, then a CDRL/DAL may not be needed to access data that otherwise might require a CDRL/DAL. One example of this might be metrics data. Typically metrics data is requested using a CDRL, but could instead be delivered in the DevSecOps environment if the data is available to the program office straight from the DevSecOps environment. This can also be true for other data available in the DevSecOps environment such as test data and source code.

The program may consider using DevSecOps data or a DAL for recurring Agile software development artifacts (i.e., design documentation for each sprint) and only require a CDRL delivery at the completion of the development effort.

Article: From CDRLs to Agile Services (Alternative considerations for leveraging DevSecOps/Agile development processes in place of traditional CDRLs).

Evaluation and Vendor Selection Techniques

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.

Multi-Phased Evaluations

Narrow down the number of offerors to ideally evaluate 2–3 offers for each award.

Confidence ratings can be used under FAR Subpart 8.4 (orders/BPAs against schedule contracts), Part 13 (simplified acquisitions), Subpart 15.3 (source selections), and SubPart 16.505 (fair opportunity for orders under multiple‐award IDIQ contracts).

DO DO NOT
Use multiple down-select gates to reduce wasted Gov’t and industry resources, starting with the least amount of information needed for the evaluators to make a go/no-go decision and asking for more detailed information subsequent rounds.

Use a confidence rating with a few supporting bullets to support the rating.

Use adjectival ratings that limit evaluators to a certain rating based on having a certain number of strengths or weaknesses as this is not flexible and may overly restrict the evaluators’ ability to assign meaningful ratings.

Oral Presentations

Allow the program technical staff to see and hear proposed solutions from the team that would perform the work which provides a much more in-depth perspective of the proposed offer.

Provides greater confidence the company understands the technical requirement.

DO DO NOT
Include on‐the‐spot questions.

Add a twist by interrupting their pitch with a particular scenario for them to address.

Use consensus evaluations immediately following each offeror’s oral presentation.

State that a contractor may attend only one oral presentation.

Eliminate offerors via competitive range determination if the number of offerors is excessive.

Consider inviting the end user or customer to the presentation to gain valuable insight that either supports or negates the proposal’s key points.

Require the offeror to cover ALL aspects of the requirements document; rather, focus on the most important aspects and go into detail!

Leave ambiguity in the solicitation concerning rules or format for the orals.

Assume that you must videotape the presentation – there are several possibilities. Allow the offeror’s presenters to use electronics or phones for reach back.  Duplicate work by asking for a detailed written proposal and a detailed oral presentation.

Product or Technical Demonstrations

Used to see, feel, and test out a product/system.  This technique can help reveal a companies’ true capabilities. They can also streamline the selection process and lower bid and proposal costs.

 

DO DO NOT
Use as either a stand‐alone factor or an element of the oral presentation.

Include a ‘test plan’ in the solicitation so industry knows what is being tested.

Ensure end‐users are included in the evaluation, as their feedback is crucial.

Pair with confidence level ratings.

Substitute the demonstration as the entirety of the technical proposal as there are other elements that will likely need to be considered.

Advisory Down-Select

Notify low-rated offerors that they have little chance to receive an award before they submit detailed technical and price proposals. If those non-competitive offerors self-select out of the competition, there are many benefits:

  • They have no standing to file a protest.
  • Reduces industry costs and burden to industry.
  • Reduces the amount of documentation for the Government to review.
  • Improves the final trade-off decisions.

 

DO DO NOT
Maintain at least 2‐3 vendors at the final phase to ensure a robust competition.

Use the most important factors to conduct the down-select, makes it higher impact.

Keep the factors planned for the down-select light so industry investment stays low.

Conduct in combination with confidence ratings, on‐the‐spot consensus, and oral presentations.

Substitute the demonstration as the entirety of the technical proposal as there are other elements that will likely need to be considered.

Resources