This is not an easy question because it depends …

It depends on the who, what, where, when, why, and how. And every change to each of these elements changes what is required for a good RFP. While there are general rules you should follow if you want a good RFP, and a good RFP process, as they say, the proof is in the pudding, and you will need to include the right “proof” in the RFP to get served the right “pudding”.

Let’s take these basic questions they teach you in elementary school, which are often forgotten in today’s business world (and, sadly, the media).

Who: needs the product or service you are going out to bid for. This is critical, even if it is an RFP for paper. The paper an office worker needs to stock the printer is not the paper an engineer needs to print out large diagrams is not the paper marketing needs for their glossy brochures. Who needs it can have a big impact on what they need.

What: is the RFP for. More specifically, the focus of the RFP is on what problem needs to be solved or void needs to be filled, not on what is on the market. Specifications should only be as detailed as necessary as it is up to the supplier to identify the best solution they have for you, not up to you to pick something from a catalog you think is appropriate. Even if you need a micro-controller for a new product you’re designing, your focus should be on the integration and processing requirements, not currently existing last-generation catalog items.

When: is the product or service needed. This is critical to define. If you are replacing a software system and it needs to be done before the current contract ends in 12 months, you can’t accept a proposal that will take 24 months, and suppliers need to know this so they can decide up front if they can work within any absolute timeframes or not. If you forecasts are that you will run out of critical parts in 60 days, you can’t accept 90 day delivery times.

Where: is the product or service needed. If you need a physical good in a warehouse outside of Lebanon, Kansas, that is entirely different than needing a good in a warehouse outside Jacksonville, Florida, especially if it’s likely that the good will be imported (on ships). The latter is a short drive from a port, the former is a long drive to more-or-less the geographic center of the USA. Specifying this is critical if you need guaranteed delivery times or people on-site of a specialty not found in the city, or state.

Why: are you going out to market. Unless this is a brand new need, chances are the organization already has a product or service it is using, even if such product or service isn’t that great. Like the who, this puts the context into what is needed, which is not always a pre-existing catalog product or service.

How: will the product or service be used or consumed? This defines the specifications much better for most products (with the exception of components that are needed for a build) much better than any feature/function list you can come up with. In software, BI for executives is NOT the same as BI for finance people which is NOT the same as BI for analysts.

In other words, if the RFP is NOT focussed on the who, what, when, where, why, and how, no matter how extensive it is, what other boxes you tick, or what best practices you follow

(which should include:

• References Up-Front
• Core Solution Litmus Test
• Third-Party Claim Verification
• Open Book Negotiations
• End-to-End Total Cost of Ownership Elucidation
• Open Finals

)

you won’t have a good RFP. Where good will also, as you have figured out, be different for indirect, direct, services, and software (which we have partially addressed in our recent series on Best Practice Vendor Selection for True Multi-Nationals: 2025 Reprise).

We’ll tackle each of these in our future posts at a high level to give you some insight into how to approach the RFP and what to include.