08 Jun How to Simplify the Most Difficult Part of an RFP
Introduction
Organizations are always in need of services that they cannot perform themselves. The usual vehicle to obtain these services is a Request for Proposal (RFP). The RFP is a document that outlines what the client needs and the process they will take to identify who will be selected to provide this service. The RFP is also an invitation to bid for vendors who believe they can meet the needs of the client.
For straight-forward services where the client knows what they want, making an RFP is a simple process that can be done in the matter of days (an average of 30-60 days). However, for more complex services in which the client’s scope is not as defined, it could take years to finalize an RFP (average 1-2 years).
The question that is always asked is what should go in an RFP? How much and what kind of information should go in an RFP?
Parts of an RFP
In general, RFPs are really simple. There are only 3 major parts of an RFP:
- Scope of Work (SOW) – Explanation of the service being requested and the requirements and specifications.
- Explanation of the selection process – Explanation of the schedule, steps that you will go through, and methodology for determining which vendor will be selected.
- Legal Clauses – Verbiage in the RFP that are written to assign accountability.
An introduction and overview of the client is also included and the client can add another section of appendices and attachments—this section contains any additional information and forms the client wants vendors to fill out.
Most organizations have an existing RFP template. Thus, the explanation of the selection process and legal clauses are already determined and written out, leaving only minor adjustments and the new SOW. If there is no RFP template, it might take you a little longer to make an RFP, but after the first one, you will be able to reuse it and just adjust the SOW for the next RFP.
This means the most difficult part of an RFP is defining the SOW.
Most Difficult Part in Making an RFP
Traditionally, when creating an RFP, the scope of work is key to ensuring a high performing service. The difficult part of creating a SOW is that usually if you are purchasing a service, you are not an expert in the service, so defining the right requirements is not an easy task. Usually, the subject matter expert in a company creates the majority of the SOW, but in some cases the procurement officer who has no experience in the service is expected to make the SOW. For this reason, the request for information (RFI) process was created to give clients a way to get advice from expert vendors to get help in creating the RFP. However, the RFI could make the process even more confusing if the client gets conflicting information from multiple vendors.
To ease the process of creating a SOW for a project, clients will often hire a consultant to help with the requirements and specifications for the service. This increases the cost as well as the time to outsource the service. This also does not guarantee that the specifications and requirements of the SOW will be what the client actually needs.
I once assisted on a procurement process for the State of Oklahoma. One of their agencies needed a computer-to-plate machine (a type of advanced printer). They had spent more than a year determining what the requirements for the machine in the RFP. When the vendors submitted their bids, every vendor was overpriced, except for one. The client couldn’t figure out why everyone was charging so much for the machine until finally they interviewed the lowest-priced vendor. The vendor’s manager let us know that the required specification in the RFP was more than what the agency actually needed for their printing needs. The client couldn’t believe it was wrong, but when they verified it, the vendor was right. The specification was way too high, and it was driving up the cost. Luckily, the vendor knew it was way too high, and submitted a bid for the type of machine that the client needed. And due to using the Best Value Approach (BVA), it gave the client flexibility to select the vendor instead of having to go through the entire process again with no risk of protest.
In the end, the SOW is difficult to define because the client is not an expert at the service. This is the only reason why a client would have to outsource a service in the first place.
Simplifying the Scope of Work and Requirements
Although defining the SOW can be a difficult process, it’s very easy to simplify with some minor changes. However, there is only one procurement and delivery system that is capable of doing this well, the Best Value Approach. The BVA makes it easier to define the SOW because it shifts the responsibility of making the SOW and requirements from the client to the vendor. The BVA is called a vendor centric model because shifts all responsibility on the vendors to use their expertise on shaping a service or project.
The process for this is simple:
- When an organization sees that they have a need, they write down their perception of what they think they need instead of creating a detailed list of requirements in their SOW.
- The client then collects simple metrics to describe their current situation (what they have right now). If they don’t know what they have, or it will take a lot of time to figure it out, then they do their best to estimate (and they explain it’s an estimation in the RFP).
- The client then puts what they have in the RFP and lets the vendors know that whoever is selected will create the actual SOW and all the requirements for it. This is all completed before the contract is signed.
Examples of Simplifying a Scope of Work
Let me give you some examples of what this might look like and on what types of services it has already been performed on. First, the type of services it has been performed on is across the spectrum—from commodities to food services to information technology. It has been tested on roofing and construction and also on health insurance.
Here is an example of a traditional roofing projection process:
- Determine what type of roofing system they would need.
- Employ an engineer or architect to create a schematic of the roof.
- Have the engineer identify exact requirements and specifications for the materials that will be installed and how the roof will be installed.
To do this might require an additional procurement process to hire an engineering/design firm. The BVA simplifies the SOW process by:
- Identifying the current specifications: square footage of the roof, the type of roof, the budget, and any unique conditions or constraints.
- Put this in the RFP and let the vendors identify which roof would be the best of the client.
The BVA method doesn’t require a consultant, designer or engineer. Only minimal information is needed to write the SOW.
In some cases, a client might have a complete set of design drawings or specification—they can always share it with the vendors in the RFP. However, the key is to make sure that vendors know it is their responsibility to define the final requirements/parameters.
Performance of RFPs that have Simplified the Scope of Work
I recognize this is a very different process than the traditional way of creating a SOW. Some clients believe this way is too risky and allows the vendor to take advantage of the client. Many people question how whether the client can choose the best vendor. I understand the concerns, but the BVA process has taken all of this into account and has a foolproof process to ensure the client gets a high performing service, while having a really simple way to create an RFP. The documented performance of projects that have done this is as follows:
- City of Rochester: Mayo Civic Center construction of a facility addition. The value of the project was $67M. The process provided a contractor $5M lower than the competition. The project finished on time and 1% overbudget; the client was responsible for adding 3% to the budget while the vendor saved -2% for the client.
- ASU IT Networking Services: The value of the contract was $12.29M. Unable to develop an RFP through the traditional process, ASU used the BVA process to identify an expert vendor. The annual cost of services was reduced from $12.29M to $9.83M. While the quality improved increasing wireless connections from 9% to 93%, 1GB connections increasing from 57% to 96%, and an IT spending ratio of 6% spent on new equipment to 56% spent on new equipment with the remaining spent on maintenance.
- The Dutch Ministry of Infrastructure road widening project: The ministry piloted the BVA with 16 projects totaling $1B which traditionally took 12 years to procure and execute. Within one year, 15 projects were finished. The delivery time of projects accelerated by 25% while transaction costs and time was reduced by 50-60% for both vendors and client. The projects were award the Dutch Sourcing Awarded in both the public and private sector.
- Arizona Department of Environmental Quality (ADEQ): The Waste Program Division (largest division) replaced their traditional approach of procuring and managing projects with the BVA. They tested out the BVA on an environmental contract responsible for hiring expert vendors to identify, assess and clean up soil/groundwater/surface water for 54 sites. The process was able to cut the procurement time from 286 hours to 13 hours (savings of $95k), identified 10+ expert vendors who delivered 195 projects on time and on budget over three years with an increased satisfaction rate of 8.7/10 from 6.9/10 at its start.
Do you have a project you need help on?
If you are looking to procure a service, but you are unsure of the requirements or unsure of what type of service you need—please see additional resources below.
- Email us with questions: josephkashiwagi@ksm-inc.com
- Dr. Dean’s research group PBSRG: www.pbsrg.com
- For latest books, events, and licensed partners: www.pbsrg.com/courses-2/
- Latest BVA journal publications: www.cibw117.org/
- Annual Best Value Conference in January https://bestvalueconference.ksm-inc.com/
- Latest presentations and videos: https://www.youtube.com/channel/UCxBi26nXLDTqG4ZRV6p0iiQ