Get certified - Transform your world of work today


Why Fixed Bids Are Bad for Clients

24 September 2007

Andy Brandt
Code Sprinters

My outsourced software development company is based totally on the agile approach. We work in Scrum and have come to regard it as a natural approach to managing requirements, releases, and changes in a project. However, most prospects and clients we talk to are not as familiar with agile development. And almost all of them ask for a fixed bid on any project they want to build. They collect the bids, choose the best contender (usually taking the lowest bid), order the project, and then go away for the duration of the contract, hoping to get a working system in the end. More times than not, what they end up with is a half-finished system not fit for release. They then have to start over, this time stressing that they want an accurate price.

We don't work like that. We believe that fixed bids are a bad idea when it comes to software. First of all, you'll never get an "accurate price." Developing software, especially new systems built to individual needs, is a creative, inventive process. It is not possible to accurately say how long developing “Feature A” might take. It is possible to make a prediction, an estimate, but it's just that—an estimate. This is especially true when you consider the amount of information about each feature that is typically available at the project start.

Every software developer knows they can't accurately predict how long a particular feature will take, so they guess. There’s nothing wrong with that. The problem starts when this guess is presented as solid reality, which is exactly what happens in a typical bidding process. Since each company knows there is a risk in their estimates, they compensate for it by overestimating. Industry standard for security margin on estimates is somewhere around 25 percent, which shows how inaccurate they typically are. In any case, what you get as a bid is in actuality a guess, bloated by some margin so that the developer feels safe they won't lose money if things go wrong.

Let's say someone tells you a project will cost $25,000. We all know that in the end it might cost $24,998 or $25,231 but it won't cost exactly $25,000. In fact it's more likely that it will cost either $20,000 or $30,000. In the first case, you lose $5,000 in money or features that might have been developed. In the second case, you’ll receive an inferior project. Why? Because if the project is over budget but a contract is on a fixed price, every sane company will do all they can to limit their losses. In other words, they’ll finish the product as quickly as possible—just kick it out the door, the sooner the better. In software, kicking it out the door usually involves developing poor, undocumented code, solving problems via quick hacks rather than elegant solutions, and reducing testing to the absolute minimum. To further reduce costs, the company may replace senior developers with interns, working overtime. If, heaven forbid, not only the price but also the deadline was fixed and penalties apply, the software company has an even bigger incentive to lower the quality to limit losses. That’s one reason so many IT projects (be it software development or deployment) end up disappointing clients or failing altogether.

Another reason fixed bids are bad for clients is because the bidding process by its very nature requires the scope to be fixed as well. That means clients have to provide all the features they might ever want from the development team upfront, before any development starts. Many clients start by writing a list of everything they want from the envisioned software system. There is nothing wrong with writing that list; it is a very helpful effort. What is bad is fixing it, making it carved in the contractual stone. Why? Because you write this document thinking that if you forget to put something there you will never get it. Result: you end up putting many things there which are not needed, the “nice-to-haves.” Worse, you won't put there many things that will be needed only because you haven't thought of them yet. And you haven't thought of them yet because those ideas will occur to you only after you will start using the software, even in an early version. In other words, writing a fixed scope document and then freezing it by making it a part of a contract means trading many useful but yet unknown features for many nice-to-haves or things that no one will use.

Agile companies do think long-term planning is a good thing, but we don't sell the illusion that a plan is anything more than it is. At my company, we fix quality and release dates (every iteration, usually two weeks) and we fix the price of each iteration before we start that iteration. We don't fix scope and we don't fix the total price for the project. If a client has a great new idea two months into the project, that's fine; we'll just implement it. If by fourth month a client decides that what has been developed is enough - that's fine too; a client can end the engagement at any time. Agile companies offer flexibility that traditional development based around static documents can't match. Most offer services at a set, negotiated price. We'll build as much as possible at the best quality for the amount a client is willing to spend on the project.

One last thought: with an agile team you'll never be left with a heap of code that can't be used for anything except showing it around in hope someone will finish it. Why? Because at the end of each iteration you get a new, complete product release that is 100 percent tested and 100 percent functional. It might not contain all of the features you ultimately desire. In fact, the first release (two weeks after the project starts) probably won’t do much at all. But those features that have been finished to date are indeed done—fully working, fully usable. From the very beginning, you have a working software system that is upgraded every two weeks with new features. You're never held hostage by the development team: you own the code and you have something that is useful. The best part is that you decide which features are most important *now* and should be delivered in the next iteration. Flexibility, customer involvement, and working software. Now there’s a recipe for success.

Thanks to Paul Klipp whose podcasts on selling agile software development remain a source of inspiration. Many ideas for presenting the merits of the agile approach used in this article are based on those podcasts and discussions during our meetings with Paul.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.8 (5 ratings)


Chris Spagnuolo, CSM, 9/24/2007 9:31:11 PM
Thanks Andy. This is an excellent article. We work with fixed-price, deliverables-based contracts on a regular basis and find it very challenging to produce quality software under those circumstances. It would be great if we can all begin to help our clients understand the incredible value and the inherent quality that a more agile approach to project management and software development can provide to them.
Paul Ellarby, CSM,CSPO, 9/25/2007 3:44:01 PM
In my old company, we worked like this all the time - a high-level estimate
(often drive by the customers budget) for the entire project, followed by a
quite accurate estimate for the next phase. Inevitably, we were very close to
being right for the next phase (iteration / sprint), but off by a lot on the
high level estimate. The reason for this is obvious - the client did not know
what they wanted until they saw what we could deliver, at which time their
"requirements" became obsolete, to be replaced by real needs - which we typically
included in the next phase.

