To RFP or not to RFP

To RFP or Not to RFP, That IS the Question

I recently had an interesting discussion on LinkedIn with a consultant (whom we will name “C”) in the Strategic Workforce Planning and Analytics space. "C" had posted an article about effective ways to navigate a Request for Proposal (RFP) process to select a vendor. Based on prior experience, my kneejerk reaction was to comment on how expensive and unproductive the whole RFP process can be, and how organizations in their right collective mind should avoid RFPs at all costs (pun intended). This, in turn, elicited an equally quick and forceful response from "C" that RFPs don’t have to be costly or unproductive (presumably, in part because some of "C"’s income comes from advising clients on how to conduct an RFP process!).

This got me thinking, and I decided to do some research, interview some clients, and look at creative ways to evaluate the pros and cons of RFPs. I have summarized my findings here, which ultimately led to a viable and superior alternative for potential clients.

Traditionally, organizations have chosen to undertake a formal RFP process in order to evaluate and select different vendors, suppliers, technologies, etc. Proponents of the RFP process hail it as a way to reduce risk in the selection process, a way to guarantee transparency, and an effective way of compiling a comprehensive list of functional requirements for the solution.

If done well, the RFP process should achieve the objectives mentioned above and, more importantly, should be able to highlight the uniqueness of each vendor’s approach, its alignment with internal processes, as well as any potential advantages and disadvantages of selecting one solution versus another. “If…done…well…” This is the key.

So let’s try to provide a list of attributes that a good RFP process must have. This is by no means a comprehensive list, but attempts to hit on some key success factors:

1. A well written RFP, which contains clear and adequate descriptions of functional requirements for solution quality and cost estimation purposes.
2. A carefully selected RFP team, with the cross-functional skills necessary to evaluate RFP responses on a functional and financial level, as well as on other aspects that may be necessary (i.e., IT security, systems integration, etc.)
3. Management support and commitment into the RFP process and its outcome.
4. A well-crafted RFP evaluation and scoring system.
5. A knowledgeable point-of-contact person (ideally, a future “user” or direct consumer of the solution within the organization) for interested vendors to direct questions during the RFP process.
6. A post-selection evaluation system to track the success of the selected vendor’s solution based on pre-specified milestones and goals.

For the sake of simplicity, let’s assume that management support and commitment have been secured, an acceptable RFP scoring system is in place, and a point-of-contact person has been selected.

Let’s start by looking at Number 2 – the RFP team. While having an RFP team is a good way of spreading the responsibility and risk associated with the purchasing decision, you can see how this can quickly add costs to the process. At the very least, each team member should be chosen because they are an expert in some area relevant to the RFP, either as a potential user or stakeholder. They will each be expected to contribute unique perspectives and information during the specification of functional requirements and the preparation of the RFP, and will be required to participate in multiple meetings, assess the market for qualified vendors, attend vendor demonstrations, participate in vendor evaluation, etc...

What about Number 1 on our list – the (well-written) RFP itself? I cannot count how many times I have received an RFP that looks like a template downloaded from the web. I think it is a good idea to begin with a template that is comprehensive in laying out all the necessary sections, but please, please (!) at least take the time to modify the template to fit your specific functional requirements. As a matter of fact, at one time I received two basically identical RFPs from two different organizations (thankfully, the RFPs differed in the organization’s name, address, etc.)

My research shows that many RFPs are poorly written, with inadequate descriptions of the functional requirements, missing information about priorities, poor visibility into evaluation criteria, etc. In addition, the point of contact is usually a procurement person who must relay vendor questions to the appropriate expert, thus delaying the response.

Aside from defeating part of the purpose of the process – namely, to assess all qualified vendors and reduce the risk in the selection process – a badly written RFP not only increases the cost of the selection process, but it also increases the risk. First, it is likely that a well-qualified vendor will decide not to bid, thus increasing the risk that good candidates will not be evaluated. Or, the vendor may decide to add a large “risk premium” to compensate for the ambiguity in the requirements described in the RFP.

The consequences? They are at least twofold... and they are bad:

1. If selection is primarily based on cost, there is a high likelihood that the selected vendor severely under-bid the solution. Thus, the vendor may: (1) Take shortcuts and deliver poorly on the requirements; (2) Try to deliver on the requirements and become financially distressed or insolvent; or (3) Want to renegotiate the price once the project is underway.
2. If selection is based on criteria such as prior vendor performance and experience, it is likely that the selected vendor is proposing to charge way too much. The vendor’s experience has led them to add a sufficient buffer to account for the risk of incurring losses.

Organizations have been creative in implementing steps in the RFP process to mitigate these risks, such as:

• breaking the process into an initial Request for Information (RFI) step (basically a simpler version of the RFP), then fine-tuning the requirements, then undertaking the RFP;
• requiring a live vendor demo of the solution;
• having a question and answer session with each vendor;
• pre-selecting a subset of vendors.

While these may be perceived as improvements, in reality they do little to cut costs or reduce the risk. In fact, these actions usually serve to lengthen the process and increase the cost, both for the organization as well as for the vendors.

The potential cost of the RFP process leads many vendors to decide not to answer to RFPs. Not because they are not qualified – on the contrary, the best vendors probably have enough ongoing business and potential leads that the cost and pain of participating in an RFP is viewed as unnecessary. Others may have limited resources to participate, so they consider the cost to probability-of-success relationship a losing proposition, and decide not to bid.

So, if your organization is considering a RFP process, there is an alternative!

Think about conducting a low-risk pilot or “proof of concept” (POC) project with a preferred vendor. The risk of “playing favorites” at the expense of transparency is greatly outweighed by the benefits of a sole-sourced pilot project.

First, the pilot project will probably be done at a fraction of the cost of a full implementation. Consider this similar to paying for an option in the securities market. You are really paying for an “option” to buy the full implementation. Second, this option gives you a chance to evaluate the solution, address any issues, reevaluate and fine-tune your requirements. Third, if – and only if – you like the solution, you can buy the full implementation. If you don’t, nothing has been lost – in fact, for less than the potential cost of the RFP preparation (market assessment, gathering of requirements, crafting the document, formulating evaluation and scoring criteria, etc.), you have achieved the same desired outcome. Fourth, chances are the pilot will prove hugely successful anyway, since by playing favorites you are invested in its success from the get-go!

RFPs have been hailed for providing transparency in vendor selection, reducing risk in the selection process and beyond, providing a good way of putting together a comprehensive list of functional requirements, and getting a picture of what the market offers. But beware: you may be increasing your actual risk and costs. If your project is critical, you want to minimize risk and costs, and you want to be up and running quickly, consider undertaking a pilot project with your preferred vendor first.