Fixed Bid Contracts
I was listening to episode 57 of the Ruby Freelancers Show yesterday and, while some of the advice was fairly good, one of the panelists said something really counter-intuitive.
Eric Davis remarked that fixed vs. hourly is merely semantics since customers are essentially trying to map the project’s cost to their budget to ensure there is a cap on their spend.
If you really think about it, if you have a fixed bid contract that’s, say, 6 months and you’re bidding $60,000, you’re actually just saying ‘That’s still a variable rate’. The unit of time is 6 months and the cost per unit of time is $60,000.
The premise that the goal of a fixed bid is to map the project’s cost to a budget misses the primary reason for fixed bids: fixing the cost to a specific outcome.
In an hourly arrangement, when you use up the allotted hours, the project stops whether the code compiles or not. Same with a 6 month, $60,000 contract. After 6 months, we stop working. With an actual fixed bid contract, a customer will almost always want to specify something like: “I get X product with Y features completed and bug free for $10,000.”
The bottom line: fixed bid == fixed payment + fixed deliverable
As a manager, I can’t easily know how many hours each person on my team is working. This is actually good for me because it forces me to look at what they’ve done.