[consulting] Responding to RFPs

[George D. DeMet]

Ryan Cross 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.
>
> 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.
Picking up on this point, regardless of how well-written an RFP is or 
not, I find it's almost always useful to have at least one phone 
conversation with a prospective client before choosing whether or not to 
respond.  Many times, you can get a lot more context about a project 
from a single 15-minute phone call than you can from even the most 
detailed and well-written RFP. 

Some of our most successful projects have actually been ones that had 
really badly-written RFPs; in these cases, the client understood that 
they had a problem that needed a technology solution, but needed help 
articulating that problem as part of the solutioning process.   We've 
also seen occasions when an RFP will call for a specific technology 
solution that's not actually the best solution for the client's business 
problem; in most cases, that's because they either don't know that 
there's a better option out there, or they think the solution they've 
proposed does something that it doesn't. That's why it's very important 
to listen to your clients and fully understand what it is that they need 
*before* starting production; not only does this make your life easier, 
but your clients will also appreciate it as well.

-- 
George D. DeMet
Palantir.net
2211 North Elston Suite 202
Chicago IL 60614
p 773.645.4100 x306
f 773.645.4105 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/consulting/attachments/20100201/0ac669a9/attachment.html