Why Fixed Bid Software Projects Are a Bad Idea

It’s springtime here in Seattle, and it hasn’t snowed for weeks. The sun is out and the days are getting warmer. Reminds me of one of my first jobs as a teenager: rototilling. What does that have to do with software development? Well, for me it illustrates why fixed bid projects are bad for everyone involved.

My rototilling billing policy was simple: $20 per hour. I would tackle your garden, lawn, whatever, and work on it until you were happy with the consistency of the soil. In some gardens, our Troy-Bilt would sink its tines deep on the very first run, engine roaring to compensate, and leave behind a strip of perfectly pulverized soil ready for planting. In other gardens, the soil would be hard, full of clay or even rocks, which would cause the poor machine to try to jump completely off the ground. Even after multiple passes, the soil was still clumpy and barely ready for planting. But it was hard to know which way it was going to go – I had to work on it first.

One time, a customer wanted his whole back yard tilled, and he insisted on a fixed price. Feeling pressured, I agreed to it. Hey, I was only 16. After I went over his whole rocky yard a couple of times, I figured I was done. He didn’t agree. He wanted me to go over the whole thing a few more times, which ended up taking way longer than I had anticipated. I left thinking I had been taken advantage of, and that I wouldn’t work for that customer again. The customer got a good deal that time, but it wasn’t a fair transaction, and eventually he would run out of people willing to work for him.

That story illustrates why fixed bids for software development are a bad idea. It’s very difficult to agree on what the software should actually do ahead of time. Sure, you can build design specs and features lists, but at the end the customer has to agree that the software is done. So, fixed bid agreements automatically put developers and customers in an adversarial relationship, one that won’t lead to a productive long-term relationship:

• The developer might overbid the job to cover the inevitable difficulties. It’s not unusual for the bid to be triple what the job might take.
• Perhaps even worse, the developer might underbid out of desperation to get the work. This will lead to big problems later.
• The customer will want to add changes and enhancements into the project.
• The developer will watch for change orders and try to limit the extra work, or at least charge extra for it.
• The customer will often argue with the change orders, saying they should have been included in the fixed bid.
• The customer will want “bugs” fixed at no charge, which implies that the software has to be completely tested before it is delivered. This is very difficult and costly.
• The customer and developer are on opposite sides, putting the whole relationship in jeopardy.

However, in an hourly agreement:

• The developer is an extension of the customer’s team.
• The customer is hiring expertise, not buying a product. This means that all reasonable work will be billed to the customer.
• The developer agrees to absorb time that isn’t effective.
• The customer controls costs by deciding what features are approved.
• The customer helps reduce costs by sharing in the testing responsibilities and reporting issues to the developer.
• If costs increase, lower priority features can be postponed to control the budget.
• The customer and developer are on the same side, so the relationship will last longer.

I’ve discussed this hourly approach with many J Street customers over the years, and it has served us well. We try our best to build a realistic estimate, but it’s just that – an estimate. It can change. Up or down. We’re very good at estimating when the scope of the project is perfectly understood and doesn’t increase. But that rarely happens. Many projects, especially complex ones, increase in scope, usually because the customer sees the possibilities and wants to add more features. But sometimes they just increase after we get started, because we discover that there is more to the customer’s requirements than we first thought, like discovering rocks in the ground while rototilling.

We once had a customer leave us after 8 years of ongoing application support, and switch to a fixed bid shop that offered a lower price for a system rewrite. The customer actually liked our work, but the temptation of the lower fixed bid won them over. We were sad to see them go, and we really wondered how the other company could possibly succeed with the bid they quoted. Two years later, when the “6-month project” still wasn’t done and the customer was no longer on speaking terms with the developer, they switched back to us. At an hourly rate.

We get calls all the time from customers who have “lost” their developer, often after a fixed bid relationship has gone sour. They found out the hard way – what seemed like a good deal at the time ended up costing them more and hurting the project.

So, the next time you’re looking for a developer to work on a project, think about what a fixed bid really means, and request an hourly agreement instead. I think you’ll find that it will cost you less and will increase the likelihood of success.

For a German version of this article, please see Olaf Nöhring’s interpretation.