Top 8 Sins For RFPs

Working at Urban Insight, I see about 10-20 RFPs for various projects each month. We have to evaluate the cost/benefit of deciding to respond to any one of these RFPs, and so the RFPs are evaluated by us much the way that our proposal would be evaluated by an organization or agency.



While some RFPs are outstanding, and clearly describe the project, evaluation, and process, others are, well, downright embarrassing, or contain clauses and provisions that leave you scratching your head.



What caught my attention today was an RFP from a county government that was sent to me. Although it's not an RFP we'd respond to in any case, the title reads:

INVITATION FOR BIDS FOR SERVICES FOR PREPERATION OF A STRATEGIC PLAN FOR HARBORS, BEACHES, AND PARKS.

How sad is it when you can't even correctly spell the title of the RFP?



Here are my top eight worst sins/pet peeves for RFPs.



8. RFPs due the following day, or within a week of the time I receive it. Yes, this happens. In fact, one private company I know routinely sends out RFPs with a three to five-day response window. The purchasing agent representing the organization says that this is plenty of time for firms to prepare responses. If you'd like a quality response to an RFP, you should allow for two weeks for a response.



7. RFPs that require that they be printed on a certain kind of paper, such as paper that is a minimum of 20% post-consumer waste recyclable. Sheesh. While I appreciate your commitment to promoting an alternative industry, please don't press me into service in support of your environmental goals.



6. RFPs that require that you open your books for an audit for a million years following the project. One RFP we saw required that the selected company's financial records would need to be available for an audit by the agency or state for a minimum of 7 years, upon 12 hours notice. How scary is this?



5. RFPs that include 100 pages of boilerplate legal language, and a one-page project description. I've reviewed RFPs where almost the entire RFP was legal and organizational boilerplate language, with a project description that was entirely inadequate for preparing a proposal. If you're going to go through the hassle of soliciting and evaluating RFPs, at least consider investing some time up front to document the project well.



4. RFPs of a technical nature where it's clear that whoever wrote the RFP has no idea what they're talking about. Since we respond to RFPs for technology consulting services (building websites, developing content management systems, building database applications, etc.), we receive lots of technology-related RFPs. Some of these are outstanding, and it's clear that a technology professional wrote, or at least edited, the RFP before it was released. Some RFPs, however, are written as if the writer think s/he is an expert, but in fact, knows very little about the industry. The tell-tale signs of this are the use of lots of buzzwords out of context, and sentences that make no technical sense. Please, have a technical professional review your RFP for technical merit before you expose it to the public.



3. Agencies that do not acknowledge the receipt of proposals or ultimate action on a proposal. This is actually more common that you'd think. Lots of agencies receive responses to their RFP, and then don't take the time to acknowledge receipt of the RFP, or let the non-winning proposers know the ultimate status of the project. It seems to me that many organizations don't appreciate or value the time that goes into preparing a quality response. I know we're not going to win all of our proposals, but having invested that time, it would be nice to be kept up-to-date on project, and notified of the final action.



2. RFPs that have obviously been written with a firm in mind. This almost qualified as my top sin. Sometimes it's so glaringly obvious that a proposal has been written for a specific product or firm, that you almost have to laugh. In one case we were sent a Word document where the author had obviously just copied and paste the feature list for a software product from the website of the preferred consultant. Turning on Word's "track changes" features even showed the edits that had been performed to the source content. If the organization issuing the RFP has already identified a firm to do the work, please find a way to hire them, and don't waste the time of the organization and the proposing firms by going through an RFP charade.



1. The top sin/pet peeve is an RFP that is pulled back (cancelled) after responses have been received. My favorite was an RFP that required a custom proposal. The agency received ten responses, and then cancelled the RFP with the statement to the effect that "Staff determined that the RFP was not specific enough in its scope of work to generate meaningful proposals". Can you imagine the wasted time and effort from the ten firms that took the time to respond? This kind of behavior gets you a bad reputation and causes firms to ignore your future RFPs.



Do you have a top pet peeve for RFPs? Write to me, and I'll include it in my next post.