Agile Contracts

Agile contracts, what are they? There is a kind of bad old tradition that software development contracts should be one of the following types:

Fixed-price OR
Time & matertials (T&M or TM)

Fixed Price is Bad

There is no doubt in my mind that fixed price contracts are a bad idea. It is not at all uncommon for contractors to offer good competitive “fixed” prices and then charge through the nose for the inevitable change requests. A typical project has 2-15 % requirement changes / month. In a 15 month project that corresponds to a total change rate of 1,4-8,1 times the original requirements baseline. In other words, if you pay a fixed price for a fixed baseline and extra for changes you might end up paying 8 times more for the changes than your original “fixed” price!

Information Assymetry

But isn’t fixed price supposed to distribute the risks away from the customer towards the supplier? Perhaps, but have you ever heard of an insurance that you can buy without paying a premium? Researchers advise us that a software contractor should only accept fixed price contracts when there is a “significant information assymetry“. In other words, if your software contractor is ready to work with you on a fixed price basis they are either stupid or there is something they know that you do not.

Being a Good Customer

So what does it take to be a good customer? First of all you should avoid the most common pitfalls for IT purchasers. Then, you should consider what makes a relation great in business. Would you agree that “mutual benefit” (aka win-win) is the secret to lasting successful relationships? In that case you should consider what makes it possible for your supplier to be profitable. And the secret answer is: time and materials contracts.

Distribution of Risk

But doesn’t that mean that the customer carries all the risk? Won’t the supplier see me as a gold mine and staff the project with inexperienced people? Indeed, the conventional wisdom is that fixed price contracts place the risk firmly with the supplier and that time and materials contracts places it with the customer. I have demonstrated above that fixed price contracts will not guarantee success. It is left as an excercise to the reader to show that time and materials contracts will not guarantee failure. 🙂

Conclusion: Future of Agile Contracts

What, then is the future of agile contracts and indeed of all software development contracts? First of all, remember that agile software development practices do quite a good job of driving down the risk in and of themselves. What should we do with the remaining risk? We should distribute it fairly between the contract participants and provide good management and governance of the relationship based on the risks assumed by each party.