[consulting] Responding to RFPs

[Alastair Scarborough]

I would agree with George – this is a 2 way affair – I am invariably a buyer not a supplier of programming services and I find it sometimes very surprising how difficult it is to engage potential suppliers in a conversation about a project. As much as the programmer may wish to check out the buyer the opposite is also true – the value of a conversation should not be underestimated in assessing the quality of the supplier, portfolio details (I want to sure that the person really did do what they claim), whether they will be easy to work with etc – no different from a short job interview in reality. 

I am pushed for time, have the money, want a problem solved, often do not have the time to construct detailed specs etc – someone who can sensibly take that problem away from me in a manner that I trust, has a good chance of winning the business – one tactic someone used on me recently was to offer to work with me to develop the spec  - I originally had no intention of going down this route – he not only persuaded me to do it, I paid him to help me, tendered the thing with a very detailed spec and he now has a $90,000 contract on his hands.

My suggestion is, if you think the spec is fuzzy, get on the phone, assess the client and see how much effort they are prepared to put in to getting it sorted out.

The other tactic as George suggests, is to go for T&M on the fuzzy spec – I spend a lot of money doing things this way with a contractor I trust, but whose arm I had to twist hard to take the business. I am now their largest client by a long way and I often get something much better than I could have imagined.

 

From: consulting-bounces at drupal.org [mailto:consulting-bounces at drupal.org] On Behalf Of George D. DeMet
Sent: 01 February 2010 19:07
To: A list for Drupal consultants and Drupal service/hosting providers
Subject: Re: [consulting] Responding to RFPs

 

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/1b12511a/attachment-0001.html