If you don't yet have a data warehouse, you're probably considering drafting a request for proposal (RFP) to obtain an idea of the prices and features of various hardware and software products. If you already have a data warehouse, you've probably deployed at least a few RFPs already and may continue to do so as you supplement your business capabilities.
Regardless of where you are, understanding how to submit an RFP will not only guide your vendors in delivering optimal responses, but will save you a lot of work in evaluating the resulting proposals. An RFP is often the only written communication a candidate vendor will receive from your company. If done right, it will make you look good. If done badly, well...
The Components of a Good RFP
Many companies in search of technology solutions have tried the "throw it at the wall and see what sticks" method of RFP creation. This means vaguely outlining what the company is thinking of doing, distributing the RFP to a hundred or so vendors and wading through all the responses to see which one's cheapest.
If price is your only evaluation metric, choose a vendor based on the lowest price. This makes the RFP creation a lot easier. But, since you'll be drafting a second RFP for the next vendor to clean up the resulting mess, I'd recommend drafting a structured and well thought-out RFP the first time around and evaluating responses based on a number of different metrics, including price.
The following list details the components of an effective RFP:
Company Overview: This section should describe your company, its industry, its history, its revenues and include a discussion of its market share. Historical information such as recent mergers and acquisitions and changes in executive staff should also be included at a high level.
Problem Description: The RFP should explain the company's original business drivers and include all necessary background information, including details about failed projects or false starts. The problem overview should give respondents a general idea of the "need, pain or problem" that the RFP response should address.
Solution Guidelines and Objectives: This part of the RFP should outline a set of questions or issues for the vendor to address. If the proposal is for technology, detailed questions about functions and features are appropriate here. If you are requesting a consulting proposal, ask for details about job roles, methodologies adopted and software tools used.
The RFP should present a pro-forma implementation solution description in order to aid respondents in crafting the right approach or proposing the optimal technology products. For example, if the proposal involves building a new front-end application for an existing data warehouse, you might see your project occurring in three stages:
Phase I: Business Analysis
Phase II: Prototyping and User Acceptance
Phase III: Implementation
Ask the vendor to describe a concise solution for each of the phases, including product, consulting and approach. Be sure to specify the objectives of each phase, as well as the ideal end-result, as in:
At the end of Phase II, the bank expects to have a functional prototype for financial reporting, including at least 13 canned reports and a range of ad hoc capabilities that match the requirements outlined in Phase I of the project.
If the proposal involves technology products, be sure to specify the exact type of technology you would like the vendor to bid. Asking the vendor to describe and price a from-scratch solution without describing the existing technology infrastructure or intended product purchases can foment misunderstandings and confusion, resulting in dissimilar responses. Better to specify the components you're interested in (hardware platform, operating system, database software and industry-specific data model) and how you expect them to fit together with what you've already got.
To maintain objectivity and ensure completeness, many companies retain a third-party vendor who is not involved in the bidding to help produce this section of the RFP, as well as to help judge the resulting responses.
Evaluation Metrics: Professionalism and fair play dictate that evaluation metrics are standardized for all potential respondents. This not only "levels the playing field," rendering each vendor equal in a full and unbiased consideration, but also mitigates the likelihood of unpleasant accusations from the losing vendors once you've made your selection. ("Hey! Vendor B was chosen because their salesman plays golf with the head actuarial's brother!")
Evaluation metrics force responding vendors to go on record with their strengths and weaknesses, and provide a glimpse of what you are looking for. "Ability of vendor to provide senior-level expertise in implementing our ROLAP application" is a sample evaluation metric. Another is "Vendor's list of customer references in the insurance industry."
Staff Expertise: If the RFP requests consulting or implementation expertise, detail the desired skill sets. Be specific about individual project roles. "Consultants should all have at least five years' experience, three of which involved relational database implementation" could apply just as well to a programmer as to a business analyst. This is where an open-ended question is okay, as in, "Describe the skill sets of the particular consultants slated to deliver application development and what makes them uniquely qualified." The answer will tell you a lot about the consulting firm's ability to deliver.
Pricing: It's up to you to define how you would like the vendor to price its proposal. While an interesting exercise in gauging various approaches, leaving it up to the vendor to decide between fixed-price and time and materials isn't worth much if your company insists on one or the other.
Remember to request price breakdowns, particularly when the RFP solicits prices for both product and consulting.
Projected Time Line: The RFP should include a high-level time line that includes:
- How long proposal evaluation will take.
- The date a decision will be announced.
- The projected project start date.
- The expected project end date.
If vendors are expected to deliver an in-person presentation as follow-up to their RFPs, specify the window of time reserved for oral presentations. Be sure to elucidate that presentations will be scheduled two to three weeks in advance, and vendors will be contacted accordingly. This will save you from the rash of telephone queries from eager vendors preparing their pitches.
Terms: You probably already have these in some standard corporate contracts. The terms protect you in the event that the project is canceled or none of the proposals submitted is accepted. Terms might also stipulate that proposals become your confidential property or that the RFP process doesn't bind you into accepting the lowest-priced proposal. See your company's legal staff for exact wording.
Proposal Response Guidelines: Before distributing an RFP, you should understand the mechanics of proposal review. Will you be assembling a proposal review team, or is management deciding? Will there be a meeting in which everyone will vote or an informal e-mail consensus? Knowing the answers up-front will give you a good idea of:
- Proposal structure and formatting guidelines so that evaluators aren't comparing apples to oranges when evaluating responses.
- Proposal delivery address. (Include the name and suite number of an actual staff member so respondents aren't left wondering if the proposal left in the lobby ever made it upstairs.)
- How many response copies should be submitted.
- Proposal delivery deadline. (Include not only a date but a time, so that you're not awaiting laggard proposals at 11:45 p.m.)
- Vendors will inevitably have questions about the RFP and its contents. While many companies hold general meetings in which vendors can ask their questions in an open forum, thereby permitting all bidders to hear questions and responses, vendors are often reluctant to query the RFP in front of their rivals for fear of betraying their strategies. Thus questions remain unanswered, possibly affecting the resulting proposal. Better to establish a process and deadline for submitting questions anonymously and in writing, and explain the procedure somewhere in the RFP document.
A Sample Table of Contents
BestBank Data Mart
|II. Company Background |
a. Executive Staff
|III. Statement of Need |
a. Business drivers for dependent data mart approach
|IV. Solution Description and Components |
a. Proposed functionality: data mart
|V. Response Guidelines||11|
|VI. Vendor Qualification |
a. Technology criteria
|VII. Pricing and Terms||22|
|VIII. Delivery Criteria and Question Clarification||23|
|Appendix A: Existing Technology Infrastructure||A-1|
Figure 1: Sample RFP Table of Contents
To tie these various components together, Figure 1 illustrates a sample RFP table of contents from a financial services firm interested in developing a dependent data mart. Notice the relative length of each section.
The best and most effective RFPs are those that nimbly balance corporate strategy and technical ideas, traversing the fine line between confidentiality and disclosure while leaving vendors plenty of room to showcase the best products and services they have to offer.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access