Preparing an RFP

As an expert in request for proposal (RFP) preparation, I despair for the quality of some RFPs that I've seen.

Most are so top-heavy in contractual and supply chain management (SCM) protocols, that it's often difficult to find the actual requirement. What is it with SCM, they're so busy trying to cover their backs that they forget the RFP is there to solicit the best solution for the business? And through all the SCM bumph runs a thinly-veiled attitude of disrespect - for suppliers, and often for their own organisation.

In general, most RFPs are heavy on contractual obligations (particularly government tenders), and light on requirements. This is, I suppose, a consequence of strict governance, but the pendulum has swung too far.

Many of the tenders I see make scant reference to the business reasons for seeking a solution. They tend to say: "This is what we want." Rather, they should be saying: "This is the problem you need to solve," and according suppliers with the opportunity of solving the problem, rather than providing some technology.

Many of the RFPs do include their business problems, but forget to ask for solutions to these problems. (To be fair, I've seen too many bid responses that focus on the technology, ignoring the challenges faced by the business.)

So, how do I prepare an RFP? Firstly (you guessed it), I ask what the business problem is. Then I ask why the company thinks the requirements specified will solve the problem. Seems simple, but too few companies do this.

When specifying a solution, I ask questions that speak to the business reason. I look for clarity, and evaluatability (new word). It's no use asking: "Is the sky blue?" An answer will be given: "Yes," or "Not when it's cloudy or at night." Both these answers are correct, but how are they evaluated? I always start any question: "Describe how your solution solves ... business problem."

Many of the tenders I see make scant reference to the business reasons for seeking a solution.

Then I make sure these requirements are reflected in the response templates. (It's sad how many aren't.)

Once the RFP is prepared in its draft form, have someone in the company try to respond to it. (The answers don't need to be long or real.) This is where the company can pick up on whether it has asked all the questions needed to get to a solution. Importantly, this also gives the company a good idea of the kind of response it is looking for. Get the trial "bidders" to be critical - to answer questions with a "yes", if that's all that has been asked. Let them say: "I don't understand the question," and "What do you really want?"

Publishing and RFP is also fraught with pitfalls. Only minor amendments can be published, so try to make all the amendments before publishing. I've seen one client publish so many amendments that it had to withdraw the RFP.

The Q&A session should be open - if one supplier asks a question, all potential bidders must get the answer.

While bidders are preparing their responses, the customer should assemble a team to weight the evaluation questions. This team should not be the evaluator. The idea is that evaluators score all answers equally, although the PPPFA says all weightings should be published.

I've recently had a problem where some questions were weighted, and others weren't. This means essentially that those un-weighted questions could not be evaluated, as they did not contribute to final functional scores. So to keep within PPPFA rules, every question should be weighted, or only those at the highest level of requirement. (Saying data centres are more important than networks is fine.)

Remember that bidders will use weightings if published to focus attention on what is important to the customer.

These are the basics of RFP preparation. It's a worry to me that so few RFPs exhibit evidence of this basic understanding. And it's a worry to me that so many suppliers respond to flawed RFPs.

The problem lies both with the preparation of the RFP, and also with the responses to these tenders. Suppliers try to answer RFPs in the format that they were published. But, too often, this format compromises both customers and suppliers, and the best solution disappears under a pile of procedural format.

Companies are doing themselves no favours in the way they publish RFPs, in the way suppliers respond, and in the way their submissions are evaluated.