Case: Developing a Fixed-Price Bid

The poster child for estimation is the development of a bid in response to a request for proposals (RFP), so let’s look at this situation first. A potential customer waves a requirements document and says, “I want to buy one of these; what will you charge me for it?” A bunch of other people go off between a rock and a hard place to figure out an answer to this question. Each wants to charge as much as the customer is willing to pay, but just low enough that the customer chooses their proposal instead of a competitor’s. Most importantly, they don’t want to bid so low that they can’t make a profit. That’s the estimation part of this game in a nutshell, though there’s certainly more to this game than estimation.

Big Contract Bids

We’re most familiar with this game in the government-contracting space. It’s an attempt to keep costs low while maintaining some impartiality in the process. The intentions are good but the results are mixed.

From the point of view of the bidding contractor, it’s a big expensive undertaking to respond to such an RFP. This fact, of course, tends to limit the competition to only corporations who have made a business of responding to such RFPs. It’s a hard business to break into. The resulting estimate is expected to be both accurate and precise, at a high confidence level. The time and cost for the proposed work is expected to be of the form “no more than” the estimated amount, while still maintaining precision.

To create such an estimate, you need a lot of expertise in the type of system being developed and good data on what it took in the past. If you need this, you probably have a whole department experienced in developing such estimates. Learn from them. Software Estimation: Demystifying the Black Art [McC06] by Steve McConnell and Estimating Software Costs [Jon07] by Capers Jones describe such procedures in detail.

The process recommended in these books is to have a large dataset available for comparison to the requirements specified in the RFP. If you don’t have that data, start collecting it. And there are programs for modeling the costs based on recorded data from other companies in other situations. We’ll later look in more detail at estimating by comparison (see Chapter 2, ​Comparison-Based Estimation​) and using mathematical models (see Chapter 5, ​Model-Based Estimation​). I suspect that there are other factors in addition to excellent estimation that are required to pull off a successful project under these condition.

Capers Jones, in particular, has a strong preference for automated model-based estimation performed by estimation tools such as the one he sells. We’ll take a look at some of the parameters of his model in Chapter 5, ​Model-Based Estimation​. Keep in mind that Jones is very concerned with large-scale government contracting and the possibilities of lawsuits arising out of contract disputes. His estimation model is calibrated for such situations. He intends to use estimates as protection in these situations, and therefore takes a conservative “kitchen sink” approach. If you can think of a potential cost, you better put it in the estimate. Capers Jones’ estimates include such things as administrative and management personnel and travel costs, which are not specifically called out in this book.

Note that these large-scale contracting situations involve a lot of handoffs and checkpoints between the two parties. As Troy Magennis points out, delays during development will quickly swamp the work itself in terms of time consumed. Therefore, experience with the client and understanding the likely delay durations may be more valuable than understanding the time required for the development work. This experience comes from working on similar large-scale contracts. If you’re planning to start your own large contracting corporation, I advise you to work for a successful one first, and take good notes on the experience.

Smaller Bids

For smaller bids, the power dynamic is often reversed from that of large bids. Usually the development company is offering their expertise at building a type of product for clients who want a customized version of that product. The development organization knows a lot more about what’s involved than does the customer.

What the development organization may still lack is knowledge about delays the customer may cause. The customer might be slow in collaborating, leaving the development organization waiting for information or decisions. Or the customer may have unusual circumstances that aren’t obvious. The customer might also be wanting things that are outside of the ordinary range of difficulty.

Note that the strength of the promise provided by the quote estimate is under the control of the development company rather than the customer. It’s prudent to make some provisions explicit.

• State what is considered usual and ordinary.

• State that delays caused by the customer are not in the estimate and will incur additional time and perhaps additional cost.

• Define allowances for things that may have a wide variability, such as aesthetic design. Specify the amount of work allotted for these things, and state that overages will be additional. There’s an example of this in ​Estimating an Online Storefront​.

You may not need to be so explicit with some customers, but you won’t know which ones until too late if the provisions are not in the contract or quote. For good customer relations, you should try to pin down the largest or scariest uncertainties as early as possible. And as soon as you discover something unforeseen, let the customer know.