RFPs: Why they suck and don’t work.

Our company responds to anywhere in the neighborhood of 20 to 30 RFPs a year, and we’ve been in business more than 20 years. That’s a lot of RFPs. It’s also a lot of time contemplating their effectiveness. Or their lack thereof.

The inherent problem with RFPs is that they force the organization that doesn’t have the expertise to do the work themselves to write the specifications for the project. In application and web development, that involves a lot of technology experience from people whose business isn’t technology. It’s the equivalent of a patient arriving at a hospital and saying, “I need brain surgery. Here’s how I want you to do it.”

Based on that, three not-so-good things happen:

  1. The customer ends up asking for something that may or may not be the right fit
  2. The vendor must respond to the specs of the RFP whether or not it’s the right fit
  3. The customer may not be getting a realistic quote

In addition, there are probably key details that will be missed in the bid and those could affect the price. So even the comfort of having a fixed price RFP is a sort of myth in itself. Worse, some companies exploit that and low-ball the bid, knowing there will be significant overages later on.

In our experience, RFPs are bad for the client, bad for the vendor and bad for the project.

But there is hope. And a good solution. Here’s a scenario using an alternative approach to the RFP:

Say you need your website redesigned and you’ve found 4 developers that might fit the need. Instead of writing an RFP, have them submit an expanded Request For Information (RFI). You say to those vendors, “Here are the goals of the project, here is what we want to achieve (more web traffic, convert visits to sales, etc etc).” Then, ask the vendors for the standard credentials (number of employees, how long they have been in business, similar clients, etc).

But here’s where the expanded RFI blows the RFP out of the proverbial water: Ask the vendors, “Knowing our goals and looking at what we are doing now, and based on your experience, what are your recommendations? What are your observations? What are your ideas? And based on similar projects you have done, what were the costs for those projects?”

With this approach, the customer gets the vendors’ recommendations based on their expertise rather than a regurgitation of your specs. Also, you get insight into their thought processes and thoroughness, as well as an estimate of the cost of a similar project.

Now, here’s the big closer: once you’ve chosen the vendor who most closely matches your needs, together you then build the final specs for the project and from that, develop a firm, final quotation. This is the vendor who will guide you through the pitfalls, and can save you costs, save you time and save you a lot of the headaches that are endemic to the web development RFP world. You get what you want and what you need.