Price Evaluation
How to Ensure Fair & Reasonable Prices
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) 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.
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). 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 cush as labor, supplies, equipment, transportation and indirect costs such as 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 (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.