When I’m not giving demos or traveling to tradeshows to meet potential and existing clients, I spend the majority of my day evaluating client RFPs and RFP requirements to determine whether our product and solution are a good fit for your various business needs.
After doing this for a decade, I estimate I have evaluated almost 100,000 written requirements from clients across approximately 750 proposals.
Accordingly, I can speak with professional expertise that there are generally three types of RFP requirements… the good, the bad, and the ugly.
The Good—A good requirement is a single question or statement organized into the context of the surrounding requirements in a clearly defined section of the RFP. Good requirements are easy to respond to, clear and concise, and are logically presented in the context of the surrounding requirements. For example, reporting requirements are presented with other reporting requirements. Good requirements allow your potential vendors to best present their solutions while still giving you an apples-to-apples comparison.
- Example: Do you support classroom course scheduling? Please describe these tools with a brief narrative and screen captures where applicable.
This requirement is clear and concise and provides detailed instructions on the preferred response format.
The Bad—A bad requirement is often multiple, non-related questions laced into a single requirement. Some of the questions might apply to the context of the surrounding requirements, but outliers often sneak in and muddy the waters. Two-part and even three-part questions are okay and even expected. However, LMS buyers should be aware that increasing the complexity of requirements can often lead to responses that may address all elements of the requirement in a compliant manner but are ultimately non-responsive. It is tough to answer reporting, hosting, and customer support questions in a single response with clarity. Instead of the details you were hoping for, you will receive generalizations and high-level information.
- Example: Please describe your reporting tools, company mission statement, and compliance capabilities, and provide a disaster recovery plan.
This requirement goes in four different directions and is vague. Instead of getting the details you seek in this type of requirement, you will get four general statements on the various aspects of the requirement without any real detail or compelling information.
The Ugly—Ugly requirements generally fall into one of three categories.
- The first type of Ugly requirement is one that is not clear and does not make sense or one that is repeated multiple times throughout the RFP. Typos are forgivable and understandable. I often see client requirements repeated multiple times throughout the document. These force respondents to either be redundant or ask the RFP evaluator to jump back to previous responses in the proposal. Keep in mind that redundant requirements make a proposal more difficult to evaluate.
- Example 1: We want to use reporting to drive eCommerce and tie it into classroom courses. This requirement does not make sense and would force respondents to seek clarification.
- The second is requirements from industries like manufacturing that sneak their way into software RFPs from existing company templates. These requirements are irrelevant to a software purchase and should be removed from your RFP template before distribution to potential vendors.
- Example 2: Please describe your warehouse security. This is irrelevant to software vendors as they do not warehouse physical products.
- A live software presentation best demonstrates the third type of ugly requirement. Vendors understand that an RFP is often unavoidable, and we also understand that the best place for our product to shine is in the demos.
- Example 3: Please show us the procedure for an end user to access the LMS, register for a course, and check compliance. This seems like an innocuous requirement, but screen captures can be edited and selectively chosen to make processes and system elements seem easier than they really are. Workflows, use cases, user scenarios, etc., are all best left to the demonstration phase of the procurement.
At this point, careful readers have noted that I have promised the anatomy of a great RFP requirement, yet we have only discussed the Good, the Bad, and the Ugly. So, what makes a Great RFP requirement?
The answer is one that eliminates all but the most capable vendors while keeping the process efficient and illuminating for the evaluators.
Most RFPs contain 3-5 minimum and critical requirements that will disqualify any vendor that cannot meet them. These are often called “must haves” or “minimum requirements” and allow vendors to make easy go/no-go decisions while ensuring the client is not flooded with bids from unqualified vendors. These requirements are your critical ones, determining whether you will move forward or not. They are often hot-button issues driven by either your client base of employees or customers or a lack of features with the incumbent vendor solution.
Forgive me for trotting out this old cliché. Time is money, and evaluating and responding to RFPs takes much time. The more upfront you are about your mission-critical requirements, the easier it is to identify the right vendor for your business. Smart, unqualified vendors will disqualify themselves before you must if they are given the information they need in the RFP to make an educated decision.
Example: We must have a single sign-on with SAML 2.0 or another industry-standard authentication scheme. Our current solution does not support this, and it is critical to our future eLearning initiatives. Vendors who cannot meet this requirement will be disqualified from the bid process, and their RFP will not be considered for evaluation.
Example: We use WebEx to deliver virtual classroom training. Please describe your support for this tool. Vendors with built-in WebEx integration will be preferred during the evaluation.
A Great RFP requirement then meets all the characteristics of a “good” requirement as it is clear, concise, and easy to respond to while also giving vendors the information they need on which requirements are your most critical.