Jeremy Miller is talking about agile adoption, and he raised the issue of fixed bids in agile projects. Fixed money, fixed time, fixed scope projects are the ones that are easiest for the bean counters to work with. You pay X$ you wait Y months, you get Z features. If the other side fails to hold their end of the bargain, you start reducing X$.

Easiest for bean counters doesn't mean that it is easiest for the software project itself. The problem is that not RFP that I have seen is close to detailing all that the customer wants, and the behind the scene political struggles to get more & more on the RFP by other departments (hi, it comes out of the ZYX department budget, it us get our critical feature U there) can produce direct contradiction in the underlying requirements.

Here are a couple recollections from some recent projects:

• In one memorable occasion, I was working on a project for 6 months before the customer discovered that there was a critical failure in the spec and that we need to do some heavy duty stuff modifications for all the entities in the system. (Where heavy duty means that code couldn't compile for days on end, when we basically restructured the core entity model for the new requirements).
• In a more recent project, not only no one could explain a requirement, but no one could ever recall who requested this feature, and why.

To summarize, the fixed time, scope & money projects aren't really working. A favorite question by agile speaker is "who have been on a project whose requirements has not changed?".

I was, but it was a two days one :-)

So, since change is a given, how can you approach such a project, if you want to work in an agile fashion. As Udi points out, there is a tendency in the industry to bid at cost or at a loss, and generate revenue by change requests. Leaving aside the issue of the morality of this behavior, that behavior is also leading to another of the common questions by agile speakers: "how many of you delivered a system according to what the customer asked, but not what he wanted?"

Since the customers has already got that this was the Operation Method de-jour, that has gotten problematic. The RFP is as broad as possible, and the spec is as narrow as possible, and the spec is not something that is meant to provide a guide for the developers, but rather a tool that is meant to be used when arguing whatever a particular request is within the project scope or not.

So far, this has nothing to do with Agile or no Agile. The entire premise of waterfall methodology is capturing requirement in concrete so they wouldn't change, except that never works.

Now, I am purposefully avoiding this part of the business, so take this with a ton of salt. There are several options that can be used, where the best is complete acceptance of agile from the customer, so they pay you per iteration. A more reasonable alternative is to work at the fixed money / time frame, which is far easier for the customer to arrange in the corporate environment, but be flexible on the delivered features. This tend to push unnecessary features to the end of the project, where they are already seen as unnecessary.

But, the question goes, how do you win such a project?

Well, you need to estimate the work from the RFP as you would usually do, and submit a proposal based on that estimate. It is likely that you will have a higher proposal than the low-balling guys, and if the only thing on the table was money, that would be a problem. The key as far as I see it is to find, not the bean counter that is signing the check, and usually couldn't care less about the project itself, but the real customer, the one that wants the actual work done.

If you can get there, you can explain why your proposal is higher (quality, no back stabbing), why you would end up with a better result (early deliverables, immediate feedback, etc) and how it directly benefits the customer to go with this approach. Some people would rather not take a risk, which is sad, but understandable, but those who would want to get things done can usually get the point across.

Then you do things as usual, letting the customer dictate what will get implemented and when. At the end of the project, it is the customer that decided what would be there or not, so not only are they in a better position to understand what is going on, they are directly responsible for that. From my experience, they usually get "change request" (features not on the RFP) for "free" (trading with unnecessary features, basically, and within reason, of course) during this time, since they get to decide what we will work upon.

The bas part is that sometimes political issues can force you to do stupid things (implement something you know no one will use), but hey, that is what the customer wants.

Assuming that in the end of a project, someone find a missing feature and demands it, the customer can explain why this feature was cut, and what the client got as a result of this. I find this much better than trying to explain to a client why authenticating against their mainframe is not a good idea, and authenticating against active directory is probably a better approach.

The counter argument is what happen if you customer has a party on change request all the way to the end of the project, at which point they turn around and demands everything that they ignored so far. That is the point when you politely points out to the responsible party, and let it go. Producing a bill for those change requests is also an effective measure to stop that kind of an approach.

But frankly, most people wouldn't behave like that, and it is fairly clear what type of person you are dealing with fairly early in the project. Then you plan accordingly. Frankly, I wouldn't want to work for a dishonest customer.

We used this approach in my last project, to great success. This also has to do with a really good customer (I really want more of those), but the basic principle is sound. And we are going to use it more in future projects.