Why Fixed Scope Contracts Might Freeze Your Innovation
And here is where fixed-scope/fixed-price projects run into trouble: to be able to estimate a price for a fixed scope, we are forced to assume certain specifications.
Nobody can estimate a precise budget using solely requirements (unless you imagine the most complicated solution possible for the problem and pad your budget for that). A problem, no matter how well you define it, does not have an associated effort: the cost of a ladder is very different from that of a jet-pack.
When you create a detailed list of specifications upfront –e.g. screen X should allow a user to input this value and then...–you are hiding under the rug the unavoidable reality that you do not know what is needed. You will not know until you do user research, build a prototype, test the prototype, iterate on the concept, give it to users, and see how it works in real life. Creating the illusion of certainty around the specifications is very dangerous.
As a customer, when you ask for a fixed-scope/fixed-price proposal, you are creating an epistemological conundrum; the provider is forced to choose between two options:
- To give you a proposal with an accurate lie –i.e. a fixed cost estimate for the detailed scope.
- To convince you of the truth of the uncertainty–the fact that you don’t know what exactly you will be building together.