I handle many Requests For Proposals (RFPs) from our customers. The RFP process was created as an equal-handed way to invite vendors to bid on sales opportunities. Unfortunately, many customers complain that the RFP process results in responses that vary widely, both in cost and features. The variance creates uncertainty about which responses truly satisfy the organization’s need.

Take a look at this list of responses from an RFP I recently handled. The list shows the price quote from each of thirteen vendors who responded to the RFP. This particular customer also ranked each proposal by how well the proposed solution conformed to the requirements. Notice how the solution ranked second was more than twice the cost of the number one ranked proposal.

Here are the main reasons why proposals vary so widely:

  • The RFP doesn’t describe the existing infrastructure
    • A well designed solution should leverage the existing investment
    • Except for a few exceptions, no opportunity is truly greenfield
  • The RFP doesn’t describe how much of the existing infrastructure is available for the requested solution
    • More infrastructure may be needed but it’s impossible to tell without understanding what’s available.
    • Software licensing is an important example because many organizations have bundled licensing agreements governing significant technologies that have not yet been deployed.
  • The RFP states a mishmash of requirements that no single solution could possibly possess
    • The RFP is a useful tool for an organization to articulate business requirements. However, because no one solution can do everything, no vendor can respond with a fully compliant proposal.
    • The RFP states requirements but never explains the problem to be solved.

If you talk privately to sales engineers like myself, you’ll quickly learn that responding to RFPs is not a fun job. We jokingly say that RFP is a four letter word. Why are RFPs so troublesome? Because the reasons above make it nearly impossible to propose a solution that’s the right fit with the least cost. Regrettably, great fit and low cost is exactly what organizations want in the response.

      An organization states that the solution must be Highly Available (HA).
      Easy enough. Unfortunately, an HA solution requires all components to be duplicated across the entire system. This has enormous cost ramifications. Many solutions have data center resilient options that provide almost the same reliability as an HA solution for a fraction of the cost and complexity. HA sounds great until you look at the price tag. Does the business problem require true HA? Maybe. But a great deal of money will be wasted if not.

Invariably , customers extend the deadline after the RFP question & answer period. This is because the responding vendors raise issues that the customer had not previously considered. The new information sparks debate that leads to new understanding of the desired requirements.

The customer then posts a revised RFP. Oftentimes the revised RFP is drastically different than the original, requiring extensive rework for vendors to come up with new designs. The question and answer cycle is sometimes repeated, creating more churn. This happens because the customer is discovering what’s actually needed. That’s understandable and a good thing, but it’s an inefficient process. What can organizations do differently?

Start with a Request For Information (RFI)

An RFI serves two important purposes:

  1. An RFI allows you to describe your existing environment, including the available capacity.
  2. An RFI allows you to express requirements in problem terms, not solution terms.

The concept of problem terms is important because it allows the vendors to understand what you want the solution to do. It allows a vendor to offer a solution you haven’t thought of or weren’t aware of. The idea is to describe business problems instead of jumping straight to requirements. Your vendor knows about many solutions for your problem. But if you state a fixed requirement, you may miss alternative technologies that are less expensive or a better fit for your organization.

At CDW, we pride ourselves on our ability to translate business needs into a solution. For me personally, it’s a point of professional distinction I work hard to maintain. The traditional RFP process prevents that value-add from coming through.

    An organization publishes an RFP for a new phone system for 1,000 users. It would seem reasonable to state a requirement to include 1,000 phones. Phones are usually the most significant cost of a new phone system.
    Interestingly, with advancements in unified communications, many organizations have abandoned the idea that everyone needs a phone. Many information workers prefer a softphone with an inexpensive headset. Mobile workers prefer to use their cell phones but need enterprise features. Additionally, some organizations are extending the bring-your-own-device (BYOD) model to headsets. Employees purchase their own headset, just like a PC or cell phone in the BYOD model. The resulting unified communications solution can be dramatically less expensive than a traditional phone system and provide powerful features for collaboration and mobile communications.

When your vendor responds to the RFI, you will learn about different technology options. Each vendor will communicate why they think their solution is best for you. Each vendor response will be quick because the vendor does not have to design the solution or quote pricing—at this stage, anyway. These are time consuming tasks for the vendor to perform. Vendors don’t want to perform these tasks unless they know they have a good chance of winning your business. In the table above, a dozen vendors spent time and effort without compensation! Bear in mind, all vendors must and will recoup the sales engineering expense on future bids resulting in higher cost for all solutions, industry wide.

The RFP is Next

From the data in the RFI responses, you can pull information from the ones that satisfy your needs best. It’s likely that the vendors you select have proposals that are very similar in terms of technology and features. You can now draft the RFP with confidence. You can describe the requirements in solution terms by using the same descriptions in the RFI responses. You can use precise terms for requirements, like High Availability or Data Center Resilience, knowing the subtle differences in performance or user experience.

When the vendors receive the RFP they then have the necessary information to design the solution to meet your requirements. Many vendors will drop out of the process because it will be clear the RFP is not favoring their solution. One important point: don’t ask for price quotes in the RFP, simply ask for estimates. The final step in the process will explain why.

The final step is the Request for Quote (RFQ)

