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.