Writing an RFP to Get the Responses You Need

Writing an RFP can be a daunting task. But the goal is beneficial and necessary: get input from a variety of third parties so you can make the best choice for implementing your requirements. What happens if you don’t get responses that accurately address your needs? How can you know if you’re making the best choice? It’s disappointing to receive responses when the vendors clearly didn’t understand your needs or give you innovative ways to address them.  

I’ve seen and responded to a good number of RFPs, from fairly informal to highly structured and detailed.  There’s one piece of advice I can give to RFP writers that will result in the best responses. And no, I promise this isn’t one of those “one weird tip” clickbait ads!

Let’s be specific.

There are many things you can do to ensure you’re making the right choice: have good evaluation criteria, solicit responses from well-regarded vendors, clearly understand your project goals and success criteria, and many more. However, I would argue that the most important thing you can do is be specific.

A common practice I’ve observed is the tendency to put forth general requirements. I can only assume that this is done with the idea that it gives vendors the flexibility to respond with ideas that you may not have even thought of. While this is a nice concept, it also leads to many more questions during the response process. If you’ve ever written an RFP and received what seemed like an excessive number of questions about what the requirements meant, then you may have fallen victim to this idea.

Unfortunately, the nature of RFPs is that they have a very formal process of asking and responding to questions.  This generally doesn’t allow the level of clarification and exploration necessary to come up with the best answers. Instead, the process relies on the vendor’s knowledge of other implementations to assume your business needs are the same as others. But what if you don’t want what everyone else does? What if your business processes give you a strategic advantage, but those processes can’t be supported by a “standard” implementation? If you feel that you need to give general requirements in order to encourage vendors to come up with solutions you haven’t thought of, you might be better served by starting with a trusted partner to advise you on what you should be looking for.  If you don’t have that kind of relationship with a vendor, start with an RFI to get a feel for solutions in your space and vendors who seem to know what they’re talking about. Once you’ve narrowed your list down to some knowledgeable partners, have some whiteboard sessions to discuss your needs and what you should do to prepare your RFP.

Watch your language.

Another example of a lack of clarity is stating specific needs with vague language. “Capability to” or “support for” or “ability to” are ok for an RFI, but aren’t clear for an RFP. Do you just want the desired software to have that capability in case you want to use it someday, or do you expect the responder to configure it for you as part of this contract? Are there rules or constraints that should be known in order to respond accurately?

Clarity for the win-win.

The results of responses based on unclear needs can have drastic consequences. The lack of clarity can lead to implementations that don’t meet your goals or additional costs. Worse yet, it may result in purchasing the wrong software. In those cases, it may not just result in additional configuration or customization costs; the software may not be able to meet a business need at all! That’s bad news for you – and the vendor, if they’re reputable, won’t be happy, either.

The bottom line is that the RFP needs to clearly state expectations. The more precisely you can tell vendors what you need, the more likely it is that they can accurately tell you the costs and effort required. And isn’t that best for everyone?