RFI and RFQ for an RFP

An activity sequencing diagram showing an RFI prior to an RFP prior to a contractI was consulting with a large government entity to develop a Request for Proposals (RFP) to replace its mission critical system. Besides getting the RFP out to bidders as soon as possible, the funding agencies needed a solid project budget estimate for their own projections. However, we were unenviably stuck in the proverbial time crunch with little time to waste.

The organization’s CIO had been researching technological advances and sustainable solutions that could possibly fit with his strategic direction. The Project Director was not well-versed in what solutions might already exist in the market, and was open to exploring anything that was feasible. My domain knowledge and experience made me familiar with what was currently in production in similar jurisdictions, but I was skeptical as to whether any of those solutions would provide the sustainability that my client required. Clearly we needed more definitive direction before we could prudently proceed with a multi-million dollar procurement.

We determined that before we poured time and effort into developing the RFP we would issue a Request for Information (RFI) combined with a Request for Quotation (RFQ). This approach had numerous advantages, and it appeared that the only disadvantage was that it would add several months to our procurement timeline. However, better to add those few extra months at the beginning and establish the project on a solid footing than to issue an RFP that could potentially result in an inadequate solution costing the taxpayers millions of dollars.

The combined RFI/RFQ was an immense benefit, not only in establishing a direction for the project and the eventual solution, but also in helping us to develop a project budget that we could be comfortable in presenting to the funding agencies.

In the RFI/RFQ, vendors were assured that their responses would be confidential, their competitors would not even be aware that they had responded, they would not be held to their responses (should they offer a different solution to the forthcoming RFP), and they would not be held to their pricing estimates. At the same time, vendors understood that assisting us with this request would be in their favor should we issue an RFP that incorporated their ideas.

We asked for information along the following lines:

  • The vendors’ recent experiences with implementing systems in this domain or similar domains. This helped ensure that the responses we received were from knowledgeable IT providers with recent successes in our marketplace or similar marketplaces. It also deterred firms with insufficient experience from spending a lot of time in preparing responses that our team would need to review. The responses to the RFI/RFQ informed our team as to the caliber of potential bidders in the IT provider community.
  • The vendors’ high-level solutions to our initial set of requirements. This helped us understand how our business requirements could be automated with emerging technology. We received very creative responses, sometimes optional solutions, that helped us formulate an overall solution strategy. Though the responses were varied, we were able to glean what was workable and what aspects of the various solutions could fit with our organization’s strategic technological direction.
  • The vendors’ suggested activities and timeline for executing the overall project based on the ideas presented in the RFI/RFQ. This helped us determine the project timelines that we would issue in the RFP, and helped us develop a project budget for additional expenses such as end-user staff to be provided, required facilities and equipment, support staff, and other non-vendor related costs.
  • The vendors’ approaches to non-technological processes such as requirements gathering, quality assurance, user acceptance testing, end-user training, and implementation methodology. These and other such processes would involve staff that our organization would need to provide to the project. The vendors’ responses helped us plan the level and number of resources that we would require, activities to prepare our staff to work alongside the IT vendor’s staff, and methods for backfilling and rotating our staff through training and implementation activities.
  • Information that the vendors would like us to include in the RFP to help them respond with more concrete proposals. This helped us to understand what information the bidders relied on to formulate their responses, and what constraints or terms and conditions made it more difficult to for them to bid on procurements such as ours.
  • High-level quote or a price range for the options presented in their responses. This helped our team to quickly understand the magnitude of the work we were asking the IT vendors to provide, and therefore informed us as to what project requirements we needed to prioritize and include in the RFP to stay within the organization’s funding constraints.

In actuality, adding the extra time for the RFI/RFQ process helped shortcut the overall procurement process, as much of the information we needed to research was provided by the vendor community. Using the information gleaned from several vendors’ responses, we issued a competitive RFP, providing opportunity for qualified bidders to respond, regardless of the nature of their initial responses to the RFI/RFQ (or whether they had even responded to it). These initial responses informed our procurement team of technological advances that would benefit our new system implementation, of creative solutions for various aspects of our business requirements, of areas where we could eliminate rigid procurement terms to allow more flexibility in pricing, and of the likely cost of the project.

Get Your Free Guidebook

Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.