Why We Don't Do Fixed-Price Software Projects (And Neither Should You)

A few years ago, I took on a freelance project to implement an Internet Explorer component in C++. I was billing a healthy hourly rate on other projects at the time, but this particular client insisted on a fixed price. In a bout of temporary insanity, I made an exception and accepted the pre-agreed budget. After all, the project was fairly intriguing and the requirements were straightforward. What could possibly go wrong?

Several weeks later I had already logged hours totaling three times my original estimate. I was working 12-hour days trying to get the project off my plate so I could finally move on to a job that would provide me with actual income. I asked the client to increase the budget or at least reduce the original scope to something more reasonable. In the fine collaborative spirit of a true partnership, he waved (metaphorically) in the direction of the contract and told me (in so many words) to shut up and get back to work.

That was the last fixed-price project I ever accepted, a policy we've continued at Salsita. Clients frequently ask us why we won't commit to a fixed budget for their job. We're experienced professionals, aren't we? Can't we come up with an accurate estimate?

Here's what I tell them.

Every developer knows that accurate software estimation is not possible even when perfect information is available about project requirements (i.e. practically never). As Michael Wolfe brilliantly illustrates in his classic Quora answer, the high-level view of an incipient project ignores the fine-grained details and unexpected obstacles that determine the actual workload. This is precisely why agile methodologies have taken over the software development world so comprehensively: they bake the impossibility of producing accurate a priori estimates right into the model.

Outsourcing software projects to a service company adds a dose of money to the already fraught issue of software estimation, yielding an explosive cocktail. Suddenly the client isn't just worried about when they will get their software, they also want to know how hard it is going to hit their pocketbook.

There are two ways around this, and they both suck:

1. Do the same kind of project over and over again. If the requirements are close enough to work you've done before then you can be confident about your estimate, especially if you have reusable code lying around.

• Pad your estimate liberally so you'll be covered when the project inevitably takes longer than expected.

The first option favors repetitive, unrewarding and low-margin projects. The second is clearly not in the interest of the client, assuming we allocate enough buffer to account for the actual variability of the project schedule. According to the Cone of Uncertainty described in Steve McConnell's classic Software Estimation: Demystifying the Black Art, estimates can vary by a factor of 4 up or down at project start. We'd have to really pad the fixed price to cover all eventualities, which means the client would almost certainly end up overpaying.

Working for a fixed price also creates perverse incentives for the development team. It is perfectly rational in these circumstances to cut corners to get the software done as quickly as possible. You know, the opposite of what you should actually be doing.

Another major issue is that every spec change turns into a business negotiation, as the two parties battle over whether adding infinite scrolling to the widget management screen is a feature (which would expand the scope and therefore the budget) or a bug to be fixed (which is the developer's own damn fault, of course). The resulting adversarial dynamic is inefficient, with much energy burnt haggling over the project spec that would be better invested in writing code.

On the flip side, a fixed budget is attractive to clients for the same reason that managers like deadlines (but with the explosive addition of money mentioned above). It's about control. A client might be concerned about a service company dragging its heels in order to maximize billings on a project, just as any pointy-haired type might worry about how hard their developers are working without a Damoclean deadline hanging over their heads.

In both cases this is a lazy approach to management that leads to frustration, bitterness and bad code. What it doesn't lead to is more timely delivery, since the fact of slapping a deadline or budget on something doesn't magically mean it's realistic.

A much better approach is to internalize and embrace the reality of software development. One of the best ideas promoted by agile methodologies is that of regular and frequent communication between project stakeholders. If a client isn't able or willing to assess the progress being made over the course of the project, taking appropriate action if the contractor isn't getting the job done, then they shouldn't be in the software game to begin with.

As software providers, it is our responsibility to provide clients with a realistic estimate of a project's scope and budget (i.e. probably much higher than they think) and to explain why close collaboration and communication are much better vectors of project success than an arbitrary fixed price. As for clients: caveat emptor. If the fixed price a service company offers for a complex, poorly specified project seems to good to be true, it probably is.