While I think RFPs can be useful tools for some projects, I'm not confident about their utility when buying complex, commercial software. A good RFP should provide enough information to allow an organization to make a decision, such as qualifying or disqualifying potential vendors. Unfortunately, I think many RFPs fail this test.

First, some vendors do not respond to RFPs. You might be eliminating qualified vendors without good reason. Even if they do respond, vendors can choose not respond to specific RFPs, often because the amount of time needed to respond to a long, complex RFP isn't balanced by a reasonable expectation of success -- many RFPs hide the fact that another vendor has been chosen.

Even if vendors respond to an RFP, the mere fact that they they say their system has a desired feature doesn't mean that the feature works the way the organization hopes it will. This is because RFPs only lend themselves to "do you do X?" questions -- it's difficult to ask "how do you do X?" questions, which often matter most. It can be difficult to write "do you do" questions in such a way as to eliminate or qualify vendors. There are exceptions, though. Asking whether a vendor can handle Japanese Kanji characters or process donations in Euros are useful questions to put in an RFP -- they're specific, not routine, and not based on HOW the vendor handles a function.

When I use RFPs, I try to keep them short and focus on the most critical, non-routine features that can be described without "how do you do X?" questions. Every question should allow the organization to narrow the vendor pool, and every response should be scored. After rating each RFP response, you should have a short list of vendors that can meet your most important requirements.

If you're selecting software, your next step should be to hold structured demos to see how the systems actually perform the functions you're interested in.

Robert

Once you've written your RFP, it's just as important to publicize it and get a substantial number of competitive bids. A good place to publicize your RFP is the RFP Database where you can post your project for free.

Robert Weiner is right on the mark to suggest your follow-up to the RFP be a structure demo from the finalist candidates. But here's an additional perspective.

Now you've reduced the pool to the ones who seem best able to meet your needs. One of the things I've learned is that our (the fundraiser's) perception of what we want can all to often be limited by our perception of what we do now.

Make room in those demos to explore next steps to growth, alternatives processes, and offer up a few well-considered "what-ifs" (ala what if we wanted to start engaging volunteers online?). Sometimes, closely competitive demos diverge dramatically when the discussion moves beyond today's tasks.

Hope this helps get you the right tool for the job!

We have made a decision not to participate in RFPs a while ago exactly for reasons Robert describes. Most of them are very poorly thought out while limiting you answers to their structure while as a conscious consultant I know they failed to consider many other things - and really want to discuss it with them!

When I was on the other side of the fence (working for a vendor responding to RFPs) a salesman I worked with had a saying

This is America we can respond to the RFP in any way we want to. If the client is intelligent they will see our value and enter into discussion with us, other wise we don't want or need them.

It made sense when the RFP demanded totally unreasonable or corporately improper requests.

Dave