When you receive the estimates from all the vendors in the RFP responses, you can select the vendor with the best solution and best estimated price. To this vendor, you send the RFQ on the basis that they can actually quote a price very close to their estimate. The RFQ isn’t really a document at all, just an invitation to produce a firm quote. By postponing the quoting process until the very end you allow the vendor to secure special pricing, discounts and promotions on your behalf. The smart vendors will have taken the discounts into account in their RFI estimate. It’s a gamble to win your business but all vendors will try to keep the estimates as low as possible.

This is another reason why traditional RFP responses vary so widely. One of the vendors will secure preferential pricing or register the opportunity with the manufacturer, but from the RFP responses, you can’t easily tell which one. It’s even more difficult with solutions involving multiple manufacturers because the special discounts from all solution components will be distributed across many RFP responses. You will maximize the discounts by selecting only one vendor to quote. In the traditional RFP process, the winning vendor may try to go back to the manufacturers for the discounts but you already agreed to pay the higher price. You may never see the discounts intended for you.

If the quote comes back significantly higher than the estimate, select the next most favorable vendor and send an RFQ. Although, before you do that, you might want to inform the first vendor. You may be surprised how quickly you get a revised quote, amazingly close to the estimate. This vendor has a lot invested at this stage.

The RFI/RFP/RFQ process puts CDW in the strongest position to be your trusted partner.

  • Enables CDW to design a solution that is right for your organization
  • Allows CDW to propose the most cost competitive solution
  • Reduces your time and frustration dealing with complex solution responses
  • Eliminates wasted time and effort for vendors responding to RFPs (when there’s a small chance of success), reducing the sales engineering expense overall and thereby reducing the cost of all solutions

Having one trusted vendor partner is by far the most efficient way to get the best solution at the best price. However, if you absolutely must use a multi-bid system (if required by law or shopping for a new trusted partner), I hope you’ll consider the RFI/RFP/RFQ process.

Since I’m a sales engineer, this advice may come across as self-serving. It’s true, it makes my life much easier. (If you adopt the RFI/RFP/RFQ process, let me thank you right now!) But you have everything to gain as well. Everyone wins. I hope this process will bring you the best solutions at the best prices.

4 thoughts on “RFP is a Four Letter Word

  • Paul Friedman says:

    Andrew…I could not agree with you more. My experience has been that we have won more RFPs after an RFI was done than if one was not up front.

    The RFI process allows the vendor to truly place themselves into a position of consultant rather than just sales and see how to provide the best solution not just a flat response to a blind request that may not fit the true customer needs.

    We sell a great deal into the MSFT Lync environment and I have seen many more RFIs for those and won more deals as a result with our SmartTAP Recording Solution for Lync voice.

    Well done. Thanks.

    Paul Friedman
    Global Director, SmartTAP

    • Rupert Clayton says:

      Andrew: Thanks for your insights on the RFI/RFP/RFQ process. I have been involved with a couple of RFPs recently where we ultimately decided not to bid to provide the solution requested. I saw these customers make several of the mistakes you highlight here. In particular, the customers:

      * Did not issue an RFI, so they entered the RFP process informed only by their own solution vision and not by that of potential vendors.
      * Set an unreasonably short period before the deadline for questions was due. In one case, this was 5 working days from the issue date. In another, the deadline had expired before the RFP made it to my Inbox.
      * Mandated specific technical features that greatly constrained the technical solution, without making clear why these features were required. In the regular process of developing a non-RFP customer solution, these requirements could be discussed openly, and vendors would know how to prioritize specific functionality. RFPs close down that discussion.
      * Listed a grab-bag of nice-to-have items (high availability, unlimited user licensing, unlimited archiving, etc.) as requirements, requiring an expensive solution that didn’t fit well with the customer’s budget or true needs. In fact, this customer appeared to need HA only for certain functions, limited archiving, and the ability to scale to many users, without licensing all of them from day one.
      * Zero or limited detail on what kind of migration and integration work is required from the vendor. No solution is implemented in a vacuum. If you want to replace your phone, e-mail or collaboration environment, what kind of transition will meet your needs with an acceptable level of risk? Your vendor needs to know this.

      I do understand the value of RFPs in securing a transparent process without favor to any particular vendor, and in forcing vendors to commit to their best price, but when poorly implemented they often result in the customer missing out on the most appropriate and best value solution for their needs. Adding in RFIs and RFQs brings back the customer-vendor dialog that makes it possible to get a better-designed solution that really addresses the customer’s requirements.

      • Andrew Hunkins says:

        Thanks, Rupert!

        Yes, the feedback loop is critical. It is true that the traditional RFP process is used to keep any single vendor form having an advantage by conducting more communication than another. That’s why I like the RFI/RFP/RFQ process because it includes a feedback loop but in an even-handed fashion.

        I agree with you completely.

    • Andrew Hunkins says:

      Thanks, Paul!

      Our customers love SmartTAP. And it’s a perfect example. Call recording will often appear as a single bullet item in a 200-page RFP. Call recording is a complex application in its own right with many options and architecture choices. Another example why engaging a CDW Solution Architect is a great place to start.

Comments are closed.