It seems that fixed-time, fixed-price (FTFP) contracts have become something of an industry standard in software development, even though most other long-standing professional-service industries (lawyers, contractors, etc) typically won’t ever work under those terms.
I’m firmly against FTFP contracts for software development; I think they are bad for clients and bad for service-providers. Below I’ll tell you why.
FTFP contracts often feel dishonest
…because software is too dynamic to accurately estimate
The estimate is at the core of the FTFP contract, but software has too many unknowns to create accurate estimates. A list of some (but not all) of the unknowns around software development:
- scope of work
- quality of the final product
- maintenance requirements
- user-interface specifications
- changes in technology during the lifetime of the product
- etc, etc, etc
I once had a reputation for always having accurate estimates. How did I do it? I applied the Scotty method: take the amount of time I actually thought the project would take, and DOUBLE IT (sometimes triple, if the requirements are particularly nebulous).
I’m not alone in this. Software estimates are known to be notoriously inaccurate in the industry, and yet many still use them as a way to bill clients. It’s actually pretty dishonest, in my opinion, which is why I stopped doing it.
That’s not to say I don’t provide estimates, I do. I just explain to clients what the estimate actually means, rather than building in buffer via smoke-and-mirrors. Then I bill my actual time, and not my estimate.
FTFP contracts cause a ton of wasted work
…because the scope of work has to be decided up-front
Since you have to understand scope before you can create an estimate, you must lead clients through the requirements-gathering phase at the beginning of the project. This can be a long, drawn-out process; one that often exhausts both the client and the service-provider before any actual work has been done.
Anyone who has been through this knows it’s not fun for either side. You’ll also know that scope invariably changes – it’s near impossible to lock it down at the beginning of the project. So what happens? The inevitable change-of-scope dance.
The client wants something changed. Now both the client and service-provider have to decide: was this in the original scope of work? The client will say that it is (they don’t want to spend more money for something they thought was included). The service-provider will say it’s new scope (they don’t want to spend more time without being paid more). The true answer is that your scope of work was not defined accurately enough, and left some ambiguity.
What it boils down to is this: it takes effort to make changes to a FTFP contract. Mental effort, mostly, which is what most service-providers and clients use to make a living. Since this effort is not paid and not productive, this effort is WASTED. It also leaves lingering feelings of resentment instead of the camaraderie that you want on a team. Which brings me to the last point…
FTFP contracts are more adversarial and less fun
…because the contract incentivizes bad behaviour from both sides
The fact that the project is FTFP means that the client and service-provider have adversarial goals.
Client: I want to get the most work for my money
Service-provider: I want to get the most money for my work
Instead of working as a team toward a common goal (creating the best possible software product), the FTFP contract incentivizes the client to extend the scope as much as possible and incentivizes the service-provider to cut corners. This is absolutely the WORST way to set up a working relationship, it only causes frustration and resentment.
Is there a better way?
You bet your butt there is! Here’s how I do it: My agile process. Feel free to discuss how you manage your projects in the comments.