The Trouble with RFPs and How to Avoid Being an Unhappy LMS Buyer

At EthosCE, we get to look at a lot of learning management system vendor selection processes. It’s clearly a difficult task: there are hundreds of vendors, dozens of technologies, and countless features you must investigate and verify to find the right LMS for you.

Selecting a learning management system is a challenging task. Use relevant criteria rather than trying to capture every possibility.

I wanted to share a few thoughts we had in the hope that it might make your task easier. Granted, these are all from the vendor perspective. However, over the years, we have seen potential customers making mistakes that could result in getting an LMS partner and software that does not meet their needs. Above all, we want happy customers and the first step is to make sure we are good fit for each other. So, in this post, I will focus on helping you figure out if an LMS is right for you.

Many of the challenges in the process come from the “request for proposals” or RFP. Issuing an RFP is just one part of the LMS selection process. However the RFP is often overweighted in the decision-making criteria. If you put too much confidence in the RFP rating, you are asking for trouble.

Here are a handful of the top issues we encounter with RFPs.

The RFP is not appropriate for your intended use of the LMS

EthosCE is an LMS for continuing education. It’s not for K-12 or talent management, and we try to qualify our customer leads carefully. We are surprised, then, when we see RFP line items that clearly are for other uses. It conveys that the author does not understand what they are looking for, have not researched potential vendors, or …

It was copied from a vendor’s template

There are a number of RFP templates that you can download from vendors and consultants. Likely these are written to favor the vendors’ feature set rather than your needs. They may exclude important features. Others are huge sprawling documents with many hundreds of line items, many of which are irrelevant to your implementation.

It’s not appropriate for your size

If you send an enterprise-level RFP, you should expect an enterprise-level budget. Use an RFP that is tailored to your needs and your organization’s size and likely the budget will be appropriate too.

Two or more requirements are bundled into a single line item

If we have one feature out of the box, but the other requires customization, responding presents an ethical dilemma. Do we respond with the higher rating number, and note the requirements gap in the comments, or use the lower number? Either way, if you are using the numbers to qualify vendors, you are getting a misleading ranking of our ability to meet that requirement. I’m surprised this happens, but it does, nearly every time.

It didn’t say what you meant

We got this question in an otherwise well-written RFP recently:

“Is your LMS configuration using a redundant, fault-tolerant architecture with no single point of failure which includes all components of hardware and software?”

All components of hardware and software? I’m sorry to disappoint, but the answer is no. Realistically, providing such levels of redundancy is not necessary for most clients. Nor is it usually a priority. I’m not sure why the question was written this way, but what I think the author really wanted to know is something like, “How much downtime can we expect each year?” or “Please provide your average uptime percentage over the past 12 months.”

When it said what you meant, did it mean what I thought it meant?

Language is a slippery beast. Your “certain criteria” are not my “certain criteria,” Your “groups” might be different from our “groups.” Putting too much trust in a vendor’s responses to a document with such broadly defined terms is dangerous.

Here’s one example:

“Does the LMS include easy to use file management features such as copying, moving, and renaming files?”

This RFP seems to trust the vendor to define “easy to use!” Guess what? Our LMS is easy to use and so is every other vendor’s if you were to ask them. It’s a subjective adjective. You want to avoid those at all costs. Think like a lawyer when asking your questions — weed out ambiguity at every chance.

Don’t misunderstand the purpose of the RFP

For better or worse, an RFP is not a contract. If it were, I doubt your lawyers would let this kind of language pass. The RFP is meant to help you understand the vendor and their software. Don’t let it give you false security just because it’s a written document. Vendors are responding based upon their assumptions and past experiences, which may be different than yours.

Suggestions for Vetting LMS Vendors

1. Use an RFI to winnow the field of qualified vendors

Send out a one- or two-page RFI with your high-level requirements, and use that to do an initial vendor analysis. Provide a list of your use cases and ask how the vendor’s software addresses them.

2. Use a smaller, more appropriately focused RFP

Keep the questions relevant to your organization and use of the software.

3. Demo the system at length

This is perhaps the most important recommendation. Don’t be lazy and do a quick poke around. Set up users and courses and become familiar with the two or three systems on your shortlist. And, really spend time getting to know the administration screens. Remember, you are going to spend much more time in the LMS than your learners will.

4. Ask the vendor to set up your most important two or three courses in a demo system

If you can’t demo at length, at least ask the vendor to set up your courses so you can see how they would work and display in each system.

5. Ask to see and use similar implementations

Some might be publically available. If not, ask for a demo.

6. Reference checks

This is obvious, but never make a major LMS purchase without checking references.