Abstract – Agile and Fixed Price Contracts

Undoubtedly, there is tremendous interest in Agile Project Management today. A very common question that comes up at presentations on Agile is, “How do I use Agile with Fixed-Price (FFP) contracts?” Or, “Can Agile be used effectively with fixed price contracts?” At first glance, there does not seem to be a good fit between the fixed price world and Agile. In the fixed price world, it’s usually the case that the customer has a very clear understanding of the deliverables, and what they want created for the project. Therefore, the statement of work (SOW) should be very detailed and quite lengthy. The customer will be choosing between vendors’ solutions based on mostly on price, and past performance – (recommendations). On the other hand, Agile is most appropriate for projects where the customer really doesn’t know what they want going into the project, and we need to discover or explore their requirements through iterations and prototypes. The customer will want a new solution created for the project. As Ken Schwaber – (one of the original authors of the Agile Manifesto) – said, “Agile is about the art of the possible,” not “you give me what I paid for, when you said that you’d deliver it.”

If the customer only knows what they want at a very high level – (“business requirements” or “functional requirements”) – then the customer cannot expect the vendor to bid a fixed price for this work. How could they? How can the vendor be expected to predict or estimate the schedule and their costs when the requirements are so high level? Therefore, vendors traditionally do not want to make a fixed-price bid in this context, and if they have any leverage, they will want the contract to be a Cost-Reimbursable Contract type, or Time and Materials. (In both Cost-Reimbursable and Time & Materials contracts, the customer has most of the risk. If the initial estimates are off for the project, or there is any kind of cost overrun, they are picking up the majority of these costs in all of these types of contracts.)

So obviously, customers much prefer a Firm Fixed Price (FFP) contract model; often expect this, and when economic times are tough, they often have the leverage to demand this type of contract. Now, in the fixed price world, the vendor is taking all the risk. So, if you are a software company, do you agree? Is there any way to make this really work? Yes, actually, software and consulting companies are proceeding with providing bids even in this context. The paper explores several strategies that are being employed using Agile methodologies in the fixed-price world. Briefly, these include:

1) Simply bid a higher price, and protect yourself by building in extra reserve to protect against risk.

2) Secondly, use a hybrid approach: mix in a front-end detailed planning phase, so a portion of the high-level requirements can be defined in detail, and a fixed-price can be bid for this subset. Of course, the customer will need to be flexible, and agree to divide the project into segments with pricing determined for each segment or phase. At the end of each phase, a new set of requirements will be chosen and planned in detail for the next phase, and a fixed-price will be bid.

This approach does depart from the classic way of doing estimating in Agile. In Agile, the team does not plan in detail the architectural specifications of deliverables and work-packages, and use this to create a “bottom-up” estimate. Instead, relative estimates are made of the size of higher level “stories” and “features,” and as the team progresses in creating these stories or features, their “velocity” is measured, so forecasts can be made against this actual performance for the duration and cost of the sprint (or iteration).

3) A third approach is another variation on the second approach. Again, the customer agrees to divide the project into phases (or iterations) with separate pricing for each iteration, but we won’t do the detailed planning needed to decompose high-level requirements into architectural designs. The customer picks a subset – perhaps the top 10% or 15% -of their requirements for an initial prototype (or iteration). These requirements (or features) will also be their top priority requirements, and something the vendor estimates probably can be created in 2 to 4 weeks. The vendor knows how many resources are required for this first prototype – (perhaps 6 to 8 senior dedicated engineers), and how much time is estimated, so it will be simple to propose a price. The vendor may feel comfortable accepting the risk for a fixed price for this first iteration, but if not, they will need to protect themselves with extra reserve built into their bid. Improved estimates and pricing for later iterations can be created due to tracking the team’s velocity and performance in the first iteration.

4) Lastly, another idea is to build incentives into the contract: either use a “Fixed-Price Incentive Fee” (FPIF) contract type, (or even a “Cost Plus Incentive Fee” – (CPIF) contract type). These incentive-based contracts help ensure that both parties are accountable, and are sharing risk for the project. The vendor is rewarded for beating the estimated costs, and likewise, picks up a significant part of any cost overruns

So, these are just a few of the ways that people are using Agile methodologies with fixed-price contracts today. However, it’s clear that the real intent and spirit of Agile is to help the customer explore and discover a new solution when going into the project they only have a very high level idea of what they want. In this situation, the customer should not expect that the vendor can put together a clear precise estimate of time and cost for a solution that is largely undefined. So, by default in this scenario, a Cost Reimbursable contract, or Time and Materials contract type would be the best fit.
The full article is also included in this blog.

6 Responses to Abstract – Agile and Fixed Price Contracts

  1. I think agile and iterative approach can be used and is important in many levels. The phase of defining business needs is extremely important and should also be iterative. By requesting fixed scope / fixed price contract the customer is giving up the chance to be flexible and killing the spirit of agile. Of course you can and should do some iterations even under fixed scope contract. But the most valuable advantages of iterative approach have been lost with signing the fixed scope.

  2. “Many people belive that you can’t do a fixed price contract in an agile project. Since the whole point of an agile process is that you cannot predict the future, this isn’t an unreasonable supposition. However this doesn’t mean you can’t come up with a fixed price agile contract, what it means is that you can’t come up with a fixed price and fixed scope contract.

    • admin says:

      Yes, I agree. However, since with most Agile projects, the customer requirements are very high-level to begin with: (they will be discovered, explored and developed in iterations), if you are the software company developing the application under a fixed-price contract, you need to be very careful that some clear, quantified acceptance criteria are created for the high-level requirements, especially in the first iterations. Your fixed-price contract may resemble a time & materials contract with a cap, and some high-level functional requirements.

  3. admin says:

    Hi Ella, – thanks for your comment for the “Agile and Fixed Price Contracts” article. Not sure if I understood correctly: let me know what part of the article you were commenting on, or taking exception to. Thank you.

  4. admin says:

    Hi Eliot, – thanks for your comment for the “Agile and Fixed Price Contracts” article. Sorry for the late reply: (your comment was lost amidst all the spam comments I receive.) However, I’m not sure if I understood correctly: let me know what part of the article you were commenting on, or taking exception to. Also, I believe Time & Materials contracts are sometimes referred to as “Unit Price” contracts. (The vendor quotes a unit price for materials or labor, but is not quoting a fixed price for any deliverables.) I believe you’ve heard them called “fixed rate” which is a new one for me, but not unexpected. Thank you.

  5. admin says:

    Hi just checking to see if this comment was coming from a real person – (not a “bot) – and if you were referencing something in the article. Thanks.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>