I was drawn into a conversation about fixed priced contracts on LinkedIn. Since many people might not be monitoring the associated group on LinkedIn I thought it might be useful for me to cross post here. The content of my LinkedIn post (slightly edited) follows:
I think the picture sums up the way you would go about dealing with a fixed price or fixed cost project. Given fixed price the variables you can change are time and scope. Time and cost are intimately related (i.e. given a fixed duration iteration with a fixed team size you have a relatively fixed cost), with time and scope being closely but not intimately related (one team or group of teams could be much more productive than another of equal size) so in agile the real ‘lever’ is to manage (but not control) scope.
The weakness of this single diagram is that it doesn’t reflect a couple of the benefits that might manifest themselves if you apply proper prioritization to the process. Most agile approaches would recommend that scope be ordered based on some constraints, perhaps the most important of which would be the business value realized by the scope. Assuming that we work on the most valuable things first, and assuming that we follow the agile values of delivering working software on a frequent, recurring basis, a few things might happen.
1) We might discover the value we anticipated is less than the actual market interest, i.e. the product is very well received (and profitable) and that we now have a revenue stream that could support ongoing development even without consuming all of the originally planned budget. In this case ‘fixed price’ may become moot since the product has a revenue stream that can support ongoing development.
2) We might discover the value we anticipated isn’t validated through our early releases giving us the opportunity to change direction earlier or even consider a fast failure, limiting the budget waste that would incur if we completed the entire scope before delivering it.
3) Through prioritization and validation of our assumptions of value we can make a decision about whether or not we should proceed on a iteration by iteration basis. If at any point we find the return on investment for an iteration would be less than the cost we could end the project. This could actually result in a project that is delivered earlier and at less cost but with less scope than may have initially been envisioned and budgeted since the return on investment for the scope isn’t justified.
Prioritizing (to the point of ordering) with strong focus on business value has a much greater impact on the potential return for the project than simply collecting a large scope of requirements (some of which might be of limited business value; but if we’re going to apply for budget then we better include everything we can think of since we’re only likely to get budget approval once) and determining a price for the delivery of those features.
So, the image depicts how agilists might think about fixed price in very high-level terms, but much more is to be gained if we understand how to more effectively leverage the concepts of prioritization (by business value) with frequent delivery that validates our assumptions. Given the effective use of these tools which become available to us through an agile approach to project (or product) delivery the concept of fixed price has the potential to become much less relevant to how we might structure even fixed price contracts.
