With the three pillars underpinning the fixed price billing in the software development field established, let me switch to explaining why none of them is quite viable. Predictability
While it sounds so enticing to make a contract where all things are set and all actions are predefined, such an agreement is just not what you want when it comes to a software project.
I've partly covered it in this article
, but, since so many mistakes tend to be done in this very area, I'd like to pay some extra attention to the issue.
If it's not a project under $10k and you're not a seasoned project manager plus a senior developer plus a veteran business analyst, no matter how great your planning is, things gonna change. The features you're planned for will become irrelevant, the market you've focused on will command for something you didn't predict and so on and so forth.
And when things start to change, you don't want your team indifferently quoting the terms of the contract and asking why would they care about the unexpected twists in your business path.
But that's precisely what is going to happen if the price is fixed. Or, you will need to pay extras along with signing a new contract every time you approach the team, which not only sort of ruins the idea of a fixed price project, but is also counterproductive and pretty awful for your personal experience.
As a result, all the project risk management efforts make no sense at all. Yes, in the end, you've got what you wanted and paid fair money for that, but what's the point if that is not what your business needs at that moment? Liabilities
As I've already said… in a pub, that Friday night… software development is not about you dropping orders and the team following them aka soldiers. It's a constant flow of information in both directions, translating into the more or less equal shares of responsibilities and the distribution of potential risks. It's crucial for the overall project success that this balance is kept.
By trying to hang too much on the team, you're effectively ruining the synergy and no matter how that feels at the beginning, you'll be the only one regretting that in the end.
The negative effect of the team being overloaded with liabilities shows as a seamless shift of their focus, from "How do we make a great thing" to "How do we fulfill the contract and make that dumbass happy". And, judging from my own experience, I can say that it has a huge negative impact on the project.
Developers lose interest in what they are doing and the management starts to think about how to cut corners and stay inside the box that you've constructed. The worst thing though is that the fixed-price agreement prioritizes time over quality for the contractees — the less time they spend on your project, the more they can spend working on something different, making more money.
No need to explain that not a single piece of great software has ever been done that way. Cost cutting
Buy nice or buy twice. This saying describes the difference between the T&M and the fixed price almost perfectly.
To start off, the people you're going to hire are not dumb. Well, if they are dumb, you won't succeed anyway, no matter what sort of agreement connects the two of your parties. The not-dumb project team tends to understand the risks associated with the fixed price contract and take steps to offset them. And there won't be any ingenious moves, there will be a straightforward overpricing, up to 200%.
Moreover, if they are experienced (again, nothing gonna work if they aren't), they will expect the typical "fixed price behavior" from your side, meaning that none of your sort-of-fair money saving tricks will have any significant effect.
In the end, the team tends to do more than expected because there is always something that they missed at the planning stage. However, while the amount of extra work is normally rated at 20–50%, the amount of extra money that you've already paid can be 80–100% and more.
Feel the difference?