Why Use the RFP Process? Because It Works!
Recently, I participated in an online discussion about the Request for Proposal (RFP) process. It was similar to the conversations I have with clients when we recommend using an RFP to select a new vendor for equipment, software or services. In both cases, the argument revolves around whether the results justify the hard work and time required.
To be clear, a well-executed RFP requires substantial effort. At a high level, the process includes the following steps:
- Conduct research
- Hold meetings inside and outside your company
- Assemble an RFP team
- Draft and publish the RFP
- Conduct vendor reviews
- Call references
- Compare the bids
- Award the bid
- Receive and accept the equipment or service
For many projects, it may take between three and six months just to get through the first eight steps. The schedule can be impacted by competing priorities, the need for site visits and addressing concerns raised by senior management. Considering contracts generally average about five years, the investment up front pays dividends.
The Arguments Against RFPs — and Responses to Each
The number one argument against RFPs is that they’re just a mechanism to get to the lowest possible price. From this point of view, the questions, scoring and presentations are merely smokescreens. The process is being followed because it’s mandated, but at the end of the day, the lowest price wins.
If the company’s goal is just to “race to the bottom” with pricing, then I agree, don’t waste your time with an RFP. Use a reverse-auction instead. This commoditizes whatever you’re buying, and removes the need for any in-depth analysis. Beware, you get what you pay for.
The goal of the RFP is not to get the lowest possible price, but the best possible price for the best solution for your company. Through the process, you’ll discover which vendors are able to meet the technical, service and support requirements for your project. Sometimes, the lowest priced vendor will be able to provide the right solution, but not every time.
Which leads to the second most common objection: the buyer has already selected the vendor and is only going through the motions. Vendors may complain that the RFP was written in such a way that only one company can meet the requirements. In other words, “the fix is in.”
This complaint often has some merit. During the research phase, a buyer may have received a lot of good information from one supplier. They may even have been given a list of requirements to include in the RFP. Unless they include additional prerequisites, then the document is probably skewed in favor of the “helpful” supplier.
This underscores the importance of getting information from more than one source — other people in your own company, peers in the industry, consultants and multiple vendors. Taking the time to perform research will result in a better RFP — for the vendors and for your in-plant.
The last dispute to overcome is that an RFP restricts the opportunity for vendors to promote the best solution to your problem. The strict requirements might limit the responses to a specific product or service. In some cases, the buyer may have asked the questions in such a way that the seller is forced to quote a hammer; however, the customer could be better served with the purchase of a screwdriver.
There are two ways to avoid this problem. The first is to eliminate overly precise requirements for the solution. Clearly spell out minimum standards for information technology, security and response times. But don’t include machine speeds, process rules or similar specifications. Ask questions to find out solutions, not limit responses.
Which leads to the second method: include a section for alternative solutions. The language is very simple: “Based on the intent of this RFP, please recommend any other (products, software, service, etc.) that will help (your organization) meet our objective.” Smart vendors will seize upon this opportunity.
Lessons from Success
A common saying is that “We need to learn from our mistakes.” That’s true, however we should also learn from our successes. When something works well, we should try to replicate that accomplishment. Our most successful RFPs have had 3 elements in common: a solid RFP team, a culture of promoting diverse points of view and keeping costs analytics separate.
The importance of having a good team of people working on the RFP can’t be understated. Depending on the policies of your company, procurement may take the lead role on the project. If equipment or computers are involved, get people from facilities management and information technology on the team. You should also invite the key internal customers impacted by this project, including customer service, sales, marketing and the business units.
The team members need to know that their opinions are valued. Feedback and scoring systems need to collect the information so everyone can provide input. During team meetings, the facilitator must ensure that all members have the opportunity to express their points of view.
When scoring an RFP, the grading and the financial comparisons should be done separately. Before sending the responses out to the team, remove the pricing data. This safeguards against people’s opinions being impacted by a lower bid.
At times, the RFP process may seem long and tedious. By creating an RFP team and following the process, you’ll increase your chances of success when purchasing equipment, software and services.
When done correctly, it works.
This article originally appeared in Mailing Systems Technology magazine.
Mark M. Fallon is president and CEO of The Berkshire Company, a consulting firm specializing in mail and document processing strategies. The company develops customized solutions integrating proven management concepts with emerging technologies to achieve total process management. He offers a vision of the document that integrates technology, data quality, process integrity, and electronic delivery. His successes are based upon using leadership to implement innovative solutions in the document process. You can contact Mark at email@example.com.