Fixed Price Contracts in Agile Projects

Again and again I am asked (or feel compelled) to explain why agile software development fits nicely with fixed price contracts. Some people still think that a fixed price contract requires a detailed up-front requirements study, to accurately calculate the costs of the project. But that's not correct.

These are the arguments that I use frequently:

1. In all the so-called "requirement studies" that I have seen (for fixed price contracts), I have never come across a proper description of the final product, as it has been delivered to the customer. It appears that, in all our software projects, customers change their minds, and we are simply expected to accommodate for that. Therefore, a detailed requirements study is not the best way to calculate the costs for a fixed price project. It turns out that the details are simply never correct! In fact, it might be easier to base our fixed price calculations on the weather, as it is more predictable than our customers.
2. A fixed price contract requires only that the scope of the project is constrained so that we are confident enough to carry the risks. You don't need to know the exact length of the third field on the fifth input form on page 283 to do proper risk management. A simple set of high-level requirements is usually sufficient to reduce risks to a manageable degree. We just let the customer know that we're estimating two days for that ordinary customer contact form that he so desperately wants in his product. (And this form is highly unlikely to cost us more than four days.) That's all you need to know when signing the contract.
3. For fixed price projects it is essential that you are able to constrain the scope (even more than with time-and-material contracts). With changing requirements (which are a fact of life) it is best not to have detailed requirements. From a psychological viewpoint, it is much easier to throw away old requirements, replacing them with new ones, if you haven't wasted time on any details. Oh, you also want a FAQ list in the product? Fine, but we won't have time for the contact form then. Is that ok with you? We couldn't care less, because we had only spent 30 seconds on the requirements anyway…
4. If you agree on a fixed price contract using high-level requirements (like user stories), you retain the option of negotiating the details of the requirements. If the details of user story A cost you more time to implement than you had expected, then you have the option of implementing user story B later in the project using the simplest interpretation possible. Yes sir, we understand that you had expected the contact form to include support for smileys, attachments and spell-checking. But the import of your product catalog over a 14.4k modem from the backside of the moon cost us more effort than we had expected. (And we're still delivering according to the minimal specifications.)

For time-and-material contracts, working with user stories, or some other form of high-level requirements, is the smart thing to do. Many agile experts have already explained this a zillion times. But for fixed-price contracts, fixing the scope using high-level requirements, and not detailed requirements, seems even more crucial to me. The need to throw away old requirements is much higher, and detailed requirements do not enable you to re-negotiate the work that is involved to implement them.

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
A Theory of Everything for Software Development
Professionalism = Knowledge First, Experience Last
Architects vs. Agilists (1 – 1)