<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ryan Cross wrote:
<blockquote
cite="mid:4e983be01002010934n7548ff00m847d59f6f0bc5a33@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!---->
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.</pre>
</blockquote>
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. <br>
<br>
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.<br>
<pre class="moz-signature" cols="72">--
George D. DeMet
Palantir.net
2211 North Elston Suite 202
Chicago IL 60614
p 773.645.4100 x306
f 773.645.4105 </pre>
</body>
</html>