18   Fixed Prices Are Broken Promises

“We have to deliver a fixed bid for this project. We don’t have all the details yet but need to put a bid in. I need an estimate for the whole team by Monday, and we’ll have to deliver the whole project by the end of the year.”

Fixed-price contracts present a problem to an agile team. We’ve been talking all along about working in a continuous, iterative, and incremental fashion, and now someone comes along and wants to know ahead of time how long it will take and how much it will cost.

From the customer’s point of view, this is all perfectly reasonable. They work like this to get buildings built, parking lots paved, and so on. Why can’t software be more like an established industry—say, building construction?

Maybe it’s actually a lot like building construction—real building construction, not our image of building construction. According to a 1998 study in the United Kingdom, some 30% of the cost of construction projects came from rework due to errors.^[19] This wasn’t because of changes in requirements, or changes in the laws of physics, but simple errors. Cutting a beam too short. Making the hole for the window too large. Simple, familiar mistakes.

A software project is subject to all the simple mistakes plus fundamental changes to the requirements (no, not a shed, I want a skyscraper!), huge variability in individual and team performance (20X or more, depending on whose studies you believe), and of course, the constant inrush of new technology (from now on, the nails are circular).

Given the inherent volatility and irreproducibility of software projects, coming up with a fixed price ahead of time pretty much guarantees a broken promise in the works. What alternatives do we have? Can we get better at estimation or maybe negotiate a different sort of a deal?

Depending on your environment, you may be able to do either. If you absolutely, positively have to provide a price up front (for a government contract, say), then you may want to investigate some heavy-duty estimation techniques such as COCOMO or Function Point analysis. But these aren’t particularly agile techniques, and they don’t come for free. If the project is substantially similar to other projects you’ve done with this same team, you’re certainly in better shape: developing a simple website for one customer will be pretty much the same as the next.

But many projects aren’t like that. Most projects involve business applications that vary tremendously from one client to the next. The projects of discovery and invention need to be treated much more collaboratively. Perhaps you can offer a slightly different arrangement. Try proposing the following steps:

1. Offer to build an initial, small, useful portion of the system (in the construction analogy, perhaps just the garage). Pick a small enough set of features such that this first delivery should take no more than six to eight weeks. Explain that not all the features will make it in but that enough will be delivered so that the users could actually be productive.

2. At the end of that first iteration, the client has two choices: they can agree to continue to the next iteration, with the next set of features; or, they can cancel your contract, pay you only for the few weeks worth of work you’ve done, and either throw it away or get some other group to take it and run with it.

3. If they go ahead, you’re in a better position to forecast what you can get done during the next iteration. At the end of the next iteration, the client still has those same two choices: stop now, or go on to the next.

The advantage to the client is that the project doesn’t “go dark.” They get to see progress (or lack of it) early on. They are always in control and can pull the plug at any time, with no contractual penalty. They are in control of what features go in first and exactly how much money they are spending. Overall, the client is facing much less risk.

And you’re doing iterative and incremental development.

Estimate based on real work. Let the team actually work on the current project, with the current client, to get realistic estimates. Give the client control over their features and budget.

What It Feels Like

Your estimates will change throughout the project—they aren’t fixed. But you’ll feel increasingly confident that you can forecast the amount accomplished with each iteration better and better. Your estimates improve over time.

Keeping Your Balance

• If you aren’t comfortable with the answer, see if you can change the question.

• If you are developing in a plan-based, nonagile environment, then you might want to consider either a plan-based, nonagile development methodology or a different environment.

• If you refuse to give any estimation before finishing a first iteration, you may lose the contract to someone else who gives an estimate, however unrealistic their promise may be.

• Being agile doesn’t mean “Just start coding, and we’ll eventually know when we’re done.” You still need to give a ballpark estimate, with an explanation of how you arrived at it and the margin of error given your current knowledge and assumptions.

• If you’re in a position where none of this is an option and you simple have to work to a fixed price, you need to develop really good estimation skills.

• You might also consider a fixed price per iteration set in the contract while leaving the number of iterations loose, perhaps determined by ongoing work orders (a.k.a. “Statement of Work”).