[consulting] Responding to RFPs

[Ryan Cross]

>
> 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.

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.

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