I recently received a regular e-mail update from one of the corporate e-learning research firms, with the subject line “Are all of these LMS reps really telling the truth?” The premise was that organizations often purchase learning management systems based on claims made by the sales representative about particular online learning features or functionalities only to discover that the finalized product does not really work in quite the way expected. In an effort to sell one of its recent reports, the research firm suggests that the issue is not really one of sales representatives telling the truth, but rather of differences in how different LMS companies approach fulfillment of specific feature requests. In its review of more than 200 features across dozens of learning management systems, the firm assigns one of six classifications to each feature reviewed:
- Automatic: Built-in, out-of-the-box functionality that can be simply switched on and ready to be used.
- Semi-automatic: The feature is mostly available in the system but requires some programming and/or customization to activate.
- Semi-custom: This feature is partially available in the system and can be adapted through some moderate custom program.
- Custom: This feature is not available in the current system but can somewhat easily be added through custom programming services at the time of implementation.
- NA; not a current feature: This feature is not available in the current release of the software.
- Third-party add-on: This feature can be added upon implementation using third-party software.
This list of categories is followed with the impressive claim “The result is that you know exactly what you’re getting when selecting a learning management system.” In a word: nonsense.
Don’t misunderstand me: There is indeed a lot of confusion around how LMS companies articulate and implement similar features. And we are big believers that good solid research reports can eliminate a lot of needless time that is spent during the average RFP process gathering basic feature information from LMS providers. But knowing the feature is there, or even that it is “automatic” or “semi-custom” only gets you a fraction of the way to knowing whether you will end up with a deployed system that truly meets your business needs. Even with these categorizations, there is still a great deal of interpretation involved in how a feature works. In my opinion, a more critical step is the development of detailed use cases or user scenarios that accurately describe the most critical functions you expect an online learning system to support. Ideally this exercise should precede any focus on specific features and should then drive your review of features during vendor demonstrations.
I am not an IT guy by training, so I will not pretend to know the best approaches and practices for the development of formal software development use cases. Having been on both the buy and the sell side of learning technologies many times, however, I know the practical steps any organization can take to help ensure a good business choice through use case development. To start with, be absolutely certain that you understand your overall strategy and business goals for e-learning. A key part of your strategy and goal formulation should be developing a thorough understanding of who your end users are and which online learning products and services will be of most value to them. Uses cases are only valid to the extent that they map back to actual user needs that correspond with your organization’s business goals. With these factors in mind, the next step is to invoke and document your imagination.
Imagine yourself in the place of your most typical end user or administrative user, actually sitting at the keyboard and on the verge of interacting with the learning management system environment. Now, in your mind, start walking through the specific actions you would expect to take and what you would expect the result of each action to be. A simple three column table like the following can serve to capture the actions you take and the corresponding results.
|ID||User Action||Desired Outcome|
||By default, all of the courses that the user is currently enrolled in or has ever been enrolled in are listed in ascending alphabetical order by title. For each title, an icon indicates the status of the course: not started, complete, in progress. For each title there is also an option to view additional details about the course.|
||The view for the course expands to show additional information associated with the course, including
||A PDF document launches that displays the following:
(Detail certificate contents)
As you can probably already sense, the above can become a very detailed and ultimately very tedious exercise. The goal as a business decision-maker, however, is not to think through every possible variation that can occur. Rather, working with the dozen or so “must-have” scenarios that you can imagine, make sure you have walked through the broad set of actions that comprise that scenario. Even doing this at a relatively broad level requires discipline and time, but the process inevitably clarifies your vision and identifies challenges and opportunities of which you were previously unaware. Ideally, once you have gone through the process, you should also walk through the results with a handful of target users.
A set of use cases that as been reviewed and verified by target end users is one of the most valuable tools you can have in determining the features your learning management system must have and can serve as the roadmap for vendor demonstrations. Having prospective vendors speak to and demonstrate against your specific use cases in real time will be more valuable than any information you are likely to gather through an RFP. And as a bonus, the use cases you develop during the technology selection process also serve as the basis for test cases that can be used to verify that a vendor ultimately delivers what you pay for.