Dont have a scope? Need a fixed bid?

Here's another section from my presentation at CFUnited:

//

This segues into the question of what to do when the customer needs an "estimate" or requires a "fixed bid"? I think I just answered that one - you write a thorough spec doc, break it down into tasks and provide an estimate based on your anticipated schedule. Submitting a bid without a spec doc in hand is, frankly, suicide. If you submit a bid at, let's imagine, $1000 for a project, and oh-my-gosh, you actually come in at that budget, you weren't right. You were wrong in your estimate since you didn't know what you were estimating and just happened to come in at the same amount for the development. It's like back in math class when you had to write out your solution on tests because the teacher wanted to know you did the problem right, not just guessed at the answer. It's the process of breaking out a spec doc into tasks that lets you come close in your estimates. (Estimating is another gigantic topic in its own right, and I'm not going to get into it here.)

There is one little snafu with this plan. Many customers want that fixed bid before they're willing to drop any coin. They won't accept a ballpark range/time-and-materials budget for the development of the spec doc without any idea how much their total outlay is going to be, including the coding. This is a total catch-22. I can't commit to a project cost until I know what the scope is, but the customer won't let me determine the scope until I commit to a project cost.

Sometimes in the "real world", I can't always convince a client that they need blueprints and house plans plans before they can get a bid on the construction of a house. What do I do in this situation? Quite simply, I must determine the scope before committing to a price. Anything else is a guess. Here are some tricks I try:

1. Walk away. There are other customers out there, waiting for me, who know that demanding a fixed price without a spec doc is foolish. These are the customers who have been burned in the past.
2. Hire a fancy salesman in a $1000 suit to smooth-talk the customer into waiting for a fixed bid until a "discovery phase" is complete. Don't call it a "spec doc", call it "discovery". Maybe I eat the time spent on the spec doc and jack up the prices on the coding phase to cover your losses.
3. Offer the customer a fixed bid based on just the spec doc process. When you're building a house, you first pay just the architect, right? When your car is broken, you take it to the mechanic for a flat-rate diagnostic fee, right? In order to swing this solution, I craft the customer relationship into an ongoing series of agreements to get from one phase to the next. At the end of every phase, the customer can pull the plug and still have value with the deliverables provided by the previous stage. After all, the final software is just the deliverable from the coding phase, right?
4. Insist that we never work on fixed bids. This is more of a meta-solution. Since we never entertain the idea of working on a fixed bid, we never have to figure out what to do about a customer who needs one.
5. Employ the used-car-salesman approach. When a customer walks onto the lot, a good used-car salesman will sell them something, anything. He takes their money and makes sure they drive off the lot. If the customer must have a total price firmly fixed before we do any work, then I can certainly guarantee that something will be delivered within that budget. What that something is, is the scope of the project, something no one yet knows, but we get to determine it by working until the customer's budget is dried up. This is roughly what the iterative development folks do, but can create big troubles because of unrealistic customer expectations.
6. Educate the customer by encouraging them to perform their own initial discovery phase. I show them a template of a previously-completed Statement of Work or Preliminary Project Plan and have them create the first draft of it. Some customers are capable of producing this kind of document. We may end up giving away some services assisting them with creating the document, but when I have it in hand, I have a good idea of how much work it will take to perform the spec doc process.

In all these cases, what I'm trying to do is nail down the scope of the application. By determining the scope, I answering many of the big, hard questions and provide a direction and some details to the project. This is the only way to produce a fixed bid without wildly guessing.