If your goal is to iterate quickly to an MVP, T&M is a far more accurate and honest way to to scope a project budget.
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:
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.
I suspect we're communicating at cross-purposes here: If we stripped our two approaches of their labels, they'd look very much alike. You do time & materials; I do small-granularity fixed bids on individual features.
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.
This is exactly what I was going for in the post - that T&M gives the client and the developer a chance to team up in the most flexible way without lots of renegotiation.
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.
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.