Most people who require or provide resources or services are familiar with an RFx document – a “Request For…” document where “x” stands for either Information (“RFI”), Proposal (“RFP”) or Quote (“RFQ”).
These may seem interchangeable and the differences may not be obvious, so here’s a quick overview of each.
Request for Information (RFI)
An RFI is generally used when the solution to a business problem is not immediately evident or clearly defined. The RFI is used to gather information, NOT to make a selection or an award, so pricing is not typically sought in the RFI. As the name suggests, it is an inquisition sent to a wide range of potential vendors/suppliers in order to gather information to develop a strategy that will make a foundation for an RFQ and RFP. It also serves to qualify vendors/suppliers for participation in the sourcing process.
Request for Proposal (RFP)
Similar to an RFI, RFPs are sent to potential suppliers and should identify your short/long-term business objectives and describe in detail the specification of your intended purchase or request. An RFP may leave some of the precise structure and format of the response to the discretion of the vendors/suppliers – how they choose to structure their proposals can help to distinguish (and elevate) one from the others.
It is typically used to short list vendors/suppliers for further rounds of quotation or face to face negotiations. Price is usually not the only factor in the evaluation of an RFP - quality, service, and reputation are usually also taken into consideration.
Request for Quote (RFQ)
An RFQ is generally used to obtain pricing, delivery/implementation information and define specific business terms and conditions. In this case, requestors typically have a clear understanding of what they need, including requirements and specifications.
Often the quotes are used as the basis of vendor/supplier selection, but you can also short list vendors for a final round of negotiation.
Although these are universally used in resource/service requests (not just SAM!), I still hear complaints about them from both clients and service/resource providers – and often for the same reasons!
The biggest complaint on the customer/requestor side is that vendors do not follow the guidelines and don’t provide what is asked – and from the vendor perspective, the complaint is that they are poorly constructed, ambiguous, complicated and no two are the same!
So what can be done to improve them for all involved? Here are some recommendations when constructing your RFx documents which should make responding to them easier, making both customers and vendors happier.
#1 Editable documents
Customers want to make sure none of the requirements are modified and often produce their RFx documents in PDF or some other non-editable form. From a vendor perspective however, this means that documents have to be printed, modified manually and then scanned back in again which takes significantly longer to complete and introduces risk of mistakes or omissions. If there is a concern about editing requirements, keep the PDFs, but provide a Word or spreadsheet format as well that will simplify the response effort.
#2 Separate Requirements from Reference Materials
For convenience and to simplify distribution, we often see the RFx document crafted as a single document – however, scrolling through pages of regulations and business terms to find the sections that require a response or a signature can be time-consuming and increase the risk of items being missed.
#3 Sufficient Space for Answers
As the customer and creator of the RFx document it is important to decide how you want to capture the information from the vendor. While it seems easier to provide a list of questions/requirements together, it can be challenging to locate and map responses to questions on separate pages etc. – so give consideration to providing space after each question for the response to be entered.
#4 Time for Response
As the customer and creator of the RFx document there is usually an event driving the requirements like a true-up or contract renewal – and this often leads to a desire for a quick response and a short timeline. However, vendors may struggle to finish and provide a complete response in less than 3 weeks.
As straightforward and obvious as the RFx may seem to the customer creating it, quite often from the vendor’s perspective there are ambiguities in the wording or gaps in the information relevant to the sizing of the project etc. While it may extend the timeline for selecting a vendor/solution, it can be mutually beneficial to include an opportunity for vendors to submit questions to help them produce estimates and responses that better meet the specified requirements.
So those are my tips for better RFx documents. Do you have any other tips for creating a new RFx document – or any examples of things to avoid?
Subscribe to Email Updates
- Savings vs Cost Avoidance – What’s the Difference?
- A Successful Deployment of the IBM License Metric Tool Isn’t Free
- A Big Data Analytics Methodology
- Your SAM Project’s Internal Rate of Return
- Indirect Usage – It’s not just SAP
- Deploying ILMT: Do You Have What It Takes? - Part II
- ITAM Repository or CMDB?
- Interpreting ILMT “All IBM Metrics” Audit Snapshot Report
- Deploying ILMT: Do You Have What It Takes? - Part I
- What’s So Great About the Gartner IT Asset Management Summit?