“We put in a new LMS and it sucks. Can you come and take a look at it?” – That was essentially the call I received from my friend Ron who is the CCO of a medium size Pharmaceutical company and who doesn’t mince words. Ron is also an amazing person and a great Compliance officer because he cares deeply about patient safety. He relies heavily on his custom, Compliance eLearning to properly educate the company’s employees to keep everyone using it’s products as safe as possible. He’s also a close friend… So even though I was crazy busy at the time I said yes, I would take a look.
A couple of days later I flew out to his office for a week long fact finding mission. Ron met me in his office and after we caught up he filled me in on what was going on. “We felt it was time to upgrade our old LMS because we felt that it was too difficult to use.” He said, “We were getting complaints constantly about it from the IT help desk. There were times when it would be the majority of their calls it was so bad. So we decided to upgrade to the newest and best LMS out there. It’s cloud based so we don’t have to worry about IT infrastructure and it’s been fully validated. We thought it was going to be great. Unfortunately, however the support calls have actually increased since we put it in and the IT guys can’t find anything wrong with it . Can you figure out what’s going on?
Here’s the system validation documentation, we’ve been analyzing it for months” he said pointing to a towering stack of paper. We thought you would want to start there…” Looking at the impressive (and perhaps excessive) stack of papers I knew two thing very quickly. First that Ron had done an amazing job as usual. There was no doubt in my mind that this system not only worked as advertised but would withstand the scrutiny of the FDA’s most fickle investigator. And two that I had absolutely no desire to wade into that giant stack of legal/techno-babble. (I’d have been there still if I had I’m sure.)
I decided instead to look at the user complaints first. What was it that people were complaining about if the system worked? Was it hard to use, poorly documented, bad training, what??? After looking at the complaints it soon became very apparent to me that it was none of those things. In fact, in a sense, it wasn’t even the LMS at all! It turned out that in over 90% of the cases the complaints had to do with poorly built or implemented eLearning modules hosted on the system not the system itself.
In the user’s mind there is no difference between the LMS and the content. In fact users spend far more time in front of the content then they do in front of the LMS screens. To them it’s all one system but to the admins it’s exactly the opposite. They spend most of their time in front of the LMS screens and very little if any in front of the content. The content simply wasn’t their responsibility beyond loading on the system. When issues were reported they either didn’t understand them because they couldn’t see them from the user’s perspective or they would realize it was content and simply pass the ticket to a (typically) non-technical course owner who rarely could help. Of course this lead to frustration from the learners who blamed the LMS causing the system to gain a poor reputation.Case closed. I understood the problem. But now I had to figure out how to fix it…
I realized that this wasn’t going to be a quick software patch and it wasn’t just going to be a policies and procedure changes either. No this called for a complete team culture and attitude change. Ron and his team couldn’t escape the perception that the content and the LMS were the same thing so they had to learn to embrace it. So I sat down and wrote out the following recommendations:
- Empower LMS administrators to become the gate keepers (from a technology standpoint) of the eLearning modules on the system by making them responsible for testing each one and making sure each functioned correctly technologically. Start with the existing ones, test each one and notify course owners of those that do not function correctly and deactivate them. Moving forward each new module must be tested first on the staging server by an LMS administrator before loading it into production.
- Ensure that you have to original source code (not just the SCORM package) for every eLearning module on your system because without it you can’t make changes in the future to the content. Simply don’t do business with vendor who refuse to provide it as part of the contract and ensure that it is well documented and easy for someone else to pick up if need be.
- Put together a best practices document for internal and external instructional designers and developers detailing the specification of your particular LMS, network bandwidth and anything else technical that might be relevant as well. Be sure your administrators have this ready to email when needed.
- Create an external LMS testing area where course developers can test their courses themselves. If this is cost prohibitive use scormcloud.com as a testing area instead as it is free and anything that works on their should work on your SuccessFactors LMS as well.
- Implement yearly reviews of course content and functionality by both admins and course owners. If course owners are no longer available, new owners should be identified by the business or the course deactivated.
- Use the perception that the LMS and content are the same thing to your advantage. You have a stage use it! There are very few (if any) other internal technology platforms that allow for the use of multimedia inside your corporate firewall. Make the most out of it by creating your own content. There are things you need to train people on I’m. (like how to use the LMS…) Why not show off the system functionality at the same time?
