Summary:

1. The "best" vendor is the one most suited to your requirements
2. No one know your requirements better than yourself
3. Don't be afraid to let the vendors educate you about their products or services
4. Respect the vendors - don't invite lengthy response that you will likely ignore
5. Closed questions (multiple choice) are better than open questions
6. Fewer good questions are better than many questions of variable quality

 

Objective Bid Comparison

An RFP (Request For Proposal) doesn't have to involve questionnaires and surveys. At its most simple, an RFP can be just a letter or email to potential suppliers: "We intend to buy product/service X, please send me your proposal".

The problem with this approach is that the proposals returned will look very different from one another. This makes accurate comparison difficult and time consuming, and it will frequently be necessary to request further information from some or all of the bidders. A well structured RFP should request specific information from bidders, and require that this information is presented in a format that permits side by side comparison. Questions should be framed so as to elicit only information pertinent to the evaluation which lends itself to objective comparison and ranking of vendors.

Who is the Expert?

A major concern when starting an RFP project is whether or not the RFP author is fully qualified to assess the vendors. Big RFP projects often involve comparing very sophisticated products or services. The buyer is rarely a expert in the category. This can seem a weakness to be exposed by sharp talking salesmen. A common reaction is to draft a huge RFP that asks lots of complicated questions about the product or service being procured - the assumption being that this will put the vendor salesmen on the back foot. It doesn't work. Sales teams receiving such an RFP will conclude:

1. The buyer doesn't know what they want
2. They will be lost in the deluge of information returned by the RFP responses
3. The RFP is going to turn into a beauty contest, and the final decision is going to go to the safest bet (nobody gets fired for buying IBM...)

The best defence is for the buyer to focus on their own organization's needs. And the only expert in that respect is the buyer, not the vendor. An RFP is about putting power and control into the hands of the buyer, not the salesman. To ask lots of technical questions is to take the battle into the vendor's territory. Here are two example questions for buying a customer software system:

• Does your product/service include complex notifications features xzy, abc and foobar2? - BAD
• ABC corporation needs to keep clients informed of the progress of their support tickets. Please describe how your system supports this objective - GOOD

RFP Structure & Criteria Granularity

Generally, the greater the degree to which information requested by an RFP is broken down into sections and individual questions, the better. Each section and question can be given a weighting to determine how much it contributes to the total score for a supplier. However, if questions become too fine grained then it can be impossible to assign a meaningful weight. For example, suppose we start with a broad question about an IT vendors support services:

This question will invite a very general answer, covering product documentation, website support, phone support, 24/7 coverage and so on. A buyer might view some of these things as important, others as not. But with only one question there is no way to reflect these priorities. A better structure is:

Inspired by this improvement, we might decide we want yet more control and elaborate further on question 3.4:

We've achieved a greater level of detail, but by further breaking down the criteria it becomes more difficult to assign useful weights or scores. Do we really care whether forum comments are moderated? If so, do we care more about that or anonymous comments? In reality, we probably don't care much either way, and neither should we. So good rfp questions should be fine grained enough to allow us to fully express our priorities, but not so detailed that we get lost in irrelevant detail. In cases where we wish to assign a single weighting to a question, but where we need to be sure to capture specific information within the question, we need to design questions with sub-elements. This is a screen shot of such a question designed in PostRFP:

This question collects very detailed information, but is treated as one unit for scoring and weighting purposes. One of the more flexible characteristics of PostRFP is the ability to create questionnaires with any combination of sections and subsections to any depth, and with questions containing any number and type of input elements.

Closed vs. Open Questions

Open questions allow bidders to give a free form answer to a question. in some cases this may be difficult to avoid:

"Please describe your company history"

Answers to open questions can be difficult to compare. To take the above example, what might it be about a company's history that will affect their suitability as a supplier? One obvious factor is age. A young company might be viewed as being less stable or reliable. So we might replace the open question above with a new question:

"Please indicate the age of your company in years"

Now we've got some tangible data for side by side comparison. If we assume older is better, then we could score comparatively, so that the oldest bidder gets the best score for this question. However, on reflection we might find that this gives rather unhelpful results.

Does Vendor C really deserve a higher score than Vendor B? Not really. So we need to think about our requirements. Let's say that we're very worried by companies less than 3 years, concerned about companies less than 7 years old, and totally relaxed about the rest. So we can improve our question again:

Now we can assign a score to each option and have a fairly rational basis for comparison.

Questions can be too closed

We reflect further on our question about company age. Are there circumstances under which this rigorous, closed questioning might be unreasonable? For example, what happens if the company was formed as a subsidiary of a larger, older company, is staffed by a long established team from the parent company, and is well funded by the parent? We cannot foresee all the possible circumstances that might affect our assessment of this point. So we decide to allow the bidder to qualify their answer with a comments box:

With this question we can now apply auto scores to each multiple choice question so that scores are added automatically when the bidder submits their response. But the comment field allows us to moderate these scores for special cases.

Well Understood Requirements; Well Framed RFP Questions

Thinking through what the sourcing exercise seeks to achieve, and breaking this down into detailed service or product requirements is the critical aspect of an RFP. When the requirements have been clearly enunciated the process of drafting good RFP questions is relatively straightforward. Good questions are those that elicit the information required in a way that encourages accurate evaluation and comparison of vendors. Drafting an RFP should be an iterative process. As the RFP author endeavors to frame questions it soon becomes apparent which aspects of the project definition and requirements are vague or poorly defined. Struggling to write good questions should not be thought of as a tiresome chore but as an exercise in better understanding what problem is being addressed, and what service or product characteristics are required to solve it.

Web Based RFP Software & Collaborative RFP Design

Using a web based RFP software system can help the buyer to create good RFP questions because the questions are accessible, and editable, online. Thus a team of RFP participants can collaborate on the same questionnaire, reviewing, editing and approving questions. Furthermore, many of the same questions tend to crop up across different RFP projects. Fully featured RFP management software enables the user to build a library of reusable questionnaire elements (sections and individual questions) that promote reuse between projects.

Further Reading

Effective RFP Development, by Bud Porter-Roth