I am educating the organization I am with now to adopt a similar approach, but "old
habits die hard" as they say, but I think I am making some progress. Of course, our
clients still ask for fixed bid projects, but I am happy pushing-back on them.
Andy Murthar, CSM, 9/26/2007 8:40:31 AM
Truly inspiring ! oh to be involved
Ben Scheirman, CSM, 10/18/2007 10:33:33 AM
I totally agree with you on this. Venkat Subramaniam says "fixed prices are broken promises" and I have to agree with him.

I'd be interested in seeing how you convey this to clients, who are just looking to take the lower bid. Ultimately a lean approach might yield cheaper results, because the client can eliminate nice-to-haves and focus on what's critical, but likely will be a bit more costly to the client.

How do you send the message of delivering business value and quality software to warrant a different approach and higher rate?
Andy Brandt, CSM,CSPO, 10/23/2007 7:40:19 AM
Actually, it is indeed not easy to convey that message to clients, especially because when comparing offerings (and, yes, bids) they compare intangibles. They compare one promise that "everything will be included for $x" against our promise that "we'll do as much high quality features as you can afford". Our position is weaker, since our promise is no match to "everything" (which gets filled in client's mind by everything they imagine - and that's exactly what traditional salesmen want). So we are pioneers here.

What we do is saying: try us, go for one-two sprints with us, let's start with something simple (a feature, that is useful but doable in such time) and then you'll decide whether you want to continue with us or not. We also (for now) do some initial work like backlog creation free, so that clients could get the first taste of the agile approach before actually committing to anything.
Richard Whitten, CSM, 3/7/2008 5:27:37 PM
A great benefit of this approach is lower risk to the client and developer. Since the contract can be terminated at any time (e.g. at the end of a sprint), the client is at most out the cost of the last sprint. The same is true for the developer.
David Harris, CSM, 3/19/2008 1:18:30 AM
The concept of being able to 'terminate' agile-based contracts at any time with a minimum of impact 'conceptually' marries nicely to some of the underlying PRINCE2 project management framework concepts of 'work packages' and 'governance checkpoints' intended to facilitate the cessation of project work early if necessary. This is a potential point of interest to raise when trying to introduce agile methods, particularly to government clients who may be enamoured of the PRINCE2 approach.
Paul Klipp, CSM, 5/18/2008 6:34:05 AM
Thanks for the plug. I have to get podcasting again. That was fun, but a lot of work. I make the same explanation to a prospect live in my fourth podcast. Generally I find that reasonable people who have been burned on software projects before find themselves agreeing with me and most of them turn in to happy Lunar Logic Polska clients.
Paul Klipp, CSM, 5/18/2008 6:37:42 AM
Andy - I agree that our argument seems weaker, but few people who contact us are buying software for the first time. You can easily play on their discontent and show them how their past stress was tied directly to the contract terms. For the buyer, the major stresses are: they don't know what's going on during development, they are caught by surprise by mistakes and delays, the PM pushes back on what seem like reasonable requests until it feels like a fight to get the product they want, and the final product becomes an implementation and maintenance nightmare. They'll nod their head as you sympathize with their past pains and while they're nodding, you can easily demonstrate why it's really the fault of their bidding process.
Petter Thor, CSM, 8/19/2008 9:47:03 AM
Thanks for a good article Andy on how the mechanism behind a contract works. In my company we struggle all the time with one problem concerning contracts,scrum and estimations. The business often works like this, our customer has got an idea of what they want to have and put this down in a short paper. We get the chance to get the business. Before we can get the business however the customer business manager wants an estimation of the work otherwise he do not have a clue of what his new idea will cost and if it is worth it. He must go to his board to get funding to develop a product with supports feature a..b..b...n. We do an estimation that is as you also write a guess. We eventually gets the business but when we get closer to release the cost often is higher that the guess done a couple of month ago and then the customer business manager who has been away during development(Product owner from the customer works with us during development) have a problem within his organization. How to handle this, should we not give any estimation to start with ? I understand that our customer have a problem going to the board saying " I want to company A to develop a product but I do not know the cost and how many features we will get". I my word of business Scrum is well known to the technical customer project manager but when it comes to the business managers who is control of the money it is more difficult.
Wolfgang Wiedenroth, CSM,CSPO, 12/23/2010 4:25:05 AM
Very nice article! Exactly what I was looking for to answer the question why fixed prices are bad. Thanks for sharing
Ashish Parmar, CSM, 1/30/2011 9:40:59 AM
Excellent article , Andy. Educating the customer, who is used to the world of Waterfall, is one of the biggest impediments that I see. But conveying the benefits, especially monetary, of lean approach and Agile definitely should help in a buy-in.
Roshan Venugopal, CSM, 1/31/2011 10:48:03 PM
Great article. I don't agree on quality issues because I am doing a huge fixed bid and I am ensuring great quality because I need more projects from the customer but I do agree on the challenges and issues particularly with the generic requirements.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up