I received the following email from Keith Heller, a database consultant who works with Raiser’s Edge and Common Ground clients:
We’ve been involved with responding to many RFPs over the years and I have a general inquiry that is in your bailiwick. I often see RFPs that are quite lengthy and well-considered, and looking for a system that has huge strategic value to an organization, but the required turn-around time to respond to the RFP is very short – often only 2 or 3 weeks. I then see software vendors, who are already busy with other prospects, scrambling to pull together responses and often (quite frankly) not able to deliver their best because of the timeframe. Finally, I’m often witness on the client side to the returned RFP information languishing for weeks beyond their own deadlines (and/or this being characteristic of earlier deadlines in designing the RFP). What’s the thought behind requiring quick responses from the vendors? Or do the clients often not understand that vendors are working with multiple other organizations at the same time? It seems to me that if response deadlines were less compressed, vendors could craft a more appropriate response in a less stressful manner and that organizations would get higher quality and value from the responses.
My response:
Hi Keith,
You know the office proverb: “Bad planning on your part does not constitute an emergency on my part.” But if you’re a vendor it often does.
In most cases I don’t think nonprofits understand what they’re asking of the vendors. I advise my clients to allow 2 weeks for a simple Request for Proposals and up to 6 weeks for a complex one. At the same time many nonprofits don’t understand what’s involved in reviewing RFP responses. They haven’t thought about how they’ll score each one, and may not have set aside staff time (or enough staff time) for the task. So even if the turnaround is driven by real deadlines on the client’s side, they’re too overwhelmed by the responses to turn them around quickly.
A more cynical possibility is the dark side of RFPs — the winner was predetermined but the organization was required to get multiple bids. That could explain the unrealistic turnaround time–the organization knows the chosen vendor can meet the timeline (and the RFP may have even been created using a template supplied by that vendor). The delays in getting back to bidders could still be legitimate overwhelmedness. They could also mean that the other bids weren’t that important to begin with so there’s no rush to respond to those vendors.
What do you think? If you’re with a nonprofit, do you think your RFP deadlines are reasonable and realistic? If you’re with a vendor, how do you cope with these sometimes-artificial emergencies, and with the RFP process in general? Are you one of the many who simply do not respond to over-the-transom RFPs?
Resources:
My article Finding the Perfect Fundraising Database in an Imperfect World includes a section called “To RFP or not to RFP”
Idealware article: The Perfect Fit: A Guide to Evaluating and Purchasing Major Software Systems
Techsoup article: The RFP Process: An Overview
Ivan Wainewright says
I used to be a salesperson and now I am a consultant helping charities create RFPs, so I can see both sides of the argument. There is no point giving sales people an unrealistic timetable or they won’t be able to give a structured response, which ultimately won’t help the charity, especially if they can’t quote accurately enough. But I really believe your 6 week reponse for a complex RFP should be adequate.
Also depends on what that “n week” period actually covers. e.g. in some of my procurement processes, we create an RFP initially, send it to a short-list of suppliers and then immediately invite those suppliers in for “pre-demo” meetings, so both the charity and the supplier can learn much more about the other one before the demo. This works well. And sometimes I then only ask the suppliers to respond formally to the RFP after the demo itself. Thus, if there is only a short window at the end when we are asking the suppliers for a written response, they have actually had much more time before that to weigh it up, understand it better etc.
Robert says
Thanks, Ivan!
John Stanton says
Robert,
Having been in the predicament of responding to RFP’s on very short notice, I have a rather obvious, but sensible suggestion. Vendors should create a file that contains all the “generic” information potential clients are looking for:
1. Company info
2. Company finances
3. Key personnel (bios/resumes)
4. References (name, phone and email)
5. Sub-contractor info
6. Project Manager names and bios
7. Past experience with similar clients
8. Pricing info
9. Generic response envelope(s)
10. Insurance info
Most RFP’s also include requirements to note any information that may be considered proprietary. This information should already be categorized as such.
I hope this helps and I enjoy your blogs.
Thanks
Robert says
Thanks, John. I agree that vendors would be smart to have something like that ready. I mostly see RFPs for software products, and they usually ask for much more detailed information. They’re usually a series of yes/no/maybe questions about functionality and technology so a generic document would only save a small amount of time. But your suggestion would help with RFPs for services. The RFPs I see for consulting projects generally ask the same sorts of questions.
Robert
Robert says
Here are some thoughts on the RFP process from my colleague Deborah Elizabeth Finn.