Bad RFPs lead to bad responses to RFPs!

In my last article, I discussed the sins committed by companies responding to RFP’s.  Now let me talk about the other side of the equation.  For associations, or any company, writing an RFP, you can make it easier on yourself when it comes time to read the resulting RFP’s and easier on the vendors who are investing time and money to pursue your contract.

Reputable vendors want to do a good job (as well as make a profit on the project) and will spend time with your RFP especially if they see that you have spent time and care in preparing it and you clearly describe exactly what you want.  Yes, there are vendors that will go after anything and worry about fulfilling it later but you will probably recognize them when you read the responses and check references.

  1. Before you expect the vendor to understand your business and your processes, you need to understand them yourself.  Don’t make the assumption that “everyone does it my way”.  Map out the processes to be managed by the software and the specifics associated with those processes.  The vendor should have a complete view of each process they need to automate.
  2. Be concise.  The size of the RFP doesn’t necessarily match its value.  If you hire a consultant to write the RFP, the consultant should be paid for the quality of the RFP and not the size.  You need to review it carefully before it is sent out to vendors just to verify the quality.  Eliminate what doesn’t apply to you.
  3. Don’t just go out and buy a pre-written RFP even when it is not advertised as such.  When I was in the business, I saw this all the time as I reviewed one RFP after another from the same consultant with almost the same verbiage and checklists.  Make sure that your RFP actually reflects what you yourself need and not detail irrelevant to you.  Consultants think they can save time by starting with a previous RFP but this leads to a lot of extraneous “requirements” that just confuse the effort of the vendors and obscure your real intent.
  4. If you are including a checklist of requirements, organize them into specific processes that describe how you do business.  Include enough in each item to make it specific to the process.  For instance, “Send group email” automatically gets a “yes” from the vendor but “Send group email to everyone who has renewed their subscription but has not donated to the foundation” will get a much more specific response.  Checklist items should require a specific response and not a generality.
  5. Long requirements checklists are deadly unless organized very well and thought out very carefully.  As a vendor, we know there will be competitors who will just say they have or can do anything so the urge to bend the truth is very strong.  When the requirement is to general, they have no way to answer it honestly.
  6. A short checklist item is not necessarily a good thing.  The vendor may answer “yes” to just that one point without associating it with the rest of a process.  As a vendor, I would much rather see a checklist item that covers a more complete issue or process and that puts it into context.
  7. Avoid ambiguous questions and the questions that can’t be answered.  “Please give me a fixed price for an interface to something that hasn’t been defined yet.”  You laugh, but I’ve seen it.
  8. Organize the RFP in such a way that the vendor doesn’t have to copy the same boilerplate into multiple sections that ask for the same information.  On top of that, specifically request that the same boiler plate not be included in multiple sections of the response.  If the RFP is organized well, it can be answered efficiently and concisely and you will get responses easier to analyze.
  9. Avoid the unrealistic request.  If you don’t know some of these, ask an independent vendor or consultant that knows. For instance, only a company on the rocks and desperate for work will agree to an unlimited liability clause in a contract.  No single contract is worth risking the entire company.
  10. Don’t insist on a timeframe for delivery that absolutely can’t be met.  You may find a company that will agree to try but the only companies that will agree will be those that don’t have other profitable work to do or who don’t plan to actually do everything you asked for in that time frame.  Some companies will promise anything with the belief that by the time they get to crunch time, you will either give in on some requirements or will have become so invested in the project, you can’t cancel it.
  11. Be specific about how you want the prices organized so you can better compare multiple responses.  Separate fixed from variable costs.  Separate software from hardware from labor costs. Be sure to specify that the quote must contain all costs for the project.  I have seen companies leave out such things a software maintenance that can be very expensive later if not originally understood.
  12. Expect questions from the vendors, especially those vendors who are trying to answer honestly.  Welcome those questions and be complete in your answers.  If a vendor doesn’t ask questions, chances are they are answering your checklists without adequate thought.

Finally, when you read the responses, be open to the fact that the vendor may have a better approach to some business process than you do.  Don’t be married to doing everything the same way you always have.  In fact, if what the vendor already has comes close to what you want, you will find it vastly cheaper to adopt their process than customize something for yourself.

I complain a lot about bad proposals.  Then again, when I used to write proposals, I complained a lot about poorly written RFPs.  A lot can be accomplished when both sides are careful with what they write.

What do you think?  Am I way off base?