When most business people think about buying software, they imagine a structured process: define requirements, identify qualified vendors, send them a request for proposal (RFP), research the most promising respondents in more detail and make a choice. It's somewhat bureaucratic, perhaps even ritualized. But it does promise a thorough, objective process that should yield sound results.

Vendors hate it.

It's not precisely that vendors dislike competition, although none would turn down a noncompetitive sale. It's more that they feel the standard process doesn't let them learn enough about prospects to propose a solution that really meets their needs. They also argue that structured interactions prevent clients from understanding what truly makes each vendor special - which often has more to do with people and processes than technology.

But most vendor ire is directed at the RFP itself. A serious RFP can run to hundreds of pages, requiring detailed answers to questions with little obvious bearing on a customer's true needs. Often these needs themselves are not stated clearly enough in the document to allow relevant answers. The RFP is frequently sent with little preliminary contact, leaving the vendor unable to judge whether it is being considered seriously or is just "column fodder" included to make the process appear comprehensive.

Yet RFPs do serve a purpose. In fact, they serve several. One is simply to meet the bureaucratic requirements of an organization. In any company bigger than about five people, the product research will be carried out by someone other than the person who signs the check. That person needs to know the selection process was run properly. The RFP and resulting responses show what questions were asked and how vendors replied. Decision-makers can easily review this to assure themselves that the recommended solution makes sense.

A second value of RFPs is that they really do force vendors to provide complete information. It's pitifully easy for a good salesperson to focus prospects' attention on strengths and distract them from weaknesses. The RFP gives a thorough list of questions and answers, which buyers can review at their leisure to identify topics that merit further exploration. The proposal resulting from an RFP is often the only place to get specific pricing from a vendor - although most experienced buyers consider this just a starting point for negotiation.

But the greatest value of an RFP lies in its preparation. A good RFP includes a detailed description of the company's business situation, technical environment, project goals and specific requirements. Assuming the company or its consultant is already familiar with the available vendors and functions of the system being purchased, most of the work in preparing an RFP lies in gathering the company information and defining an appropriate solution. Done properly and in enough detail, this provides vendors with the information they need to bid intelligently and greatly shortens the discovery process at the start of implementation.

How much detail is enough? Your best guide is to think like a vendor. Try to provide all the information that someone unfamiliar with your company would need to understand your situation and propose a suitable solution. This begins with a general overview of your business, going into more detail in the areas that are relevant to the project at hand. Describe the major components of your technology infrastructure and any relevant standards or constraints. Give additional details about the systems that relate to the project: data volumes, update cycles, file structures and so on.

It may seem odd not to start the RFP with the project objectives. But it really makes more sense to first tell vendors enough about your company that they can understand why the project is needed, where it fits into the larger scheme of things and how they can help you. You want their best thinking on your situation, not just responses to questions about their product. You also want the vendor to judge whether they are really a good fit for the project. If not, having them bow out sooner rather than later is in everyone's interests.

After project objectives are defined, you can jump into specific requirements: product functionality, processing windows, numbers and types of users, target response times and so on. Again, you should be as specific as possible. Include an appendix with sample files, process flows and reports if these are available and relevant. Define any specific constraints, such as particular operating systems, security features or on-premise deployment. You also need to describe the project schedule and how you want to divide work between the vendor's resources and your own during implementation. A complete RFP also asks about vendor background, professional services available, support policies, contract terms and pricing.

In other words, an RFP is much more than a list of questions for a vendor. It's really a tool to organize your own information and present it in a way that lets the vendor help you. Preparing a proper RFP is a lot of work. Fortunately, you don't always need to do it. I'll discuss some alternative approaches to system selection next month.  

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access