Why RFPs Are Not Right for Everyone (and When You Still Need Them)

The traditional process for selecting software involves gathering requirements, embedding these in a Request for Proposal, sending the RFP to qualified vendors, and making a decision based on the replies. I don’t know where the process got started; I suspect in government procurement but perhaps it was large corporate bureaucracies. In any event, RFPs are widely detested by vendors who often do huge amounts of work without knowing whether their efforts will be rewarded or even taken seriously.

From the buyer perspective, a more powerful criticism is that the formalized RFP process prevents buyers and vendors from really understanding each other. Plus the process takes too long, and most buyers don’t understand their real requirements, anyway. (My friend Richard N. Tooker makes this case in his usual colorful fashion in his book The Business of Database Marketing. Another recent criticism is in Avinsh Kaushik’s excellent Occam’s Razor blog here.)

As someone who has written dozens of RFPs over the years, I sometimes think I should feel defensive about these criticisms. But I don’t. It’s partly because a well-constructed RFP process avoids these problems. But it’s mostly because I myself avoid RFPs when other, less formal approaches can be more effective.

The actual approaches vary. Sometimes you can conduct a “bake off” by giving vendors a specified problem and actual data, and seeing how they solve it. This works when requirements are well understood—for example, when seeking a replacement for an existing solution. When requirements are not known, it may make more sense to first work with a demo or free trial system so you can learn about the issues before making a final choice (this is Kaushik’s recommendation for Web analytics). On the rare occasions when both vendors and requirements are familiar, you can simply select a product after informal meetings with the top candidates.

I feel a 2x2 matrix coming on. Looking at what I just wrote, it boils down to how well you know your own requirements and how well you (or your consultants!) know the vendors. A different selection strategy makes sense for each combination:

Unknown vendors, unknown requirements: formal RFP (forces you to define requirements and thoroughly assess each vendor)

Unknown vendors, known requirements: bake-off (lets you quickly understand key vendor strengths and weaknesses; still need additional research into vendor background, etc.)

Known vendors, unknown requirements: free/trial/prototype installation (lets you learn about requirements before making a final selection)

Known vendors, known requirements: informal selection (you can easily assess the leading candidates and make still a good choice)

Of course, there is also a dimension of corporate culture: some companies, particularly the big ones, require a formal RFP process just because that’s how they do things. It’s reasonable for a big firm to act this way, since they must justify their decisions to senior executive and ultimately to investors, and because the stakes are so high that it’s worth some extra investment to avoid mistakes. (This assumes the more formal process actually avoids mistakes—not necessarily true, but it does improve the odds of success.)

On the other hand, a more formal process takes time, which can be very costly when you face an immediate need. In this case, it’s often best to start with an outsourced or hosted solution. This lets you get started quickly while leaving open the possibility of moving elsewhere later. It also gives time to learn more about your needs (moving quickly is usually an big issue for something new, not a replacement system) and to learn from the expertise of the interim solution provider.

I’ve used all four of the strategies in my little matrix at different times. The key point to remember is you're simply trying to find a product that meets your needs. It doesn't have to be the perfect product or even the best product but just one that's good enough that you can get on with your business. Several of the alternatives probably meet this goal.

Although some organizations do indeed award points for the quality of your selection process itself, it's really the outcome--having a suitable system--that's important. Pick the fastest, simplest, cheapest process that finds a good system, and you'll have made the right choice.