Do You Really Need an RFP? Because It's Really a Pain...
Nevertheless, the inconvenience today may well yield better results at the end of the process.
It's true--a Request For Proposal (RFP) process can take a lot of time and effort. So when does it make sense to go through the effort?
1. When you are making a complex purchase, an RFP will help you organize both yourself and the vendors who are bidding the products and/or services you plan to obtain. Putting your requirements in writing up front helps you to decide what capabilities are essential and what is optional.
2. When you need more information about the product and/or service, how it works, and how it will meet your specific needs. In an RFP, you can describe a situation or a problem and the bidders can explain how their solution would address your specific issue(s).
3. When you want some protection from over-promising and under-delivering, an RFP gives you proof that specific claims were made and makes your position very strong if problems arise. This protection is much stronger when you include the RFP and the successful vendor's response in the final contract (See "5 Tips for Successfully Installing a New Telephony Solution").
4. When you want to demonstrate serious intent to make a change from your existing technology or provider. If you go to the trouble to create an RFP, the vendor community knows that you are making a commitment to review your options.
5. To give you leverage not only with the incumbent vendor, but with also with the other bidders. The incumbent gets the message that the golden goose may wander off, and the other bidders also know that the process is competitive and that they need to put a good offer on the table.
So how do you create a good RFP? One approach (admittedly self-serving) is to hire a consultant to write it for you. Experienced consultants have developed a methodology for creating RFPs and know what information vendors need in order to provide a complete proposal. In addition, consultants are familiar with the marketplace and know how to create a document that elicits the best responses for a client.
But if you insist on writing the RFP yourself, here are some tips:
1. Be clear on what capabilities are "Required" and which are "Desired" or optional. It is very difficult to compare proposals when they are for different sets of capabilities. The document should have a well-defined set of core requirements that every proposal must meet.
2. Insist that the bidders are clear about which capabilities are included in the system as proposed, and what capabilities are available for additional costs. It is often hard to distinguish between a "system capability" and an "included system capability."
3. Specify your anticipated growth so that the system can be sized to meet your needs over time.
4. Have the bidders spell out server requirements, including who provides them, the OS, CPU and memory requirements, and whether they can be virtualized (if this matters to you). Add in any costs there may be for customer-provided servers in your cost comparison of the proposals.
5. Include terms and conditions that your company requires in an agreement (such as including the RFP and the successful vendor's response in the final contract). In their proposals, most vendors will take exception to terms and conditions that they don't like. While they are not necessarily final, this will allow you to get a feel for the effort that will be involved in negotiating a contract with the various bidders.
6. Create your own format for the pricing and require the bidders to use it. This will allow you to have a common format for your comparison. In addition, we require the pricing to be submitted in Excel format rather than .PDF so that we can cut and paste into a comparison document.
7. Address your requirements for installation and testing. After all, the best solution in the world must be properly implemented in order to function as expected. Your requirements should state what recourse is available to you if the system does not perform as described in the vendor's proposal; otherwise, you will be left with minimal options if you use the vendor's contract language.
8. Define your acceptance requirements, including proper system operation, completion of all training, and provision of all required documentation (including passwords, IP addresses, copies of software, system documentation, training materials, etc.). Withhold a significant percent (we prefer 25%) of the contract value until acceptance so that the vendor has an incentive to complete the project and fix any remaining items on the punch list.
9. Specify your training requirements including the number of end users to be trained as well as the number of system administrators. Also specify your training format; do you want classroom training with live phones or will a webinar work? (See "5 Tips for Successfully Installing a New Telephony Solution for more information on this).
10. Specify your ongoing support requirements, including response times for major and minor outages. Be sure to define a major outage; most vendor contracts have definitions that may not meet your needs. Also define response times for moves, adds and changes unless you plan on handling those yourself.