[consulting] Responding to RFPs

[Antonio P. P. Almeida]

On 1 Fev 2010 17h34 WET, drupal at ryancross.com wrote:

>>
>> I think you should reply to a RFP even when it is badly written,
>> with things like fuzzy specs or such. If you can grasp the main
>> idea behind the proposal and you can handle it, you should reply
>> IMHO. If poorly specified, just add a $ cushion to your budget
>> since you're going to have to help the client figure out what the
>> specs are, thus using your valuable billable time doing what should
>> have been their work.
>>
>> António,
>> --- appa
>
> Will have to respectfully (and heavily) disagree with you there. A
> badly written "RFP" is not an RFP, it is either more of a casual
> request or a client who doesn't know what they want. By not
> responding appropriately to each request, you waste everyone's time
> and usually get yourself in a bad position easily.

I'm talking about a RFP that not being completely specified to the
last detail has a clear idea about the outcome. I'm thinking about a
client that, for example, knows exactly what type of site he wants,
but hasn't figured out in full the image handling workflow, or is
uncertain about doing a phased deployment or a big bang. Not about a
client with an RFP along the lines of:

"I wanna have a new web site. How much it is?" 

> You should screen potential clients the same way you might screen a
> module or that a client would screen developers. Then either give
> some boiler plate response (or no response) to bad RFPs, or full
> proposals for ones with a good budget and well written, and
> something in between for the rest. For poor RFP's I also often
> suggest they pay me to do some project planning and develop a better
> RFP before asking for bids.

Yes I should have qualified my reply. I will reply to a RFP that being
clear has some "holes" in it, meaning that I'm aware that will have to
fill in some blanks, but nevertheless the project is interesting. Of
course I'll take that in consideration and include it in the price.

I'm arguing not so much against screening the RFPs/clients, but
against blindly following rules like "don't reply to RFPs not
completely specified". There's a need for a qualification: what's "not
completely specified"? It varies.

> Alternatively, you can structure your RFP more agile like and then
> charge based on T&M instead of flat-fee.

Yes. This can be a variation on the "$ cushion" I suggested.

--- appa