The Hunt for the Perfect LMS – Part 2

June 18, 2019

One of the most commonly requested capability in RFPs is that the Learning Management System (LMS) be able to obtain enrollment information or report course completion data to a third party crew qualification system. This implies that the requested capability is extremely difficult to implement.

The request itself makes perfect sense, and you’ll usually find it written that exact way in the RFP, but it’s often an indicator that the person writing the RFP doesn’t fully understand what they’re asking for even though they think they do.

Let me explain how this works.

Let’s say you want to go skiing in Breckenridge tomorrow. Since we’ve had a lot of snow lately, you want to find out what the weather will be tomorrow. How do you do that?

One of the easiest ways is to go to Google. Simply type in the following in the search box: the city name, state, the word weather, and the word tomorrow.

You will get about 285,000 results in less than a second. The most relevant weather is at the top.

Welcome to the world of Web Services. A web service is a program that runs on a server and is used to provide machine to machine communications.

The concept behind a web service is literally “ask for some information and you shall receive”.

A web service is used (or consumed, in technical parlance) by specifying a web address and the information to be passed. In the example above, the information the web page passed to the Google web service were the words used in the search box. In turn, the web service searches the Google database and then returns what it found, with the most relevant results at the top.

So how difficult is it to implement this type of cross-communication capability? It’s literally child’s play for an experienced programmer. The code for a simple web service that passes completion data from one system to another can take less than 5 minutes to write. Seriously!

So, if it’s so easy to implement, why do RFPs invariably specify that the LMS must be able to obtain enrollment information or report course completion data to a third party crew qualification system? From the customer’s point of view, there is a desire to limit the duplication of effort and data, so the request makes perfect sense. However, the request could be formatted in a way that provides better context and showcases the real need behind the specification. The real question should be: “Does your organization have the ability to develop an API to communicate with a third party crew qualification system?”

It takes two to tango, and in the case of this particular feature, the two that need to play together are the provider of the crew qualification, and the LMS provider. Notice that the customer is not in the mix. As the recipient of the RFP, we obviously would like to get the business, so of course, we’re ready to get to work to implement the feature. But what about the crew qualification system provider? Well, they’re not so motivated because they already got the business in the first place. And since there’s usually overlap in capabilities, their system may already provide an LMS, but their customer is looking for a different provider.

So, if you are authoring an RFP or are an organization looking for this particular capability, you better be prepared to put pressure on the crew qualification system provider to “force them” to cooperate.

When you’re talking with an LMS vendor, you should always beware the one that tells you their system is the greatest on the planet because it interacts with “X” or “Y” crew qualification system. Remember, it’s child’s play to build this into a system, so don’t get taken for $10 when the feature’s only worth 10 cents.