Software contracts that define all software requirements up-front make your project half-way to failure. The software company will try to do exactly what is in it, and the client will try to believe that none of those requirements will change. And at certain part of the project both will realize they were wrong.
Let’s face it. Software requirements always change. But it doesn’t mean that people got they wrong, it means that after seeing a piece of working software people learn more about it and they will always have a lot of new ideas to improve it.
Let’s see how could we change this situation:
Don’t define requirements in the contract. Well, this sounds obvious, but the problem is that people most of the time confuse software scope with project scope. The project must define clear vision of the goals to achieve, but should let the software change during this period to get to these goals faster.
Define an initial cost and time . Once you have no requirements in your contract, people can argue that you can’t define the project cost and time. That’s wrong too. Even with requirements in your contract, project cost and time are just estimates. So, to create those estimates you can think about requirements (the MoSCoW or the Joelonsoftware technique should help), and you can even keep these written items as initial ideas, but they really should not be written in the contract.
Build the software in short cycles where working software has to be produced . And define that requirements can be changed and the development velocity can be evaluated between those cycles. This way it’s possible to guarantee that changes will not scare the development team and the client will be able to check the team productivity. By the way, that’s other myth about scope-flexible contracts, that people will work less if they don’t have the requirements defined up-front. But this way of thinking ignores the fact that the software company should have interest in get the software done as fast as possible. After all, it’s a way to impress the client and get more contracts.
(Bonus) Create a much smaller contract first . If the contractor could not be convinced that this type of contract is better, propose a smaller one (one month, for example). If after this contract he’s still not convinced, everybody will be able to evaluate the risks and try to come up with another idea.
See, all those items are not too complicated. And if you ever experienced the stress that a traditional software contract can cause, you should really think about adopting a more flexible one.