The Anatomy of a Great RFP Requirement

When I’m not giving demos or travelling to tradeshows to meet potential and existing clients, I spend the majority of each day evaluating client RFPs and RFP requirements to determine if our product and solution provide 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 clearly organized into the context of the surrounding requirements placed 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, for instance.  Good requirements allow your potential vendors to best present their solution while still giving you an apples-to-apples comparison.

1. Example: Do you support classroom course scheduling?  Please describe these tools with brief narrative and screen captures where applicable. 

This requirement is clear, 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 tend to 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 in nature.  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 instead receive generalizations and high-level information.

2. Example: Please describe your reporting tools, company mission statement, 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.

1. The first type of Ugly requirement is one that is not clear and does not make sense or one is that 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 to 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 into classroom courses.  This requirement does not make sense and would force respondents to seek clarification.

2. The second are requirements from industries like manufacturing that sneak their way into software RFPs from existing company templates. These requirements are just not relevant to a software purchase and should be removed from your RFP template prior to distribution to potential vendors.

• Example 2: Please describe your warehouse security. This is not relevant to software vendors as they do not warehouse physical products.  

3. The third type of ugly requirement is one that is best demonstrated in a live presentation of the software. Vendors understand that often an RFP is unavoidable, 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 their compliance. This seems like an innocuous requirement but screen captures can be edited and selectively chosen to make processes and elements of the system seem easier than they really are.  Workflows, uses 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 in a manner that keeps 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 referred to as “must haves” or “minimum requirements” and allow vendors to make easy go/no-go decisions while also ensuring the client is not flooded with bids from unqualified vendors.  These requirements are your critical ones, the requirements that determine if you will move forward or not.  They are often hot button issues driven from either your client base of employees or customers or from a lack of features with the incumbent vendor solution.

Forgive me for trotting out this old cliché, but time is money and evaluating and responding to RFPs takes a lot of both. The more upfront you are about your mission critical requirements, the easier you will be able 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 single sign on with SAML 2.0 or other 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 a built in WebEx integration will receive preference during 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.

Get off to a great start in your search for a learning management system with Meridian’s best practice LMS RFP template.

Download Meridian’s best practice RFP template now.