Skip to main content

Pricing considerations


Because Agile software development is heavily process-driven, must agencies only use fixed-price contracts to get the desired result?

The selection of a contract pricing structure for acquisitions using Agile software development is no different than those for any other contract. Contracts utilizing Agile software development are not limited to fixed-price arrangements; the CO is encouraged to select the pricing structure that will result in reasonable contractor risk and provide the contractor with the greatest incentive for efficient and economical performance.

The selection of a contract type for acquisitions using Agile software development is no different than those for any other contract. As with all contracts, there is not a one size fits all pricing structure that fits all contracts using the Agile software development methodology. FAR 16.103(a) states that selection of contract type requires exercise of sound judgment that will result in reasonable contractor risk and provide the contractor with the greatest incentive for efficient and economical performance.[19]

In cases where requirements are easily identifiable, fixed-price contract types have the advantage of shifting risk to the contractor, which gives the contractor the maximum incentive to control costs and perform efficiently. Fixed-price contract types have been used successfully for commercially available off-the-shelf item solutions or developmental services for software projects or increments where the Government knows the specific functional characteristics that will satisfy its objectives. A Fixed-price model focusing on a fixed process and objectives can be highly effective by utilizing short option periods (e.g., 3-6 months) to ensure high levels of performance.

On the other hand, time-and-materials (T&M)[20] or Labor-Hour contract types may be suitable if circumstances do not allow the agency to define its requirements sufficiently to allow for a fixed-price type contract and uncertainties involved in contract performance do not permit costs to be estimated with sufficient accuracy to use a fixed-price arrangement. See FAR 16.6. In these cases, forcing a fixed-price arrangement could force the contractor to build in unnecessary contingencies that would result in a higher price for the Government. It is important to take into account that contract types other than fixed-price may be delivered at a lower cost because the Government has more control over funding and development decisions. Additionally, a T&M or Labor-Hour contract type may be beneficial if an agency is using a blended team where one vendor has no direct or exclusive control over the outcome of the products.

Types of Agile Software Development Successfully Acquired

Agencies have used T&M or Labor-Hour contracts for Agile software development for:

Agencies have used Fixed Price contracts for Agile software development for:

Per FAR 16.103(c), an agency might consider hybrid contracts that allow the agency to achieve a better match between the requirement and how the work is priced. Work for which there is a basis for firm pricing could be awarded for a fixed-price (FP) while requirements for which there remains considerable uncertainty can be acquired on a T&M or Labor-Hour basis. IDIQ contracts can be structured as hybrid contracts to allow the agency to choose among the various pricing structures. Another example could be having a hybrid contract with FP for the milestone releases and Labor Hour type line items for the sustainment. If the agency has a hybrid contract with T&M as a component, the agency is encouraged to move to fixed-price when pricing history is established and when the pace as an integrated team is set.

If other than fixed-price based approaches are used, such as those in FAR 16.3 (addressing cost-reimbursement contracting) and FAR 16.6 (addressing T&M and Labor-Hour contracts), agencies ensure results by holding contractors accountable to the software sprint (iteration)/release schedule and by being involved in the Agile process.

Through highly disciplined time-boxed sprints (iterations), Agile forces agencies to manage risk by ensuring progress is continually monitored in real time, including with the direct involvement of end-users.

To ensure results, the Government must ensure that the “definition of done” is clear, comprehensive, and objective. This definition is established post-award at the beginning of each sprint. The contractor is considered to be “done” if working software has been produced that meets a set of criteria that the Government will use to evaluate a software demonstration (e.g., packaged, documented, tested, independently verified, and releasable). “Done” should ensure that the capacity of the application is such that all users are able to access and use it. To be considered successful, a contractor must also meet cost and schedule goals.

Agile practices bring to light projects likely to fail much sooner than traditional practices. Because of the small initial scale, this practice reduces the scope of failure and allows projects to take corrective action quickly, irrespective of whether the contract is fixed-price or cost-based. As a result, although a contractor will only be held to best efforts if a cost-based contract type is used, the Government’s exposure to major cost overruns will be significantly limited.

In fact, the Government’s exposure to risk under other than a fixed-price (e.g., T&M, Labor-Hour) contract is arguably less than that under a fixed-price contract that follows the traditional methodology. History shows that the likelihood of significant problems being surfaced late in a traditional project is substantial – by some accounts at least 70 percent21 – along with the likelihood that the Government will end up sharing, or paying for, the cost of the overrun because the initial specifications turn out to be faulty or otherwise inconsistent with what customers determine they ultimately need.


When using a FP contract, how could the line items be structured?

In a FP contract, the line items may be structured by iterations (sprint cycles) with the unit of measure being the iteration. The Government may also use optional line items to account for additional work if needed.

For this sample line item, iterations are listed as “sprints,” but would be modified based on the type of Agile process being used. These scenarios are used to illustrate examples of how a contract may be structured, not dictate how it should be structured.

Scenario 1: New Task Order or New Contract- no known quantity of velocity/capacity of iterations is available. This method works well where a known budget amount is set and the program office needs to determine how much work effort translates.**

Fixed Price Contract. Period of Performance: Base Period [insert date of award through a set date]

