The Learning Management System is Undead. Everyone wants to kill it but no one does.
We are stuck in this no-win situation because it makes sense to have a system that tracks learning data and manages logistics, however the cognitive load and resource drain created by its complex workflows leads us all to question whether it is worth it. We will remain in this limbo state until we resolve the contradictions. The time has come to face this conundrum, but in order to do so we need to understand what the core problem is. The workflow structure of the LMS is layered with artifacts from past learning practices much like rock strata contain the fossils of creatures from eons ago. Unearthing these structures and examining their flawed assumptions can be a start to working towards a more useful learning architecture.
Let’s go back to the early days of the corporate LMS when it was really a classroom management system. Unlike K-12 where classes occur daily and Academia where classes are given on a semester basis, the scheduling of classroom based training in the workplace is highly variable. For this reason, LMS design had to be hierarchical to accommodate for all possible scenarios. The basic structure is this:
- Course: the container of the content delivered to learners
- Class: an instance of delivering the course
- Session: an actual time and place where learners are presented with the content
Why is it necessary to track down to this level of granularity? LMS vendors are trying to sell more functionality around these objects: reporting on course completion, scheduling of people and resources for classes, attendance at sessions, etc. Without the hierarchy, the data structure necessary for this functionality would be hard to manage. The problem is that this level of complexity makes things easier for the LMS programmers but for the L&D professionals and learners it just adds to the strain of using the system.
An important component to making this hierarchy work is the concept of the registration. On a practical level, registrations are used for printing rosters, to capture attendance, and for managing wait-lists, class sizes, food orders and penalizing no-shows. On a data level, a registration which records an intention to participate in learning, acts to create the first record in the database that all subsequent transactions can be based on. For L&D and learners, though, it adds another layer of workflow that creates more confusion.
Now let’s move on to eLearning. Even though eLearning is nothing like classroom learning as far as workflow, no one wants to have a separate classroom system and eLearning system. So a structure needs be contorted to accommodate both processes. This leads to some pretty obvious contradictions that we all live with. For starters, eLearning is a transactional activity and not hierarchical, yet to fit in an LMS we need to create separate eLearning courses and eLearning activities (the equivalent of classes). Also, registrations are not necessary for eLearning but they are so integral to the LMS data strategy that they can’t be removed. This creates an extra step that learners do not understand.
Once we accept the flawed premise that eLearning must follow classroom training workflows, we now have to solve for problems that this model creates. This is like the problem people have when they try to fit unwieldy metaphors to complex real-life situations. Here’s an example: in classroom training, instructors are the arbiters of learning. If they feel that a student has learned, they give them a completion for the course. The completion becomes the coin-of-the-realm for learning data. With eLearning, there is no instructor to verify your completion. If the LMS simply links to the material, there is no way to prove that the learner “completed” the course. The proxy for the instructor is the end of course quiz. This is designed to prove a negative. Just like attendance of a class is not a guarantee of learning but not attending class is a reliable indicator of not learning, so too, the ability to answer questions about the content is not a guarantee of learning but the inability to answer those questions is a reliable indicator of not learning. Building a whole system to prove a negative seems a bit weak.
To create this dynamic in a foolproof (read human-proof) way, various protocols like AICC and SCORM need to be followed to control the flow of data between the learner and the database. This tight control leads to much of the difficulty in using and supporting these courses. If you are going to reliably report on this data, you need to follow some logical rules that take all possible scenarios into account. For instance. It might seem intuitive that you can make changes to a course any time you want but if you change the learning content itself aren’t you invalidating the completions that have occurred so far? This kind of logic may be valid from a data integrity standpoint but it kills usability. The need for this complexity is created by the Frankenstein monster we put in place when we try to create a hierarchical system that is meant to solve for all situations.
Now we have Social Media and Mobile where control is not practical or desired and you have a crisis. The structure of the LMS was designed to control participation data but we don’t learn that way. We learn by interacting with people and ideas in countless ways. The Internet which was designed to circumvent all control is allowing us to learn without restrictions. The LMS is not equipped to handle that. This is why we have to address these issues now. The latest successor to SCORM, called xAPI (the API formerly known as Tin Can) begins to address some of these problems. It tracks transactions rather than hierarchies and it doesn’t require that you discover learning through the LMS so it can capture data more freely but this is just the tip of the iceberg.
This seemingly intractable problem was created when vendors attempted to give us everything we wanted in one package. The answer is in the L&D industry doing some soul searching about what it is that the learner really needs. I could go on forever about the nuances of the LMS workflow. we need to make the LMS more usable for learners and for organizations. To do this we need to continue this exploration.