<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=utf-8">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";
        color:black;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0cm;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";
        color:black;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;
        color:black;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page Section1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
        {page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=white lang=EN-GB link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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. <o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The other tactic as George suggests, is to go for T&amp;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.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>

<p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:
"Tahoma","sans-serif";color:windowtext'>From:</span></b><span lang=EN-US
style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> consulting-bounces@drupal.org
[mailto:consulting-bounces@drupal.org] <b>On Behalf Of </b>George D. DeMet<br>
<b>Sent:</b> 01 February 2010 19:07<br>
<b>To:</b> A list for Drupal consultants and Drupal service/hosting providers<br>
<b>Subject:</b> Re: [consulting] Responding to RFPs<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>Ryan Cross wrote: <o:p></o:p></p>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>I think you should reply to a RFP even when it is badly written, with<o:p></o:p></pre><pre>things like fuzzy specs or such. If you can grasp the main idea behind<o:p></o:p></pre><pre>the proposal and you can handle it, you should reply IMHO. If poorly<o:p></o:p></pre><pre>specified, just add a $ cushion to your budget since you're going to<o:p></o:p></pre><pre>have to help the client figure out what the specs are, thus using your<o:p></o:p></pre><pre>valuable billable time doing what should have been their work.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>António,<o:p></o:p></pre><pre>--- appa<o:p></o:p></pre><pre>    <o:p></o:p></pre></blockquote>

<pre><o:p>&nbsp;</o:p></pre><pre>Will have to respectfully (and heavily) disagree with you there. A<o:p></o:p></pre><pre>badly written &quot;RFP&quot; is not an RFP, it is either more of a casual<o:p></o:p></pre><pre>request or a client who doesn't know what they want. By not responding<o:p></o:p></pre><pre>appropriately to each request, you waste everyone's time and usually<o:p></o:p></pre><pre>get yourself in a bad position easily.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>You should screen potential clients the same way you might screen a<o:p></o:p></pre><pre>module or that a client would screen developers. Then either give some<o:p></o:p></pre><pre>boiler plate response (or no response) to bad RFPs, or full proposals<o:p></o:p></pre><pre>for ones with a good budget and well written, and something in between<o:p></o:p></pre><pre>for the rest. For poor RFP's I also often suggest they pay me to do<o:p></o:p></pre><pre>some project planning and develop a better RFP before asking for bids.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>Alternatively, you can structure your RFP more agile like and then<o:p></o:p></pre><pre>charge based on T&amp;M instead of flat-fee.<o:p></o:p></pre>

<p class=MsoNormal>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.&nbsp;
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.&nbsp; <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.&nbsp;&nbsp; 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>
<br>
<o:p></o:p></p>

<pre>-- <o:p></o:p></pre><pre>George D. DeMet<o:p></o:p></pre><pre>Palantir.net<o:p></o:p></pre><pre>2211 North Elston Suite 202<o:p></o:p></pre><pre>Chicago IL 60614<o:p></o:p></pre><pre>p 773.645.4100 x306<o:p></o:p></pre><pre>f 773.645.4105 <o:p></o:p></pre></div>

</body>

</html>