This chapter is from the book
This chapter is from the book
This chapter is from the book
Different Types of RFPs
To enable suppliers to offer their best solutions, an RFP must represent a clear understanding of all the technical issues (technical section), must provide a method for implementing and managing those issues (management section), and must provide the supplier with an acceptable method for doing business (contracts and price section). Many RFPs are not successful because they fail to communicate one or more of the above requirements properly.
NOTE
The type of RFP used depends on your understanding of the technology.
Buyers often find new products and technologies hard to understand. Typically, the RFP team will read white papers, brochures, and datasheets; attend conferences and demonstrations; and invite the supplier to give a presentation or demonstration. Even with all of this research, the RFP team may still not fully understand how the technology will fit and work within their project. When more information is needed than is publicly available, the RFP team may use a "pre-RFP" request for information (RFI).
Request for Information (RFI)
An RFI is a way for buyers to determine what is available from suppliers who respond to its requirements. It is also a way for the buyer to determine whether the requested requirements are reasonable and whether appropriate technology is available. Suppliers are encouraged to respond to the requirements and also to spell out where there may be potential problems, areas in which technology may not exist, or unrealistic project goals and schedules. The information gleaned from proposals may help guide the subsequent RFP or cause it to be canceled if suppliers do not respond.
An RFI is not a mandatory prerequisite to writing an RFP; many companies write RFPs without going through the RFI stage. RFIs may be considered when the goals of the project are in question or when the technology for the project is new to the industry or your company—or when you would like to explore a variety of potential solutions.
Figure 1.2 shows that an RFP is dependent on both the team's education concerning suppliers and on the available products and suppliers' responses to the RFI. Responses to the RFI may show that (1) the technology mandated by the requirements is not available, (2) the technology is available but far more costly than originally anticipated, or (3) suppliers do not understand the RFI requirements. If the suppliers are not responsive, it could mean either going back to the requirements analysis phase or stopping further work on the project.
){kind=link}
If suppliers' proposals are responsive to an RFI, the requirements are first reviewed according to the information gained by reading these proposals. These requirements then become part of the RFP, and finally the RFP is developed and released.
Figure 1.2 RFI/RFP Development Cycle
NOTE
Use RFIs when you need to validate technology and requirements.
Typically, an RFI encompasses all of the requirements and is structured just like an RFP. It is important to list not only the technical issues but also the requirements for project management, maintenance, training, and support. Thus, potential suppliers are allowed to comment on all aspects of the procurement and to establish what is possible and not possible—from their point of view. Of course, the RFP team will have to separate the wheat from the chaff—since suppliers may try to say that technology other than their own does not exist. (However, it is important not to combine competing technologies within a single requirement when rewriting requirements based on multiple suppliers' proposals.)
The following paragraphs were taken directly from an RFI:
[Our company] is in the process of researching corporate Intranet technology and systems that will support our internal Intranet, public site, and an extranet for . . . . The objective of this RFI is to obtain information about systems that are available from suppliers.
It must be clearly understood that this RFI is being used as a vehicle to obtain information about Intranet technologies and potential system suppliers. This RFI should not be interpreted as a contract (implicit, explicit, or implied), nor does it imply any form of an agreement to candidate suppliers. In addition, no inference should be made that we will purchase and/or implement in the future any of the technology or systems proposed by the suppliers responding to this RFI.
We will, however, use responses to this RFI to build and fine-tune our RFP.
In this case the buyer is making it very clear that the purpose of the RFI is to gain an understanding of a specific technology and to develop a list of the potential suppliers.
Why would a supplier respond to this type of request when there may be many other RFPs in the hopper? One reason is that an RFI gives them a chance to participate in the early planning stages of a project and to try to influence the RFP's strategy and direction. It allows suppliers to provide information about their products so that the RFP team members are better informed by the time they release an RFP. Also, many companies send the subsequent RFP only to those suppliers who responded to the RFI. Therefore, the RFI becomes an important tool for determining who should be on the bidders' list for the RFP.
NOTE
An RFI should not be a fishing expedition.
A note of caution: If an RFI is poorly put together, has little focus, and demonstrates a fundamentally poor grasp of the technology, many suppliers will respond with datasheets and boilerplate text, or else not at all. Many potential RFPs are not released after an RFI, because the RFP team has severely misjudged the technology, the implementation, and the cost. Suppliers are quick to grasp which projects are likely to move forward and which appear to be misguided "fishing expeditions."
On the other hand, an RFI is the best place for a supplier to try to influence the requirements and therefore have the inside track if and when the RFP is released. As an old supplier proverb goes, "If you didn't help write the RFI, don't bother with the RFP." So, in the spirit of team education, let suppliers provide you with as much information, help, support, and interaction as appropriate to your needs.
Request for Proposal (RFP)
An RFP is a formal request for proposals from suppliers, and such proposals often become part of the resulting contract. An RFP may be the result of an RFI that tested the technical waters, or it may be written based on current knowledge of products and suppliers.
The following is taken from the Proposal Preparation Instructions of an RFP:
[This company] reserves the right to award the contract according to the evaluation criteria. . . . The supplier chosen for award should be prepared to have the proposal incorporated, along with all other written correspondence concerning this RFP, into the contract. Any false or misleading statements found in the proposal will be grounds for disqualification.
NOTE
RFPs becomes the basis for the contract.
Unlike an RFI, in which the RFP team is still fact-finding, the RFP represents a decision to buy technology or services. Proposals submitted in response to an RFP are incorporated into the contract as an addendum or exhibit. This procedure allows the company to obligate the supplier contractually to comply with statements made in the proposal, and to seek legal recourse if the supplier cannot meet the requirements as stated.
An RFP represents a significant opportunity for suppliers to sell their products, systems, or services:
It provides a platform for describing and promoting products.
It allows suppliers a chance to interact with the buyer organization.
It demonstrates a buyer's commitment to the project and indicates that funding is available.
In summary, we can say that an RFP is a written document that represents a certain amount of time, resources, and money in order to communicate an understanding of the business needs of a company. Resulting proposals represent an interpretation of those needs and involve the expenditure of a commensurate amount of time and resources on the supplier's part.