Fixed Bid Follies

A couple of months ago, my family was in the mood for a change. We had some extra money lying around after paying for our trip to Ireland (highly recommended, btw), so we decided to invest in some home improvements. As a general policy, I hire out any and all manual labor tasks associated with my home (landscaping, pool maintenance, etc… ). With my temper, it's just better that way. So, I contacted a local handyman company to come out and give me an estimate on the work that we wanted done.

The handyman listened to what I had to say, jotted down some notes, placed a phone call to his office, then gave me a fixed bid for the work (sans materials, of course). Well, that isn't entirely true. He gave me a minimum and maximum price, but the range was only $100, so for all intents and purposes, it was a fixed bid. I agreed to his price, and told him that I would call his office later to schedule a date for the work to be performed. I scheduled the work to be done a couple of weeks later.

A few days after that, my wife and I decided that we should just go ahead and buy a bigger house. We wanted more room, anyway, and we were feeling the effect of angryCoder's Law, which states that my house payment must double every 3 years (not to be confused with the similar consistency of Moore's Law). Now also seemed as good a time as any to make the investment, with interest rates as good as they are these days.

We tend to get attached to our houses, though, so we planned on turning our existing house into a rental property (yes, the angryCoder is also an angryLandlord of 3 previous homes). That meant that we still needed to make improvements to the house in order to get it ready for renters to move in. The problem was that the nature and extent of the work that we wanted done changed with our new circumstances.

When the handyman showed up, we told him about our change of plans (he kind of figured it our for himself, too, since the house was completely empty). That was when the trouble started. The notes that the handyman had written down concerning the job were not what we had discussed previously. One of the tasks that we wanted done was to paint the entire living area of the house, except for 1 bedroom (which had a wallpaper border in it). The handyman had written down “Paint living area + 1 bedroom”. The house has 4 bedrooms, so you can see that the slight variation in his notes had a staggering impact on the scope of the work. The notes were handwritten, so we had not noticed this detail when we signed off on the job order. The handyman had repeated our intentions back to us, though, so we were satisfied at the time that he knew what we wanted. To top it off, we were now removing some tasks and adding others.

By this time, we were pissed at the handyman for screwing up his notes and not remembering what we wanted, while the handyman was pissed at us for making changes to a fixed bid job. After brow-beating each other for what seemed like hours, we compromised on a modified price. Neither of us was happy with the outcome, but we both felt that we had come too far to let the deal fall apart.

Sound familiar? It should, if you've ever ventured into the world of fixed bid development contracts. It baffles me why some companies insist on fixed bid contracts. At first, they seem like a good idea, because they appear to be a way to constrain costs (making the budget look nice and orderly). Companies sell fixed bid contracts as a good idea to developers, because “if you finish ahead of schedule, then you get to keep the overage as extra profit.” Unfortunately, no matter how detailed the specifications are for an application, the nature of software development contains too many variants to venture a fixed bid. I have also never met a client that didn't change their mind about the specifications at least a few times during development.

When the client changes their mind and you're getting paid by the hour, it can be a bit frustrating, but you get over it pretty fast, because the client eats the cost of the change. When you're working on a fixed bid contract, though, it's the developer that eats the cost of the change. That gets downright infuriating.

Now, let me dispell some of the stupid responses from the cheap seats before they can gain any traction in the article feedback. Why don't I just tell the client that I can't change anything in the specs without charging them for it? That response sounds like a valid strategy… until you actually try it. Go ahead. Let me know how your client reacts when they're told that you're going to nickle and dime them for any changes that they want to make. The remainder of the contract will be as tense as George Bush during a game of SCRABBLE, and you sure as hell aren't going to get any future contracts out of the client.

Why don't I just build the cost of the client changing their mind into the bid? This response is appealing to the developer, but won't get you very far when you are competing with other developers and consulting companies to win a job. You'll almost always be underbid. Even if you aren't, you'd damn well better not exceed your bid if you built the fudge factor in already. This strategy also tends to result in you getting a shitstorm of change requests, because “hey, you knew we would be making some changes, so you already budgeted for it.” Yeah, fuck that.

Why don't I give the client a fixed bid with a percentage variance clause to account for specification or scope changes? The main problem with this strategy is that you'll find yourself constantly arguing with the client as to what constitutes a change in the specifications or scope (regardless of what the specifications say), thereby qualifying it for additional money under the variance clause. It's amazing how black and white becomes gray when it suits the client's purposes.

Although I have experienced it on occasion, I have rarely been involved in a fixed bid contract scenario when both sides of the transaction came away perfectly satisfied. It's only human nature for the client to feel that the developer didn't do enough, and the developer to feel that the client was too demanding given the supposed constraints of the fixed bid contract.

On the other hand, there is no ambiguity whatsoever when a project is paid on an hourly basis. Sure, a developer should still provide a work estimate to give the client a general idea of the amount of work that a project will take. An hour worked is an hour paid, though. The client can change directions to their heart's content, because they are fully aware of the consequences. Since the payment arrangements were made in advance, there are no hard feelings.

I don't mean to imply that hourly contracts don't have their own set of troubles. The biggest one that I have found is that the client (for good reason) pays much closer attention to the time that you as a developer bill, and the nature of the work that you are performing during that time. That is in stark contrast to the “black-box” nature that most fixed bid contracts take, in which the client doesn't give a damn how you get the job done… Just that you get it done for the agreed-upon price. Hourly contracts require a much higher level of time accountability (which I find to be an acceptable side-effect).

At this point, I have to admit to a bit of hypocrisy. I still do fixed bid contracts on occasion if a client insists, but with a few constraints. First, the contract cannot be for more than 200 hours of work (a little more than 1 man month). For such a small contract, it is relatively easy to keep the project reigned in and under control. It is also usually not enough time for the client to radically change their mind about the color of the room that they want painted (so to speak). Anything more than that, and the uncertainty factor is just too great.

The second factor that must be in place for me to extend a fixed bid for a project is that there be adequate written specifications and documentation. If I'm being paid by the hour, I'll start working based on a sketch on a napkin and a 10 minute phone call if the client is in a hurry (though I don't recommend such haste). For me to submit a fixed bid (even a short-term one), the client had better have all of their ducks in a row. Otherwise, no sale. I don't need the aggravation.

Third, I will not do a fixed bid development contract unless a down payment of at least 20% is involved, with multiple subsequent milestone payments (yeah, even on such a short contract). That way, I suffer minimum losses if the client becomes unreasonable and withholds payment, and I have to throw out the parachute. Milestone payments can significantly reduce the never… … … .ending… … … .contract.

As a general rule, I would say avoid fixed bid contracts at all costs. If you must do a fixed bid contract, keep it short and focused. If your negotiating skills are up to par, you should not have too much of a problem convincing your clients that fixed bid contracts only lead to unhappiness all around. Hourly contracts are the way to go, and often lead to “annuity clients” that come back to you month after month (as long as you do quality work and keep them happy).

Do you avoid fixed bid development contracts? What strategies have you employed to minimize fixed bid contract problems? Have any fixed bid contract horror stories to share? Talk back!