In the WCM Analyst Panel at Gilbane last week there was a bit of discussion about how to write RFP’s. The Gilbane analyst gave advice like, “Use open-ended questions rather than yes/no questions” and then went on to complain about vendor (un-)responsiveness to his 150-question RFP’s.

I dislike RFP’s. Even if you eliminate from consideration RFP’s that are obviously rigged toward one vendor or RFP’s sent to a vendor for the sole purpose of the vendor serving as column fodder, the vast majority of RFP’s are too often misused. RFP’s may be an acceptable way to buy commodities like office supplies and construction materials, but they are a terrible way to by complex, often heavily-customized software. It’s highly unlikely that you are going to be able to come up with a set of questions that either (a) distinguishes one vendor from another in the areas that matter or (b) gets to the heart of whether or not that solution will ultimately be a good fit for your very specific requirements.

I realize that in some companies, the purchasing department can be pretty hardcore and that the RFP process may be as certain as death and taxes. If it’s unavoidable, at least try to use RFP’s in a way that makes the most of your time and the vendor’s. One thing the analyst said that I totally agree with is that you should think of your CMS implementation as you would a custom application implementation. If you accept that a significant amount of customization will be required, why would you then go on to ask detailed questions about functionality that in all probability won’t exist until it is developed as part of your project?

The point of the RFP, then, should be to figure out if the CMS fits your environment and your world view. RFP’s should be focused on weeding out solutions that won’t work for you based on things like architecture (platform, language, and other “enterprise footprint” dependencies), licensing model and cost, company viability/stability, support options, and ease of customization. You ought to be able to do that in 10 questions or less. And, really, you ought to be able to answer those questions on your own by looking at the vendor’s web site. Once you’ve used those to create a short list, then it’s time to have real conversations between yourself, the vendor, and your integrator and start working out bake-off logistics.

Anything more complicated than this is a colossal waste of everyone’s time. I recently saw a company issue an RFP to about 15 different CMS vendors running the gamut from the usual “leading” closed-source vendors to a couple of open source players to mid-market players to services firms pitching custom solutions. Such a diverse field is a huge red flag and an indicator that either the client really doesn’t know what they are looking for or they don’t understand the market. Analysts, services firms, and online communities can help in either case, but only if the client (and the client’s purchasing department) lets them.

The other painful thing about this particular RFP was that it was well over 200 questions with the majority of those being around unimaginable minutiae. I’ll bet the first 10 to 20 questions could have been used to eliminate 2/3 of the field from consideration.

Rather than reacting to lackluster RFP responses by adding more questions, diving into microscopic detail, or tweaking the format, consider whether a shorter RFP focused on narrowing the field based only on the most critical fundamental requirements followed by a bake-off with two or three vendors wouldn’t be more effective. My hunch is that in most cases, it will lead to a higher quality decision in a shorter amount of time.