Time & Materials vs. Fixed Price
terralien.com
terralien.com
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.
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.
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.
(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).
Building custom software is nothing like building a cookie-cutter tract house - completely agreed. In that case you're getting the same house as someone else, the builder has done it all before, and there are only a few options that you get to pick with the costs for those options known.
Building custom software is a lot like building a custom house, though - while there's an estimate going in, it tends to change a lot, and the final price varies widely depending on the buyer's choices during the project. Try being the general contractor on your own house construction project and you'll quickly discover costs are very variable regardless of the estimates up front.
There are a lot of stereotypes about how construction projects are "fixed bid" and "everything runs off of well-defined blueprints"; my Dad is an architect working on large healthcare projects, and I can tell you that those stereotypes are largely wrong. The projects do not go according to plan and even things "in the blueprint" change regularly mid-project.
I’ve been given some of those BDUF software projects in the past and they’re definitely painful - if not impossible to deliver. The only reasons they were successful were that the clients were enormous and ultimately paid for us to keep modifying spec documents as we went along.
We planned for that going in and the fixed price agreement was loaded up with all kinds of contingency (read, lots of extra cost to the client). In the end, it cost them more and delivered less. Sure, they got a great “as-built” plan showing exactly where things were different from the original blueprint - but having a great looking plan wasn’t the real goal. The sad part was that we could have done so much more feature development with that extra money.
Early stage entrepreneurs (which is who the post is about) are different. They don’t have the time or the money for that kind of inefficiency. They need an app that works. Now.
We do some up front work with them to lay out the flow of the major features. Then the client prioritizes them and we start with the most important thing first. We push new code very regularly and they tell us when they think it is working well enough for us to go to the next feature. Not sure that would be realistic in a fixed price model.
I like your final point in the BDUF post - that the development of the software is organic and ultimately determined by the process. Sounds like a great rationale for T&M vs. fixed price!
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?
Have you ever heard of any significant projects executed in this manner?