One of the prime reasons that a request for proposal (RFP) is a valuable tool is that it gets promises in writing. Should you ever need it, an RFP gives you evidence of promised capabilities or services that you wouldn’t have if you were relying on deliverables discussed verbally.
But to achieve this, you must craft your questions carefully. This is yet another reason that you should
never use a vendor’s RFP as your template. It’s not structured to protect your interests.
Let’s say that it’s important for your new solution to be able to send your voicemail messages to your email. This capability is a firm requirement, rather than a “nice to have” or something that you would like to explore.
How do you specify the requirement and ensure that you can hold the supplier responsible for providing it?
First, let’s look at what doesn’t work.
1. Statements
Example: “ABC Company wants the new solution to provide voice messages in a user’s email.”
What’s wrong with that?
- It’s not a queston. It doesn’t require a response from the vendor indicating that it can provide that capability.
- It uses the word “wants” instead of “requires.” Expressing a desire is not the same as stating a requirement.
2. Descriptions
Example: “How does your solution provide voice messages in a user’s email?”
What’s wrong with that?
- You are asking the vendor to describe a capability of its solution. But you are not obligating the vendor to provide it in the solution as proposed. In theory, if the vendor didn’t include the capability in its solution, it could say it thought you just wanted to know if the capability existed. You never explicitly stated that you actually wanted the capability included in the solution.
3. Listing a requirement without requiring a response
Example: “ABC Company requires the new solution to provide voice messages in a user’s email.”
What’s wrong with that?
- It doesn’t require a response from the vendor indicating that it has included that capability in the solution as proposed. This gives a vendor a loophole. It can say that the system meets the requirement because it can provide voice messages in a user’s email. But the vendor could also leave that capability out of the proposed configuration in order to lower its price artificially and look more competitive. (Oh, you wanted tires on that car?)
Do vendors really do that kind of devious stuff? In my experience, most are not like that. They are trying to meet your needs and make you happy. But multiple people often work on putting together an RFP response, and sometimes they make mistakes or things fall through the cracks. If they have already locked in their cost structure for the job, going back later to add in additional capabilities at no cost is a problem. Someone is going to look bad; that’s when a vendor starts looking for a way out.
So what kind of language does work? Listing the requirements and eliciting a direct response.
State your requirements plainly. Then require the supplier to say, in writing, what is included in the proposed solution. I have had a few situations where we were able to go back to the proposal and show a vendor where it had said a capability was included. In every case, the vendor then made things right and added the capability at no charge.
Example: “ABC Company requires the new solution to provide voice messages in a user’s email.”
Followed by: “Please state whether your solution, as proposed, has each and every feature described above.”
Typically, I don’t require a response after every requirement. I usually put that phrase at the end of an RFP section, and ask it once to cover all of the requirements in that section. This makes the RFP easier to respond to without sacrificing the ability to hold the supplier accountable.
Writing a high-quality RFP is not easy. The document must convey all of your requirements clearly and completely. This is difficult to do, especially when you are describing technology that is new to you and therefore unfamiliar. Hopefully, this information will help you to hold vendors responsible for their promises.
And here’s a tool to make things easier for you. Click
here for a free checklist of the topics that your RFP must include in order to protect your interests.
This article is part of the "SCTC Perspective" series written by members of the Society of Communications Technology Consultants, an international organization of independent information and communications technology professionals serving clients in all business sectors and government worldwide.
