What should a RFP contain?

A good RFP should contain an accurate description of your organizations technology (software, hardware and service) requirements in a clear and lucid manner. If there is some technology infrastructure already existing make sure you include that in detail as well. Finally, evolve a set of transparent criteria based on which these short listed vendors can be evaluated and the timelines. This is (as the experienced ones will vouch for) easier said than done for each of these are complex tasks. Now a small and timely clarification. It is advisable that a detailed RFP be prepared and given only to vendors who have been short listed. Later in the article there is a part devoted to short listing of vendors.

GETTING THE REQUIREMENTS

Administer a survey across the organization covering all the departments identifying the workflow process and bottlenecks. Also try to identify among all these processes which ones are critical interms of current and emerging organizational priorities as well as plans. For example the survey should be able to identify situations where employees spend valuable time searching for, or correcting, data needed to complete a given task. Some examples of this situation would be manufacturing order entry on one hand, and document capture in a document management system on the other. Many other examples exist.

The good thing is that this also helps you arrive at reliable estimates of potential savings and financial impact to be made.

SHORTLISTING OF VENDORS

It is very time-consuming to review vendor respones to a fully detailed RFP, attend lengthy software demonstrations, and compare all of the proposed system features. One way to reduce this time drain is to send all potential vendors a brief list of key questions (known as a Request for Information or RFI) covering just the mandatory, “must-have” features needed to satisfy your major requirements. You can then “weed out” those vendors or products that do not have a close fit to your needs, reserving your time to deal only with the vendors who submitted the best 3, 4, or 5 responses to the RFI, i.e., those vendors are most likely to meet your needs the best.

Coming up with a list of “must have” mandatory issues can be done rather easily using the information collected in the survey mentioned above. This is also where system constraints can be imposed. For example, if the new system must interface with an existing legacy system, or must be used on an existing database, or must provide a certain key software feature, that mandatory requirement should be listed here and used as a means to weed out vendors who do not support that function early. Use a quantitative, weighted grade point scoring system to determine the best RFI responses.

Once those vendors and products with the highest potential for being well suited to your needs are placed on the shortlist, the task of preparing a fully detailed Request for Proposal (RFP) begins. Overall, the RFP must do two things - accurately communicate your organization’s needs to vendors, and elicit vendor proposals with the least amount of unplanned Q & A sessions from the vendors.

Accurately communicating your organization’s needs involves much more than simply presenting a series of questions regarding system features and company history to each vendor. Why? A simple list, no matter how detailed, provides no means of cross-referencing your organization’s goals and procedural priorities with vendor responses to the RFP. In addition, a simple list provides no means of enabling consistent vendor RFP responses to be obtained, or analyzed and compared on a quantitative basis. For best results, the questions found in a detailed RFP should:

1. be categorized by major organization business and procedural goals

2. be answered with clearly defined vendor responses

3. cross check each other to verify the vendor’s understanding of your unique needs (see legal benefits)

4. be directly related to the high level business procedures important to your organization

Obtaining consistent vendor responses is extremely important if you want to compare them to each other! If 3 different vendors answered a given question with YES, NO, and MAYBE, what do you do with the MAYBE? How can that vendor’s proposal be evaluated? All questions in an effective RFP must be clearly stated so there is no vendor confusion, and they must be worded to elicit a focused answer. Some tips are given below:

1. Use either YES/NO or multiple choice formats

2. In those cases requiring essay type answers, make the questions detail oriented

3. Electronic or Web RFPs must offer vendor input validation

4. Be sure options such as Not Available (NA) or Not Supported are clearly identified

Like we suggested earlier, a detailed RFP should only be sent to those vendors with the best RFI responses, 3 to 5 vendors at the most. This is because of the time required to distribute RFPs to vendors, and the need for one or more software demonstrations.

Manually copying and assembling a Request for Proposal that is 20, 30, or 50 pages long is no easy task. But even this time-consuming task pales in comparison with the daunting task of manually entering all of the vendor responses accurately! There is no question that electronically distributing an RFP to vendors, and receiving their responses back in an electronic format that can be quickly merged into a database, is needed! Be sure that the vendor responds to your RSP and does not add more to it, If he does you will have to depend on him to later de code it!!

(The article was written by the businessgyan editorial team, with major inputs from Shivaji SenGupta, a consultant and a Senior Professional.)

Issue BG8 Nov01

Related Items:

---

Be first to comment this article

Only registered users can write comments.
Please login or register.