Previous Next |
Sample RFPThis section contains a sample RFP structure that you can customize if you wish to use an RFP process. RFPs are massive documents because each and every item in the requirements list will need to be translated into an RFP question. This sample simply refers to the requirements list when appropriate to avoid needless repetitions, but shows the other sections in detail. Many companies have standards for RFPs so use the suggestions here to augment the process that already exists in your organization if there is one. RFPs are organized as follows:
Let's explore what each section contains. Cover LetterThe cover letter is simply a transmittal memo that summarizes the purpose of the RFP, orients the vendor to the way the RFP is packaged, and states the basic requirements for responding to the RFP.
RFP InstructionsThis section describes how the RFP process will work and gives specific instructions on how to respond to the proposal. Proposal GuidelinesStart by giving a short summary of the context of the RFP: why are you interested in a CRM tool? What are you trying to achieve? What target dates do you have in mind? This is only a summary so the vendor can confirm its interest in preparing a response. A more detailed description is included in the next section. Then, give the following factual information about the process:
Vendor InstructionsGive instructions to the vendor on how to complete the RFPs, typically to provide clear and concise answers, to use the rating scorecards for the technical and functional requirement sections, and perhaps to provide pricing in a spreadsheet format. State that the RFP answer will become part of the contract. Give detailed instructions on when to respond and how. Electronic responses are common and they are often preferred because they can be shared easily. State any format requirements. Company InformationThis section gives the vendors information about your organization. It's important because it sets the tone for the proposal and it allows the vendors to tailor the RFP to your particular needs. The company information section should include the following subsections:
Vendor QualificationsThis section asks the vendors to describe their corporate fitness to meet the requirements. Many of the questions are taken from the "Vendor Requirements" section of the requirements list. Many deserve the full written answers that are asked since they don't lend themselves to the scoring system we will see later for the technical and functional requirements. Vendor ProfileThis section typically starts with a free-form statement from the vendor. I recommend limiting the length here for fear of getting back a very long and not very relevant expose. It is useful to get a feel for the history of the company, though, as it can indicate much about the vision and the executive team. After the overall statement, questions in this section include:
Product strategyAsk the vendors to explain their plans for new releases, new markets, and new customers. Place a limit on how many pages you will consider or ask specific questions to avoid getting massive amounts of information that's not directly useful. I recommend asking both for a long-term plan (say 3-5 years) and for the contents of the next major release, which should be firmer. ReferencesSpecify type of customer, location, configuration, etc. We'll discuss references more fully in . Ask the vendor to provide contact information for each reference. Contractual TermsAn RFP is not the place to negotiate detailed contract terms, so your goal is to gather information on standard terms so you can get ready to negotiate. If specific terms and conditions are important to you, by all means include them in the RFP. Specifically request:
Product OverviewProvide an overview of the recommended system. Technical RequirementsThe technical requirements section, like the Functionality Requirements section that follows it, is usually constructed to match exactly the requirements list you created. Both require the vendor to answer each question in detail as well as rate its ability to match the requirements in a scorecard similar to the one we showed in the last chapter when we discussed requirements. Questions take time to create, which is one of the main reasons why the RFP process is resource-intensive—the other reason is the scoring—but they are often necessary to communicate the nuances of each requirement. Compare the following RFP question:
with its corresponding, terse item from the requirements list:
It's clear that you will get more information from the question than the item as is. And, at the same time, it will take you much longer to interpret and score the answer to the question than to look at the rating. Whenever possible, use short and precise questions to increase your chances of getting unbiased information. Start the section with instructions on rating the items. It's usually very dangerous to use a simple yes/no rating system, since anything that's remotely possible will be rated with a "yes". Most RFPs use a system similar to this one with four categories:
Functional RequirementsThis section is by far the longest in the RFP, matching its length in the requirements list. Proceed as you would for the technical requirements section, asking vendors to provide both written answers and ratings. Implementation and Support RequirementsThis section explores the implementation and support requirements per the requirements list you created. If you expect the vendor to provide implementation services, you will probably have to create a separate statement of work and negotiate it separately, but you can ask about high-level information in the product RFP. Even if you are completely certain that the vendor will not be the integrator, it's useful to get the vendor's high-level estimates of what an implementation would consist of so you can use it when selecting an integrator. Here are items to request for the implementation:
For training, request the course list, complete course descriptions, pricing, end-user training options, and the availability of a train-the-trainer program. Request recommended backgrounds and custom curriculum suggested for system administrators and implementers. Request training schedules and course availability: if courses are always tutorialed, your technical staffers may need to wait for a long time before they can be useful. You may want to request sample user documentation in the RFP. For support and maintenance, be sure to detail the requirements down to the SLA (service-level agreement) level. PricingRequest firm pricing quotes for the configuration(s) you require. It's useful to request several quotes for different configurations, as it may be advantageous to purchase a license for slightly more users than you currently have. Quotes should include implementation (if provided by the vendor), maintenance, and other services such as training. Request future pricing information as well. For instance, are maintenance price increases capped? How will maintenance be computed in the future? |
Previous Next |