blogs.conchango.com

Responding to an RFI?  Here''s some simple advice
I've been on both sides of the fence here.  For many years, I worked as a consultant to a product or services vendor. often involved in presales work.  Time after time, RFIs would land on my desk, with a woefully short amount of time provided to complete a credible response.  I did as best I could with the technical part of the responses, and was always given praise for the quality of the input that I gave.  However, in a recent exercise, assisting in the assessment of technical responses to an RFI for an integration hub for one of our clients, I have had the opportunity to see things from the customer perspective.  Here are some observations that I believe will help anyone responding to an RFI or RFP.  Believe me, it makes a difference:

1. Remember, yours is not the only response your prospective client is reading.  Chances are yours is just one of a number of responses they must wade through (and usually in addition to their day job!).
2. No matter how much you may like to (or how much it suits you to) believe it, it is rarely the case that the author of the RFI is an idiot.  They may be less technical than you; you may not see eye-to-eye, but it is likely they know far more about their particular problem, requirements and needs than you do.
3. The questions you are being asked have been sweated over, reviewed, modified, checked, and checked again.  They are frequently designed to address multiple issues and often the key point is buried amongst more obvious statements.
4. Most organisations will use some sort of grading process which is designed to at least show they are taking an objective viewpoint on all the vendors chosen.  This will invariably reduce into a spreadsheet within which each vendor will be graded, and some sort of (un)scientific weighting applied.
   
5. Most of the individuals inside these organisations will not be objective; they will have prejudices, personal agendas, misconceptions and previous experiences that will colour their judgement.

From these observations flow the following recommendations

1. Answer ALL the questions.  Don't be big-headed; yours is not the only response your prospective client is reading.  As stated in 4. above, you'll probably be scored against a grid, and if you don't answer a question, there will be two probable consequences: (i) you'll piss them off because you're making life harder than it needs to be, & (ii) you'll get a 0 rating.  The zero rating may have caveats around it, but at some later stage there'll be no time to read them, and an overall score will be taken.
2. Answer all questions appropriately.  If you spend two hours answering a question about scalability and then find that the 'same thing' is being asked in the section on performance, then you may be right: the author may be a muppet, who doesn't know the difference.  Alternatively, you may have misunderstood what the questioner is really asking.  If in doubt, at least answer the subsequent question as if you hadn't answered the first.  the fresh words and reorientation of your brain may yield new insight.  Common mistakes: (i) Simply referring to the previous answer - which is tantamount to stating that the client is stupid and has asked two questions when one would have done; (ii) Cutting and pasting the previous answer - this isn't kindergarten and clients generally spot that kind of thing.
3. Keep it concise.  Believe me: your potential client will skim anything that extends beyond that which they can see on one screen.  You must be able to provide the key information that proves you are the answer to their needs within that space.  Any further information will be gratefully received, and forgotten/ignored, in appendices and supporting documentation.
4. Conversely, never refer to supporting documentation instead of stating the answer in the direct response.  If it's explained elegantly and clearly in the supporting document, then that's great: include the document with the rest of your response and mention that the reader might like to refer to it for more detailed information, but do your client the service of at least summarising the salient points in the main, customer-tailored, response.
5. Provide concrete, factual answers wherever possible.  Don't replace facts with woolly nonsense if you aren't sure.  Anything contentious will be taken up and thrashed out at a shortlisting stage should you get there, so don't hold back on information you believe to be true, but can't quite substantiate.
6. Don't bother with lots of supporting information that isn't specifically requested.  Given the rest of what I've said in this post, I expect you understand why, but I will labour the point by providing another perspective: I have never read a response that has been exemplary; there is always a bunch of stuff that has been missed out, or not explained properly, or no proof-read, etc. etc. etc.  If you then go on to write a load of stuff  because you think the reader should know it, even though you haven't bothered to do the bits they have asked for properly, then, well, it pisses them off.  Concentrate on the stuff you've been asked to provide.  Trust me: you won't have enough time to do that justice, let alone put the frills on.

I would urge all suppliers to take careful note of these points.  Admittedly, this is only my perspective, based on being a technical reviewer on a number of occasions, but I know for a fact that it's hard enough to win over a client and you must do as best you can to make it easy for your potential client to choose you.  On the positive side, there is almost always all to play for.  I've seen may examples where the outsider storms it - but usually only because they've played a blinder in the selection process.  Conversely, never consider it a done deal.  I hate the look on a vendor's face when it finally sinks in that the sale they've told their directors is a done deal, evaporates in front of their eyes.