
Time & Materials vs. Fixed Price - ntalbott
http://terralien.com/blog/articles/2011/01/06/time-materials-vs-fixed-price
======
peteforde
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:

[http://www.youtube.com/watch?v=lIQIZ0NIkxk&hd=1](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.

~~~
ekidd
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.

------
auxbuss
A fixed price contract requires that you define "done". Without defining done,
you are exposed to large, possibly limitless, risk.

(And btw, building software is nothing like building a house.)

~~~
vetinari
(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).

~~~
DougWebb
I agree completely that building software is nothing like building a house. I
blogged about this a few months ago:
[http://webbindustries.com/archives/2010/10/index.html#e2010-...](http://webbindustries.com/archives/2010/10/index.html#e2010-10-19T10_29_00.txt)

~~~
ntalbott
[Disclaimer: I run Terralien, and the author of the article works for me.]

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.

------
ekidd
I've done a lot of fixed-price projects, and rarely had trouble making
everybody happy. Here's how:

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?

------
malvosenior
Million Dollar Consulting ([http://www.amazon.com/Million-Dollar-Consulting-
Updated-Prof...](http://www.amazon.com/Million-Dollar-Consulting-Updated-
Professionals/dp/0070696284)) suggests charging on value created (vs cost
based pricing or time and materials). This may be a share of future revenue
based on your work or a fancy sales pitch charging x% of the millions of
dollars your work will save the client.

~~~
peteforde
Interesting, but I am deeply skeptical.

Have you ever heard of any significant projects executed in this manner?

------
rbxbx
A lot of great discussion around this very subject from not terribly long ago:
<http://news.ycombinator.com/item?id=1880096>

