Melissa Swartz ¦ March 27, 2019
I have a client who was making a large purchase for a solution that would impact their entire organization. They had narrowed the field to three finalists, who were asked to give presentations. The client recorded the presentations on video, mainly because there were some key stakeholders who could not attend. They made a selection and began the implementation.
Things were going well until the client was told that a key capability had not been included in the solution as it was proposed. What? The client was sure this had been promised, but how could they prove it? Video recording to the rescue! They reviewed the presentation and found where the promise was made, and could prove it to the vendor. The result? They didn’t have to spend $100,000 on a change order to get the capability.
In my opinion, one of the reasons that an RFP is valuable is that it can be an excellent way to get vendor promises in writing. This gives you the ammunition you may need later to prove that capabilities or services were offered. Without this proof, the vendor can always deny a verbal conversation.
But to achieve this, you must craft your questions carefully. Let’s say that it’s important for your new solution to be able to send your voice mail messages to you in 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 vendor responsible for providing it?
First, let’s look at what doesn’t work.
- 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 question. It doesn’t require a response from the vendor indicating that they can provide that capability.
It uses the word “wants” instead of “requires”. Expressing a desire is not the same as stating a requirement.
- Descriptions
Example: “How does your solution provide voice messages in a user’s email?”
What’s wrong with that?
You are asking them to describe a capability of their solution. But you are not obligating them to provide it in the solution as proposed. In theory, if they didn’t include it in their solution, they could get by with it by saying that they thought you just wanted to know if the capability existed. They didn’t know you actually wanted it to be included.
- Listing a requirement without 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 they have included that capability in the solution as proposed. This gives a vendor the ability to say that the system meets the requirement because it can provide voice messages in a user’s email, but to also leave it out of the proposed configuration in order to artificially lower their price and look more competitive.
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 often there are multiple people working on putting together an RFP response, and sometimes they make mistakes. 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 they start looking for a way out.
So what kind of language DOES work?
Listing the requirement(s) and eliciting a direct response.
This makes the vendor say, in writing, what is included in the system. I have had a few situations where we were able to go back to the proposal and show a vendor where they 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 the response after every requirement. I usually put that phrase at the end of a section of the RFP, 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 vendor 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 when you are describing technology that is new to you and therefore unfamiliar. Hopefully, this tip will help you to hold vendors responsible for their promises.
