Here at RFPMonkey.com we routinely get inquiries from someone or some company who needs to write an RFP and doesn't have a clue where to start. A few days ago we got another, and it went like this... "We would like to put out an RFP for a roof on a school building and paving a parking lot. We do not know how to begin. Is your company able to do this?".
Not that we couldn't do that, but it's not our main line of work. We specialize in helping companies respond to RFPs, not write/issue them. Still, with many years of RFP experience, we do know a thing or two, not only about maintaining an RFP library and using it to respond, but also about what they should contain and how to create them. We offered some advice and received a very heartfelt Thank You. Among the feedback we got was that they "felt much better about the process and were no longer scared to start". The guidance was so well received that we thought it might help others too.
So if you have to create/issue an RFP and don't know where to start, here is some helpful advice...
First... Relax! RFPs don't have to be complex or done in any certain way. It's your contract, so you can describe it and RFP it however you want. Do keep in mind though the 2 primary goals for your RFP:
#1 Writing your RFP should clarify for yourself exactly what you want done, exactly what you would accept
if less than what you want), and exactly what you expect from vendors/contractors.
#2 Reading your RFP should clarify for your prospective vendors/contractors exactly what is expected of them, not only in completing the work, but also in responding to your RFP. Let them know how and when you expect them to participate in the RFP. Give them enough information to be interested in winning your business, and enough to be able to give you a reasonable pricing estimate.
The Devil is in the details, so let's shift from the general calming wisdom above to some very specific points to keep in mind.
Don't send your RFP to any vendors/contractors you already know you wouldn't do business with.
It's inconsiderate to consume so much time from responders who are pre-disqualified. Maybe your procurement
procedure requires you to have
"RFP responses from at least 4 vendors".
Still, if you don't plan to actually study the responses and seriously consider the merits of each and
every potential vendor, don't include them.
Include in your RFP a good overview of your project. Sure, vendors should do some research on you as they decide whether or not to respond, and how to respond, but to get the most well-targeted proposals back, you should make it easy for your RFP participants. Include a clear overview of what you are trying to accomplish. Describe what you are looking for, why you are looking for it, and what you have been doing in its absence up until now.
Include in your RFP some guidance on your RFP process and schedule. Develop a reasonable schedule for things like issuing the RFP to vendors, receiving/answering clarifying questions, RFP submission deadline, post-RFP demos or other due diligence, and award of business. Then include this reasonable schedule in the RFP, preferable as a table. Make it clear what needs to be done to participate, and by whom.
Don't make it difficult to respond for difficulty's sake. Responding to RFPs is inherently difficult, and quite time consuming. Potential vendors/partners will invest greatly in what they write for you. Don't create needless hoops that have to be jumped through. Don't flex your procurement muscle or test how high you can make a vendor jump. Remember, responding to your RFP is a decision, not a requirement. (We actually have a Go/NoGo tool than can help with the decision to respond or not. If interested, you can download the Go/NoGo Tool now.)
Include any/all questions you need to know the answers to to help you narrow the field. RFPs (or RFIs) with only 25 questions are common. 50-100 questions is probably more common. 200-300 is not at all surprising. More than that begins to feel challenging. The worst I ever had to respond to had 2300 questions! Just remember, it's your RFP - ask what you want (need) to.
Offer verbosity guidance. Generally, RFP responders will not be very brief. It's good practice to provide a concise answer AND back it up with more verbiage. Some writers take this concept way too far and droll on with countless platitudes, flowery adjectives, and multiple clauses in every part of each sentence. (That last sentence is a good example of what I'm talking about.) Some writers will stick to textual answers. Some will accompany nearly every response with a screen shot. Again, it's your RFP, and you are going to have to read their responses. So state whether or not you appreciate brevity or thorough coverage. Do you expect screen shots, or are you OK without them? You may even consider including a couple example answers to your own questions to illustrate what type of responses you are anticipating.
Remember that the RFP is not to 'pick' a vendor, but to narrow the field to the top 2 or 3. Then you will seek more info from them, perhaps in the way of references, site visits, product demonstrations, etc.
Don't represent as 'must-haves' anything that is actually a 'nice to have'. You don't want to discourage vendors/contractors who fall just a little short of your wish list, but who do good work and are reputable.
Group your questions into Categories (and possibly Sub-categories).
Issue your RFP in Word (or some other editable format). Often the best way to craft an RFP response document is to start with the RFP itself, inserting answers and other sections. Don't make it hard on vendors by giving them a PDF file. There is nothing to be gained by making them rewrite your document. There is nothing to be gained by making them copy/paste each and every question before they can answer it. Some may say "if we provide an editable document, some vendors may change our questions or requirement statements." Not likely. And if they do, you still have the power to disqualify them or evaluate their responses accordingly.
Remember that the RFP is NOT an award of business. And that a response is NOT a contract. It's all just mutual info sharing. This point should seem quite obvious to experienced RFP/proposal/Sales/contracts pros, but it's not so obvious on small companies or independents who find themselves required to draft an RFP for the first time. Seeing some contractual language in RFPs is not uncommon in the last few years, but I prefer that it be left out. The main thing it does is add expensive cycles into the response process. Later due diligence efforts can ferret out miscommunication (or fabrications), and eventual contracts can assign accountability.
Don't be surprised if some vendors insist on a Non-Disclosure Agreement prior to responding to your RFP. Not a big deal. Just read it and make sure it sounds reasonable, and doesn't include any obligations on your part. If they want an NDA, insist on a Mutual NDA (MNDA). The web is full of examples.
Proofread your RFP before you issue it to vendors. A sloppy RFP implies that you might just accept sloppy work from them. Also, if different people contribute to the RFP, try to limit duplicate questions. At the very least, this should also limit the number of times you have to read something like "see prior response".
In the end, your RFP should be a valuable document for both you and your potential partner. Use the requirement to write it as an opportunity to document your needs and exhibit professionalism and serious intent.
You may want to download and examine a sample RFP template that RFPMonkey.com has created for the RFP solution space. It contains examples of project overview, category hierarchy, RFP schedule, and participation requirements. You can download the RFPMonkey.com RFP Tempmlate now.
Our primary business is the software that helps you build, manage, and search a library of reusable RFP content, but we occaisionally take on clients for additional needs...