A request for proposal (RFP) is a method that many companies use to solicit bids or proposals for a service or project. The RFP process is tightly structured and intends to provide unbiased, competitive proposals that make it easier for buyers to compare responses between different vendors or suppliers so that they can make informed choices. Some publicly funded or government-based organizations are required to use a standardized RFP process in an effort to make the bidding process fair.
The RFP’s Purpose
The RFP is used to inform potential vendors of a buyer’s specific requirements and expectations for a product or service. When companies take the time to create a detailed and accurate RFP, it can be a powerful tool to help select the most appropriate solution. Depending on the company’s policy, RFPs may be made available on public websites so that any vendor that feels qualified can respond, or the RFP may be delivered to those prospects that have already been vetted.
Once the need for a product or service (such as an IT system) is determined, a company can begin the RFP process to let vendors know that it (the buyer) is interested in a proposal for a solution to fit its specific requirements. Through the RFP process, vendors or suppliers describe their solutions and how those solutions match up to the buyer’s requirements. The buyer can then use the RFP responses to evaluate and compare different vendor solutions and select the one that best fits its needs and budget.
RFPs are specifically useful when there are several solutions available that may fit the buyer’s needs, and the buyer is seeking the “best fit” solution. The RFP process can be the starting point of a long-term business relationship. In many cases, RFP terms and responses are included as part of the final contract, and vendors are held accountable for their “promises” in the RFP response.
Evening the Playing Field
The structure of the RFP process requires participating vendors/suppliers to be subject to the same rules and privy to the same information, meaning the RFP allows responders to compete on a fair playing field. By having standard requirements and questions, the RFP responses are easier to compare.
Getting Started
The RFP clarifies expectations and schedules, creating a starting point for the future business relationship. Buyers can avoid the problem of missing critical requirements in an RFP by completing a thorough needs assessment that is used to create a comprehensive, well-thought-out RFP. Once buyers define an area where they desire a new software or service and confirm administrative support, they proceed through the following steps:
- Define what problems the solution needs to solve.
- Identify potential vendor candidates.
- Create a budget and timeline for the project.
- Determine and assign personnel who can support the project.
- Develop a detailed list of requirements to include in the RFP.
- Agree upon evaluation and selection criteria.
Request for Information (RFI)
Taking a step back, sometime prior to the RFP, prospective buyers may choose to send out a request for information (RFI) to determine which vendors may be suitable for the RFP process. The RFI is a less formal document that requests to learn more about the offerings of various vendors’ products and solutions. Buyers can use the RFI response to determine if the solution is a prospective fit for their needs and to select a pool of potential vendors/suppliers to receive the formal RFP.
An RFI will ask basic questions about a company’s history, stability, future plans, product capabilities, etc. Unlike the RFP, an RFI does not inquire about pricing. Orchard Software offers an online RFI that those interested in more product information can complete to specify if they would like an information packet, a product demonstration, or a sales call.
An RFI may be fitting if there is a vendor that the buyer is unfamiliar with, or when there are several different ways to meet the buyer’s requirements. However, an RFI is not necessary if the buyer already has enough information about the prospective vendors to proceed with the RFP process.
What Is Included in an RFP?
The RFP should include all the instructions that vendors need to complete the RFP, as well as detailed questions the buyer needs answers for in order to compare vendors’ products and make an educated selection. As part of a complete RFP, specific contact information should be shared regarding whom to contact on either side for clarification. The table below outlines some common areas that may be included in an RFP.
Example Introductory RFP Sections – Created by the Buyer |
|
| Introduction Includes general RFP conditions or rules, timeline, and instructions for submission. |
The introductory section should include a project overview and a summary of the problem the buyer intends to solve. Buyers should allow vendors a minimum of four to six weeks to respond to allow adequate time to prepare a complete response.
The following dates should be included:
|
| Facility Profile Information about the buyer’s organization. |
Buyers should provide accurate information about their organizations so the vendor can target the appropriate products and prepare an accurate price quote. This includes demographics, practice, IT information, etc. |
| Current Environment | Buyers should provide detailed information about the current IT architecture to provide prospective vendors with the most information possible to complete a thorough response.
Provide information such as:
|
| Selection Criteria Process | Include a summation of the prioritization of criteria that defines how the selection will be made. |
Example RFP Response Sections – Completed by Prospective Vendors |
|
| Vendor Profile | This section requests company history, team organization, references, and the vendor’s financial overview or statement. It may include multiple pricing options, a risk analysis, projected milestones, and short- and long-term business plans. The vendor profile may help you determine how well you will be able to work cooperatively with each vendor under consideration. |
| Technical Environment | This section requests the vendor’s technical details associated with the proposed solution, including how the system will interact with the buyer’s existing network architecture (e.g., hardware, software, networking, interfaces, etc.). |
| System Implementation & Technical Support | This section requests detailed information about the vendor’s implementation plan, training, and ongoing technical support. |
| Specifications/Functional Questions | This section is typically the longest section and may be subdivided by groups or specialties. It includes detailed questions selected by the buyer that represent its needed system functionality. It should allow the vendor to explain how its system can meet the buyer’s requirements and show where there are gaps. |
| Proposed Solution Details & Cost Proposal | The RFP response should include a detailed summary of all aspects of the proposed solution (hardware, software, interfaces, training, implementation, support, etc.) along with the cost of each item. |
In addition, it may be of value to include an open-ended question, such as, “What attributes make your company an ideal partner for our organization?” This calls for a subjective response that may lend insight into the vendor’s values and priorities.1
Be Thorough, but Build in Room for Flexibility – A Word of Caution
Some believe that the RFP process is somewhat dated and can be so onerous as to bog down the decision, rather than facilitate it. In some cases, a buyer’s RFP may be lacking or incomplete due to the rigidity of the RFP process, where everything is expected to be defined right from the start. In reality, it is nearly impossible for the buyer to know all the requirements ahead of time. More likely, the buyer will learn more about its needs during the process, particularly in the implementation phase, as it gains a greater understanding of what the product can do versus the systems it used to have.2 The rigidity of the traditional RFP process does not easily handle this need for flexibility and can, in some cases, be the cause of project stumbles.2 In light of this concern, having a clause in the RFP that outlines how additional requirements can be added is a good plan.
Starting with a comprehensive needs assessment that translates into an accurate RFP can help alleviate misunderstandings; however, proper documentation of how disagreements should be resolved is also necessary to avoid disputes that can lead to litigation. Though it is sagacious to include protective clauses in the RFP, buyers should strive for a balance where the RFP does not become so onerous that the bidder struggles to complete a proper response. When an RFP includes rigid rules, the flexibility of both parties is limited.3 Logic lies with finding a balance between RFP language that protects you, yet still leaves room for discussion and negotiation. With no disrespect to the formality of the RFP process, having candid discussions and meetings with the vendors can help define some of the requirements that a buyer may miss. After all, you are looking for a partnership with some level of trust involved.
Evaluating RFP Responses
Prior to sending out RFPs, each buyer should establish its own criteria for evaluation and selection and set rules for disqualification. For example, some buyers place a higher value on cost while others may place a higher value on functionality. The RFP team can develop a Vendor/Supplier Evaluation and Assessment Form that includes a ranking of the value of each RFP category and each functional response, which yields overall scores that help compare vendors. The table below lists some items that buyers may choose to include on their evaluation scorecards.
Example Items to Include on Vendor Evaluation Forms |
|
May include: |
For example: |
| Needs assessment weights | Mandatory, critical, nice to have, etc. |
| Explanation of points assignment | 10 = Can fully meet or exceeds this requirement. |
| Percentages assigned to each of the evaluation criteria | Functionality is 40% of total. |
| Explanation to scorers about any calculations involved | Weighted total scores from each responder’s sheet for each category (row) are averaged. |
Post-RFP Activities
Once the RFP is delivered and responses are collected, buyers can begin to determine which vendor offers the “best fit” solution. Having agreed ahead of time on the evaluation criteria, the RFP team can use that criteria to review the responses and grade them accordingly. Vendors that do not meet minimum requirements can quickly be eliminated. Buyers should notify eliminated RFP responders and offer an explanation as to why they were not selected. This is important in case the winning proposal needs to be justified for any reason. In fact, RFP responses and evaluation forms should be saved for a minimum of six months in case the need arises to explain why a vendor was eliminated, or in case a vendor contests its loss of the project months later.4
Buyers should attempt to whittle the shortlist down to two or three vendors. Once the list is narrowed to those companies that are a potential fit, buyers should contact referencess and schedule live demonstrations and/or site visits. Assuming the RFP process helps the buyer find the top contenders, references, system demonstrations, and site visits help the buyer garner the information necessary to make a final decision.
With the amassed cumulative information and the evaluation criteria, the last step is to select a winner. Once the RFP team decides the winning vendor, the companies can develop and sign contractual proposals, and then begin the project.
Bottom Line: Do You Need an RFP?
Do you need an RFP? That is up to you and the rules at your facility. At some companies, the RFP process is mandatory. At others, it is a method to help systematically gather enough information from vendors to make a good decision, attempting to remove any bias. The RFP is meant to be a communication tool that helps clarify project/system requirements and allows buyers to make well-informed decisions about which product or system is the best fit. Buyers can use the f inal RFP as part of the contract or statement of work and refer to it in the case of questions during implementation. Although developing an RFP and an evaluation plan can be resource-intensive, for many businesses, the resulting information is well worth the effort, especially when a significant amount of capital investment is under consideration for a project or system. If you are considering an LIS, Orchard Software can guide you through the decision process and help you make the best choice for your laboratory.
Notes
- Tayntor CB. Successful Packaged Software Implementation. Boca Raton, FL: Taylor & Francis Group; 2006.
- Doig C. 12 ways to fix the traditional but broken software RFP selection process. CIO. https://www.cio.com/article/2929015/ enterprise-software/12-reasons-why-the-traditional-software-rfp-process-is-broken-and-how-to-fix-them.html. Published June 1, 2015. Accessed February 28, 2019.
- Grierson S. RFPs – A binding process or not? Lexology. https://www.lexology.com/library/detail.aspx?g=7df86021-93f3-4f72a718-05433b963170. Published December 17, 2012. Accessed February 28, 2019.
- Porter-Roth B. Introduction to writing RFPs. In Request for Proposal: A Guide to Effective RFP Development. 1st ed. Boston, MA: Addison-Wesley; 2001:1-36.
