After Hours optimize

10 things you should know about creating an effective RFP


Purchasing and implementing a new hardware or software system can be daunting, often involving multi-year project lives and multi-million dollar costs. If you think about it, the same issues arise in efforts such as internal systems development projects. In the latter cases, a correct understanding of requirements is crucial to success.Similarly, you can think of the request for proposal (RFP) as being a statement of your requirements. When internal software development projects fail, they do so often because of inadequately defined requirements. For that reason, the clearer and more comprehensive your RFP is, the greater your chances of getting higher quality responses that lead to a successful outcome. Following these tips will help you.

Note: This information is also available as a PDF download.

#1: Involve the right people

The classic complaint of an internally developed system is that "no one uses it." When you investigate further, you often find that the people who actually use the system had little or no say in how the system was to function. Rather, the internal IT group developed the system based on its own understanding of how things should work. Alternatively, if the IT group did contact anyone in the user area at all, it might have been the users' managers, not the users themselves.

Don't make this same mistake when preparing your RFP. Make sure that everyone who should be involved in the process actually is involved. Will you be considering innovative ways of acquiring the system? If so, your finance organization should be involved. Do you have special terms and conditions you will want? I hate to say it, but you should have an attorney involved.

#2: Check the accuracy of your processes and current environment

Verify the accuracy of the description of your current environment. Have you included all systems and all interfaces? How accurate are your figures regarding transaction volumes? Are you discussing average numbers or peak numbers, and regardless, how clear are you in making this distinction?

If your statements contains inaccuracies, and you later run into performance problems, your vendor probably will point to those statements as an "out."

#3: Be clear on priorities and evaluation criteria

What features of a system are the most important to you -- that is, what MUST you have? What other features are merely desirable, "like to have" items you can live without? Being clear about these criteria, and ranking them by importance, helps both you and the vendor in setting expectations.

#4: Consider a confidentiality clause

Vendors who respond to your RFP might be concerned about sharing proprietary or confidential information with you if they believe there's a chance their competitors will see it. At the same time, you might have reservations about sharing information about your own operations for the same reasons. One way of helping address these concerns is via a confidentiality clause. The wording of such a clause is beyond the scope of this article, but in essence it establishes an understanding that one side, in exchange for receiving confidential information, agrees not to reveal it to others, or to reveal it only if certain other circumstances apply or develop. Needless to say, if you agree to keep vendor information confidential, you must make every effort to do so.

#5: Determine who bears the costs of preparation

The most common practice is to specify that the vendor bears the costs of preparing the response to the RFP, including any travel expense to pre-proposal conferences. You also may want to consider a statement that the RFP preparation process is separate from any billable work that might result from a successful submission. In other words, you probably want to keep the vendor from recovering RFP preparation expenses through the actual project itself.

#6: Consider vendor involvement in RFP preparation

What about involving a vendor in preparing the RFP? Yes, I know it's like asking a barber if you need a haircut. But as long as you consider and can mitigate potential conflicts of interest, involving a vendor can save time and effort.

Vendors who prepare an RFP easily could write evaluation criteria that favor themselves. Therefore, consider having a requirement that the vendor who prepares the RFP is ineligible later to contend for that RFP. An alternative is to employ a vendor who wouldn't be competing anyway. In this case, though, you'll probably want that vendor to certify the absence of financial interests in any of the competing vendors.

#7: Distinguish between references and reference letters

When asking for references, be clear about what you mean. Do you want merely contact information (organization, name of person, telephone, and e-mail)? Or do you want actual letters of reference from that person? Yes, I have been "burned" on this point, submitting the former when the requesting organization actually wanted the latter.

#8: Be sure you give consistent answers to vendors

Because vendors will prepare their responses based on your information, giving consistent answers is critical. In fact, problems in this area, depending on how your process is set up, might be grounds for nonselected vendors to file a grievance. Two specific areas are the following:

  • In response to a question from a vendor, two departments in your company give two different answers.
  • In response to the same question from two different vendors, a person in your company gives different answers to each one.

To minimize problems, first consider designating only one person as the contact person. Second, to ensure consistent information regardless of vendor, avoid giving isolated answers. Instead, answer questions to everyone at the same time. You could do it in front of all the vendors at a pre-proposal conference. Or you could set a deadline by which vendors must ask any questions. Then, issue a common question-and-answer sheet.

#9: Check the details of delivery

Check and double-check the way in which you wish to receive RFPs. Will you take fax or e-mail submissions? If so, what fax number and e-mail address do you use? If you're taking only hardcopy, specify how many copies you need. Do all of them require an original signature or just one?

What about dates? Be clear about whether the date for submission is a postmark date (less likely) or a date of receipt (more likely). Also, be aware that if you give only a U.S. postal service box, vendors will have to use U.S. mail and will be unable to use an overnight service such as Federal Express.

With regard to time of day deadlines, be sure to specify a time zone. To avoid confusion, I recommend omitting references to "standard" or "daylight" time, because these designations are time-of-year specific. For example, specifying a date and time of "July 6, 2008, at 5:00 p.m. Eastern Standard Time" makes no sense, because in July, most of the country observes daylight saving time. Therefore, the correct time should be "5:00 p.m. Eastern DAYLIGHT Time."  To avoid such confusion, consider simply "5:00 p.m. Eastern Time."

#10: Follow up with nonselected vendors

I know it's extra work, but consider following up with nonselected vendors, if they ask. It might be helpful to go over with them the decision process, so that they can possibly make improvements internally. Taking this time could increase the chances that they'll want to respond to a future RFP.


About

Calvin Sun is an attorney who writes about technology and legal issues for TechRepublic.

2 comments
hamads
hamads

We have seen significant Application performance degradation when applications are run on a virtual environment VS a Physical environment. The extra virtualization layer is obviously a cause as is the allocation and sharing of physical devices/resources. Make sure you benchmark and set reasonable performance expectations before diving into Virtualization.

david
david

How about distributing it to get a wide range of proposals? You can craft a great RFP, send it only to a select few vendors that you know, and miss out on the right vendor for your project. I recommend posting your RFPs to sites such as the RFP Database at http://www.rfpdb.com which enable you to get a wide distribution for your RFP. The second thing you need to have is a good way of judging the proposals that you receive. How do you make sure you're comparing apples to apples? How will you be able to tell which is the better project/vendor for the money and which one will deliver the right solution for you? Before you even send out the RFPs you need to have decided internally how you're going to judge the responses.