The other reason why Fixed Rate Contracts suck

You have a prospective client and you are discussing the project. Often the client would like you to quote a fixed fee for the work, so maybe you think thats ok and come up with some number by using a fancy estimation tool or tossing chicken bones. It really doesn’t much matter, something is likely to go wrong anyways.

The most obvious problem is the one everyone talks about. The client wants more work for the same price or changes his mind and wants you to just do the changes for free. Sure you could go down the route of detailed specs and change requests etc. but that’s means you are spending your time pushing paper instead of making code work, which is hopefully why you are in this game in the first place. So often we absorb a little bit (which hopefully we accounted for in the quote) and it only becomes a real problem when you have a particularly difficult client. There’s alot more to say about this and I don’t pretend to be an expert on the situation or how to resolve it.

I’d like to talk about the other side of this problem.

You agree to do a job for a fixed fee. While doing the work, you realize that there is much more you could do to make the product better than was originally envisioned by you or the client. In a good situation you can talk it over with the client and they will to pay more for this additional value. However, often the client’s budget is limited and they are unable to pay for this work that you know “ought to be” done. I run into this relatively often my desire to build something great runs up against my desire to not work for free. Usually the two desires compromise but that never leads to a feeling of satisfaction.

The simple answer is to just avoid doing fixed fee work. Is there a better answer?

One Reply to “The other reason why Fixed Rate Contracts suck”

  1. Fixed fee is fine if you have a good working relationship. But unless your client trusts you absolutely, you can’t completely avoid the pushing paper problem. How are you going to respond to a “why did we do it this way?” or a “what happened to feature X that I wanted” question?

    With a high level of trust, it you might be able to answer “don’t you remember, we agreed X” and be done with it. But you’ll be in a lot better shape if you have a waterfall model spec and change orders, or a batch of use cases at various levels of completion sitting in your backlog along with burndown reports instead of having to rely on email or even worse partially remembered whiteboard drawings.

    The key is avoiding a mismatch between the amount of paper pushing and the potential need for documentation and that is going to vary by client and by project. Which does kind of suck.

    There is a lot of thinking about how to do this stuff in scrum land:

    I’m very fond of the “money for nothing and change for free” model (look at page 28 here) :

    and an article about the whys (you’ll need to register)

Leave a Reply

Your email address will not be published. Required fields are marked *