[consulting] Responding to RFPs

[Katherine Lawrence]

I read a lot of RFPs. It gets to be a lot like the ancient parable about 
the blind men describing an elephant. The writer of the RFP has a 
picture in mind. How well have the words described the final 
realization? The first question is, "is this real, or is this a snipe hunt?"

Is the projected budgeted? If not, is RFP a ruse for a fact-gathering 
mission? "Get me three to five estimates, Higgins, so that we can decide 
whether we want to take this project in house." Or, "then we can tell 
our existing supplier that another firm has lower prices -- we'll ask 
the current firm to match the lower price." Or it may be the clients 
wants me to create a fleshed-out RFP that can be shopped. I have seen 
several RFPs where the client missed cutting another developers name 
out, so it was clear that they used the earlier RFP as a springboard to 
further their bidding process. Not a client I want to deal with.




Antonio P. P. Almeida wrote:
> 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
>
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>   

-- 

Katherine Lawrence, Chief Operating Officer
pingV, Inc.
4450 Arapahoe Ave., Ste. 100
Boulder, CO 80303


1.303.415.2559 phone
1.303.502.5222 fax
katherine at pingv.com