RFPs – Time for a Rethink?

RFPs – Time for a Rethink?

It seems to me that the traditional Request for Proposal (RFP) process common in enterprise software procurement exercises has, over recent years, lost much of its value. While the principle of a customer inviting formal proposals from vendors makes complete sense, most of the energy, cost, and time involved in the process is now taken up with the preparation of, response to, and evaluation of, extensive technical questionnaires that have very little value to either party.

Why Issue an RFP?

Let’s step back and consider why a company is looking for an enterprise software solution and why they might issue an RFP. The goal surely is to improve the firm’s current situation. Whether the trigger for a system selection is the obsolescence of the current solution, a digital transformation, or a change in the business environment, there will be a series of business and technical problems that the new solution must solve. In order to select a solution, the customer must satisfy themselves that the chosen vendor can solve their problems – hence the RFP.

Today’s Typical Process

• The first thing that a company will often do is compile a list of features that the new solution should have – usually based on the current system and current business practices. Or worse, they will look for a list provided by a third party or a potential vendor and take that as their business requirements. Sometimes those lists of features are extremely long – recently I saw a spreadsheet containing 1,200 questions! Very rarely do the questions talk about business problems.
• Having scanned the market for possible vendors, the customer then sends this list to them, along with some more general questions, and asks for a proposal.  Frequently customers will limit the amount of interaction that they allow suppliers, arguing that they must be fair to all of them.
• The vendors will then attempt to respond. Given the lack of context, and assuming that they are reasonably well qualified in the space, they will likely be able to answer yes to almost every question by applying suitable assumptions and interpretations as to the meaning of the questions.
• Having received responses from several vendors, the customer then ranks each, using some mysterious scoring system and eliminates all but the top two or three.

At this stage, there may be more interaction between the customer and the short-listed vendors, but the content of the proposal remains frozen in time. It is highly unlikely that neither the RFP questions, nor the answers, will be an accurate reflection of the business needs once the project starts – as I mentioned above the answers will have been crafted based on assumptions that may well be inaccurate, but it is only once the customer gets into the detail of the implementation and in the light of the chosen product’s capabilities, that the real requirements will become apparent. So what was the point of all that effort to compile the feature lists?

A Better Way

As I said, requesting a formal proposal from potential vendors makes complete sense. But the request needs to provide enough information to enable the vendors to provide meaningful proposals – partly in the RFP document itself and partly through significant interactions between customer and supplier.

I am not saying that an RFP should not contain any questions. It is important to establish some basic facts about the vendors, and there are some technical areas, particularly around privacy and security (where questions tend to be less ambiguous anyway) that are vital to a successful long term partnership.

But hundreds, or even thousands, of feature level questions, really do not add any value.

This approach is in the interests of the customer and will greatly improve the chances of a successful implementation.

Surely, the time spent on preparing detailed questions and then reviewing responses would be much better spent on understanding and documenting the problems to be solved and the high-level business processes to be supported and then working with potential suppliers jointly to identify the optimal solution.

Each vendor, based on their experience, will likely have a different approach to solving the customer’s business problems, and so being prescriptive about the required solution, by documenting requirements in detail, is not taking full advantage of each vendor’s capabilities.