Agile Methodologies and the Federal Acquisition Regulation – Part 2

This is the second article in a 3-article series on integrating Agile methodologies within the context of the Federal Acquisition Regulation. This article focuses on considerations for selecting a contract vehicle and creating the most appropriate contract pricing structure from a Government Agency’s point of view…

This article series is based upon the recently developed TechFAR Handbook for Procuring Digital Services Using Agile Processes. The handbook highlights the flexibilities of the Federal Acquisition Regulation (FAR) with respect to procuring IT services and products through contractors who employ Agile methodologies. The Office of Management and Budget is currently accepting comments on the handbook in order to develop a comprehensive guide for Agencies.

The first article in the series focused on Requirements Development and Acquisition Planning. Key suggestions in this early phase of the acquisition lifecycle include developing a Product Vision, creating a description of how Agile processes will be used to fulfill the Product Vision, and understanding how an evolving product definition and product iterations will support the documentation required by an Agency.

Once a Product Vision is established with a corresponding solicitation description of Agile processes, the procurement team can consider contract and pricing options.

Contract Vehicles and Use of Existing IT Contracts

According to OMB’s 2012 Contracting Guidance to Support Modular Development, Agile software development and IDIQ contracts are especially compatible because IDIQ contracts are flexible and provide significant acquisition responsiveness. However, other types of contracts, including modular contracts, single award and stand-alone contracts, can also be used.

Contracting Officers (COs) may use existing contracts for IT if the contract under consideration supports Agile software development. However, if it does not, other contract vehicles may be used. In practice, COs should evaluate existing contracts using established Agency procedures, document any reasons why existing contracts are incompatible with Agile software development and seek a new contract vehicle if necessary.

Pricing Considerations

Selecting a contract for Agile software development is no different than selecting any other contract, thus, fixed price arrangements are not required. Under FAR, the selected contract type should provide maximum performance incentive and reasonable contractor risk.

Fixed price contracts are often preferable for certain types of jobs in which requirements are easily identified. A Fixed Price contract may be effective for Agile methodologies by structuring 3-6 month option periods to encourage high contractor performance. Line items may be structured by iterations or sprint cycles and Agencies may account for additional work using optional line items.

In the past, Agencies have successfully used fixed price contracts for:

  • Development of an enterprise system with cloud-based apps
  • Development of an electronic enterprise platform to centralize interaction and communication

If the circumstances don’t necessitate a fixed price contract, other types of contracts, including labor hour contracts or time-and-materials contracts, may be more appropriate. Agencies have previously used time-and-materials or labor hour contracts for:

  • Blended teams where no single vendor has control
  • Complex electronic medical record systems
  • Integrated electronic benefit systems

In some cases, Agencies may be able to use hybrid contracts to determine pricing. For example, some portion of the work could be priced using labor hour methods, while other work is awarded based on a fixed price arrangement.

When approaches other than fixed price are utilized, Agencies are able to ensure accountability among contractors by requiring them to meet the specifications of an Agile software development iteration schedule. Under the Agile software development process:

  • Requirements are defined at the beginning of each sprint
  • Testing is utilized throughout the process to ensure quality
  • Cost and schedule performance are measured using standard performance metrics

To ensure the quality of results, the “definition of done,” which is established at the beginning of each iteration, must be objective and comprehensive. This definition must ensure that the application is accessible to all users, that the software meets all of the agency’s criteria and that the contractor has met cost and schedule goals.

Fair and Reasonable Pricing

To ensure that prices are fair and reasonable, COs must first establish the definition of a fair and reasonable price. Agencies must establish this definition based on comparisons with other rates in the industry in question. Agencies can compare proposed prices to prices the Agency has paid in the past, as well as to prices obtained through market research.

To establish fair and reasonable prices, COs can request specific information from vendors about their quotes. All quotes submitted should provide backup documentation to support pricing. Quotes should also demonstrate the correlation between pricing and the proposed technical solutions. COs should also ask each bidder to propose a number of required iterations, along with prices for each iteration. Alternatively, COs may fix the number of sprints and ask bidders to propose a price for each sprint.

When preparing the Independent Government Cost Estimate, Agencies should estimate both direct costs and indirect costs using market surveys and historical pricing information. One strategy for IGCE development involves estimating the cost involved in each user story based on a coarse abstract scale, assigning a price range to each scale value and calculating a high and low estimate of total cost. Another strategy involves fixing sprint timeframes, fixing the number of sprints and multiplying by the estimated cost per sprint.

While all contract types and pricing structures are available to a CO to fulfill a requirement for Agile software development, some may be more optimal in helping the agency achieve its objectives.

In the next article, we will look at contract administration best practices, including contractor accountability and tracking progress. To continue the discussion about how to use Agile in the context of the Federal Acquisition Regulation, contact us.

facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmailby feather