Item No. Supplies/Services Quantity Unit Unit Price Amount
0001 Baselining effort 100 day $ $

Upon completion of the 100 day timeframe, Government and contractor shall mutually agree upon the team’s capacity/velocity. Note: decision making under the contract is the purview of the Contracting Officer. The contractor cannot make a decision about the nature of the contract requirements as that would be an inherently governmental function.

Deliverable

  1. Implement proposed methodology (30 days)
  2. Operate team under proposed method through several iterations (60 days)
  3. Define and agree to mutually agreed sprint capacity (10 days)
Item No. Supplies/Services Quantity Unit Unit Price Amount
0002 Sprints TBD sprint $ NTE $500,000

Upon completion of line item 0001 – the final quantity of Sprints will be determined based on the agreed upon capacity and compared to the available budget remaining in order to determine how many Sprints could be awarded.

Scenario 2: Follow-on Effort or New Competition. This method works when the iteration has already been defined and agreed upon by the Government, whether this is through historical knowledge of a previous effort or through the solicitation requirements established in a competition.**

Period of Performance: Base Period = 12 months

Item No. Supplies/Services Quantity Unit Unit Price Amount
0001 Sprint 15 Sprint $ $

Each Sprint needs to be defined either by the Government or by the contractor in their proposal. The goal of each Sprint deliverable is to have working code that has undergone some process of testing and quality assurance. An example of a sprint deliverable could be spelled out as follows:

Sprint = Includes Analysis, design, development, testing, QA, documentation, and production of releasable code in a 3-week iteration. Estimation method uses Small, Medium, and Large scale for user stories (S, M, L being defined in solution).


Do incentives under FAR Part 16 work with contracts for Agile software development?

Yes, the Government is highly encouraged to use incentives in contracts for Agile software development, if appropriate, to motivate contractor performance.

FAR Part 16 describes different incentives that may be used in contracts to ensure the best results. Recently, Government agencies have had success with fixed-price incentive contracts (FAR 16.204, 16.403), fixed-price contracts with award fees (FAR 16.404), and performance incentives (FAR 16.402-2). See Appendix C: Sample Language for Government Contracts for Agile Software Development Services.

Examples of Performance Incentives


How does the Government ensure fair and reasonable prices when acquiring a process such as Agile software development?

The Government may determine whether prices are fair and reasonable in a contract utilizing an Agile software development methodology by requesting and evaluating pricing of the effort as a unit of measure that is equivalent to the proposed sprint/release cycle and demonstrating the correlation between the proposed technical solution in the PWS and the pricing.

COs must obtain the type and quantity of data necessary to establish a fair and reasonable price. Generally speaking, competition drives reasonable prices. The Government ensures fair and reasonable prices by looking at the prices per sprint (iteration) cycle, the team size, and if applicable, the labor category rates used to build the team – whether they are in line with other rates in this industry. Expected “through-put” (team size, skillset, velocity[22]) and determination of specific services all factor into the offeror’s price for an IT contract utilizing Agile processes. The Government can compare the proposed prices received in response to the solicitation (adequate price competition establishes a fair and reasonable price) to the historical prices paid by the Government or private sector for the same or similar Agile process, or compare proposed prices with prices obtained through market research.[23] See Appendix C: Sample Language for Government Contracts for Agile Software Development Services.

The objective of price analysis is to ensure that the contractor’s price is fair and reasonable and that the CO is responsible for evaluating the reasonableness of the offerors’ prices. The CO may request specific information from vendors to establish fair and reasonable prices by having a solicitation that states in order to determine best value, pricing for the effort is required to be on a unit of measure that is equivalent to the proposed sprint (iteration)/release cycle. The price quote should provide backup documentation to support the pricing proposed and should demonstrate the correlation between the proposed technical solution in the PWS and the pricing submitted.

The solicitation may provide the timeframe in which the Government desires the minimum viable product and should solicit the offerors’ proposed number of sprints (iterations) or releases and proposed pricing for each sprint (iteration).[24] It may also define how development work sizing is to be conducted based on the size of the team proposed. Alternatively, the solicitation may fix the number of sprints and the timing for each sprint and have the offeror submit proposed pricing for each sprint.

When preparing an Independent Government Cost Estimate (IGCE), the agency should estimate the projected costs a contractor will incur in the effort, which includes direct costs (e.g., labor, supplies, equipment, transportation) and indirect costs (e.g., labor overhead, material overhead, general and administrative expenses, profit, or fee). To determine the estimates, the agency may use market surveys to compare prices offered within the local area for similar Agile efforts, and also look at the agency’s previous buys of comparable Agile software development contracts if they exist.

When developing the IGCE, one strategy is to take the user stories at high levels (epics) and estimate the amount of effort involved in each epic on a coarse abstract scale (e.g., small, medium, large). Then assign a dollar value range to each value on the scale, and tally up the final figures to provide an upper and lower bound for the total estimated cost. Another strategy is for the Government to fix the sprint timeframes and dictate how many sprints it will be purchasing. In this case, the IGCE would be the estimated cost/sprint times the number of sprints.


Next Page “Competition”