Winning a fixed-price RFP with an agile proposal
It came up in recent presentations I did around our engagement model and Agile Project Management offering: “How can one win a fixed-price fixed-scope fixed-time RFP?”
Ayende just posted an excellent article about this scenario, the common responses from agile speakers, his thoughts and a sensible approach to it. I quote:
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.
I believe this is leading in the right direction. There is no silver bullet and it always comes down to judgment calls, experience and context. There are however common themes in these RFPs:
- There are typically low-balling bidders involved employing less talented people (to make profit on margins) and change-control the living hell out of the client once the project is won
- The client is inexperienced in software development projects or has no real interest in the project deliverables (e.g. legislative requirement)
What hasn’t been mentioned yet is the fact that you as the vendor typically have a chance to ask questions and/or meet the prospective client face-to-face. That is your chance to get a feeling for a client’s motivation. If you get the feeling that there is no strong interest to make this project successful or no movement in terms of scope then my advice would be to stay away. Why would you engage in a project when there is little chance of success or the client just wants to screw you. If you are an agile organization chances are it won’t be aligned with your principles and values.
If you chose to pursue the RFP then you want to address not only the typical arguments for agile software development but also the cost transparency and value proposition. Point out that the cheapest response is not necessarily the response with the least costs for the project. Talk with them about the maintenance costs after go-live as well and that they proportionally increase when accepting a low-quality output (which is fine as long as it is a conscious decision).
Agile works because it is based on openness and trust. Agile works because it is based on common sense. Having a conversation with a client about the whole-of-life model of a project (including development and ongoing operational costs) can be powerful and create a sense of trust.
You typically can’t win a fixed-price fixed-scope fixed-time RFP on price unless you manage to include the hidden costs of non-agile vendors into the equation!
February 9th, 2008 at 4:38 pm
So from your last statement it sounds like you’re saying that Agile projects, by definition, will be more expensive than engaging with a non-agile vendor? The rationale being the quality will be better. I would hope that a well run project using Agile principles could still be cost competitive - if not, it makes it an even harder sell to our clients.
February 10th, 2008 at 10:58 pm
Not at all. My point is that fixed-priced projects tend to hide some costs early on - costs that the client is charged eventually. This could be through change requests or support and maintenance costs.
I agree, if a vendor knows what they’re doing then agile is most likely the more cost-efficient and higher-quality option.