(And btw, building software is nothing like building a house.)
Well, building houses (buildings, bridges, power stations, stadiums...) is usually fixed price, waterfall at that (the blueprint is prepared before construction starts, etc).
Of course, the clients can change the projects, that's what addendums to contracts are for. Here you define what changes and how the fixed price changes.
Among other things, it is great anti-slacker motivator. With time&material, the construction company could take whatever time they feel like. With FP, they are encouraged not to, because it goes on their tab.
Maintenance of buildings/whatever structures is on the ofter hand often done as a T&M (it is slightly more complicated, as there are a certain baseline services with fixed monthly fee and everything above that is T&M).
Keep in mind that there's nothing stopping you from giving them an estimate! But you need to make it clear that most project scope changes come from client requests.
My co-founder spoke about this extensively at a conference several years back. It might be the best 15 minutes of your week:
http://www.youtube.com/watch?v=lIQIZ0NIkxk&hd=1
I am glad that fixed-price works for some, but I have a pretty hard line view on this: I think you're crazy. With a fixed price, either the client is paying too much or the developer isn't paid enough (and the work suffers due to decreased morale).
Every developer has a sad story about a client from hell and a fixed price engagement that crawled out of Scope Creep Alley. Yet, I'll bet that you've never heard anyone complaining about how they have to keep charging hourly to make pedantic changes.
As for the claim that hourly projects reward you for being a slower developer:
- there's nothing wrong with being a slow developer, assuming you're slow for good reasons like careful design and thoughtful testing
- this slur only really applies to time and materials developers that aren't busy! a good developer is likely busy, which means there's more work in the can and no reason to drag your heels in a dishonest way
Finally, the best ideas for a project come while you're working on it. How do you change course on a fixed-price budget? Are you going to stop to renegotiate a contract?
Sorry if I seem "passionate" about this. Building Unspace over the past six years into a happy place to work that only does T&M was a direct response to the ten previous years of fixed price hell. If this post saves one person from doing fixed price bids, my work here is done.
If you've used Pivotal Tracker, you'll understand my model: I commit to doing, say, 5 or 15 points of features in an iteration, for a fixed price. If the client wants to adjust the feature set, that's great! If I misjudge an estimate, and spend an extra day on something, the client doesn't pay extra. But if I have an extremely productive week, I earn a bit more. In the end, it balances out.
Usually around week 2, there's a brief moment of awkwardness where the client realizes that scope creep costs money.[1] But I help them cut a few marginal features, and we're ready to proceed. And from then on, the client is thinking about trade-offs, ROI, and priorities. And that's an excellent basis for a successful, long-term relationship.
I'm happy that you've found a model which works for your and your clients. Contracting should not be a miserable or adversarial process.
[1] Scope creep always costs money. It's better to make this visible to the client, even at the cost of some initial awkwardness. The usual alternative is to surprise the client later, when the bills come due. I've seen contractors do that, and I dislike it.
In an early stage project that's often budget constrained, and where the entrepreneur often isn't 100% sure what needs to be built, a fixed price agreement would waste a bunch of their money - either by forcing them to finish something that wasn't right for their market or by spending precious time and cash to renegotiate.
Have you ever heard of any significant projects executed in this manner?
1. Break the project down into small, easily-estimated features, and estimate the time required for each. Most estimates should be a day or two.
2. Allow the customer to select those features which have the best return on investment.
3. Strongly encourage the customer to budget an extra 25% to 50% for unanticipated features. There will always be a few!
4. Allow the customer to add new features, or to cancel features you haven't started.
5. Work with high-quality clients who know enough about their business to make intelligent decisions. Then, focus hard on helping them earn money. This removes a lot of stress from the relationship.
This approach only works if you take pride in your work, if you know how to estimate, and if you don't mind occasionally spending an extra day or two on a feature that proved trickier than expected.
Fixed-price projects have two great advantages: They encourage clients to think about which features will earn them the most money, and they reward programmers for good time management. Hourly projects reward you for being a slower developer, and where's the fun in that?
