This Chair is Too Big: The Case Against Individual LCMS Tools

The arrival of learning content management systems (LCMS) ten years ago was heralded by analysts as a major step forward in the evolution of eLearning. LCMS tools, it was believed, would solve many of the challenges related to using individual authoring tools while also enabling the full adoption of learning object-based development models. Unfortunately, neither prediction has been fully realized. Learning object creation and reuse has proven to be more complicated and problematic in practice than in theory. (Howard, 11). And while LCMS solutions at least partly address most of the issues associated with individual tool strategies, they also come with significant costs and unexpected challenges that, until recently, have been underreported.

In 2005, Chris Howard of Bersin & Associates conducted a survey of the LCMS industry to help organizations understand the challenges and opportunities associated with this eLearning platform. As part of this survey, Howard uncovered a number of serious challenges with LCMS approaches:

1. Content reuse, repurposing, and sharing
2. Integration with other tools and systems
3. Content development (establishing development standards and usage by content contributors)
4. Implementation
5. Managing the development process

Howard's research would seem to indicate that while the major challenges of individual authoring tools are collaboration and team-based authoring, the major challenges of LCMS solutions are linked to content, integration, and implementation.

The Myth of Reusable Learning Objects

According to Howard's data, the top three challenges in using an LCMS are integration with other tools and systems, establishing development standards, and implementation (52). These are significant challenges on their own, but there is another serious challenge buried in the data. Content reuse, content repurposing and content sharing, taken as a group, were ranked as highly as both "integration issues" and "establishing development standards." Clearly, organizations are also having serious issues in managing content.

With regard to this issue, Howard found that the majority of corporate learning programs do not have the necessary characteristics for effective reuse. He concluded that in many cases, "...reusing across programs isn't worth the investment" (23). Instead, organizations should focus on content recycling or content repurposing (copying and reusing) as "...a more practical application of leveraging existing content" (22).

Unfortunately, this recommendation has come too late for many organizations. According to Howard's research, 77% of LCMS buyers ranked reuse as their primary consideration for buying an LCMS system, while 62% ranked reuse across departments their number one priority. Despite these stated objectives, only 38% of current LCMS developers actually reuse any content, and even this smaller percentage of reuse is done at a reduced scale. In other words, a significant number of LCMS purchasers have already purchased LCMS solutions for the wrong reasons and have significantly missed on expectations.

Content Development

These challenges related to learning objects cannot be understated. In order to achieve reuse, organizations must be willing to make compromises in their development model. The typical LCMS development environment is quite a bit more complex and inefficient than the development environment of a typical single purpose authoring tool. This is also reflected in Howard's data: When asked to rank their number one challenge in using the LCMS, 10% of the survey participants cited "usage by content contributors" and 25% cited "establishing development standards" (Howard, 52).

For developers who have experience with both LCMS and individual authoring tools, these results are not surprising. An LCMS is not designed to be an efficient authoring tool; it is first and foremost designed to be a content management tool. LCMS therefore have a host of features related to content management: workflow, reporting, content-related administration rights, taxonomy models, etc. that have nothing to do with creating content.

Unlike most rapid eLearning authoring tools, LCMS development environments are typically too unwieldy for most subject matter experts and even some course developers, particularly those without eLearning experience. New eLearning developers and virtual team members such as SMEs and project managers need more structure and guidance than an LCMS typically provides.

Additionally, if the tool doesn't provide enough structure around themes and templates, larger organizations may find it challenging to develop consistent content within the same course, let alone across courses. One of the major issues around reuse is consistency - in tone, layout, metaphor, graphics, etc. If the solution does not easily enable a consistent framework, the skill set of the development team must be commensurately higher to establish consistency manually. This prevents the use of these tools by SMEs or less experienced developers and further slows down design, development, and QA. These impacts to efficiency are further exacerbated by the lack of rapid development features found in the more sophisticated individual authoring tools - features including PowerPoint import, themes, WYSIWYG templates, and sophisticated integration with third party media and simulation.

Furthermore, to effectively reuse content, the content must be tagged and cataloged, which also negatively affects design, development, and QA time. Tagging is the act of applying appropriate meta-tags to the instructional element so that it can be easily retrieved by other development teams. Logic dictates that time spent tagging is time that is not spent authoring. In theory, all of these non-authoring tasks are supposed to result in major efficiency gains from reusing existing learning objects in new courses, reducing overall development time. In practice, however, true learning object reuse is not happening at the scale organizations anticipated previously. It's unclear where the balance point is between reuse and development inefficiency; however, it is clear that most organizations have thus far dramatically overestimated the former and underestimated the latter. While these organizations may still be realizing some positive ROI, it is unlikely that it is at a level that matches their original business plan.

Managing the Development Process

In the absence of significant ROI from content development or learning object reuse, another area where LCMS could provide a positive business impact is through the streamlining of the development process, specifically areas like storyboarding, QA, and project management. In team-based development models, these areas are typically project bottlenecks that lead to overall authoring inefficiencies. These are also the areas where individual authoring tools typically provide the least value. Given this, one might expect LCMS users to take full advantage of the aforementioned features in the LCMS. Unfortunately, this is not the case.

One of the most interesting findings from Howard's research is that many companies use LCMS systems primarily to author and assemble content. The three most frequently used features of LCMS solutions are assessments (54%), content authoring (51%), and content assembly (48%). Comparatively few organizations are using the LCMS for storyboarding (13%), project management (13%), workflow (12%), or bug tracking (7%) features (Howard, 51). What this data suggests is that LCMS platforms are primarily being used as enterprise-wide authoring tools rather than true team-based authoring solutions. This corresponds to the buying criteria noted above; if 77% of buyers ranked content "reuse" as their number one criteria, it's logical that these same buyers would be primarily interested in authoring.

It's unclear why these more advanced LCMS features are under-used. One could speculate that organizations that are primarily interested in authoring solutions lack the maturity to see the value in these sorts of features. It could be that the features themselves are inadequate and not yet mature enough to meet the needs of the development teams that rely on them. Howard's research suggests that feature immaturity is at least partly to blame: According to the Bersin study, only 37% of responders were satisfied with the workflow features of their chosen LCMS (Howard, 58). Perhaps storyboarding, project management, and bug tracking are similarly challenging. Whatever the cause, it's clear that LCMS solutions are not solving the processrelated challenges facing the average eLearning team. Howard's research seems to suggest that LCMS solutions do little to simplify design, project management, or QA. Indeed they may even complicate it by requiring the adoption of new development methodology, like meta-tagging.

Integration with Other Tools and Systems

Over the last few years, LCMS solutions have increasingly tried to become an end-to-end solution by providing features more typically provided by an LMS. While the reasoning for this is clear, it is still the case that most enterprise-level LMS solutions offer far more advanced learning management features than most LCMS solutions (Howard, 9). It is also usually the case that organizations contemplating an LCMS already have an LMS in place. This can often result in confusion among buyers and a further diminution in the value proposition of the LCMS.

Many LCMS now offer dynamic delivery of the content - meaning time-of-need assembly and delivery of relevant content. This type of usage pattern, however, is not one that is tracked and managed by an LMS - it needs to be managed by the LCMS. Organizations that use this feature must therefore make a decision about tracking learners in two different systems (one for static delivery and one for dynamic delivery) and presenting learners with two different learning portals. These organizations also must often choose which system will be the reporting system of record. In cases where courses are exported for administration and management through the LMS, this also means that the LCMS is essentially being used as a publishing platform for static courseware. As a result, content updates still require a republish and repost before they can be seen by a learner, the same model used by individual authoring tools.

All of these decisions and overlapping feature sets lead to confusion among those implementing LCMS solutions. Organizations large enough to truly need an LCMS authoring model are also typically large enough to need a full-featured, robust LMS, often with a performance management component. This in turn means that they will likely adopt a publish and post model for development which renders moot any dynamic delivery options in the LCMS and diminishes the value of the LCMS solution.

Another area where LCMS typically have integration issues is with more advanced eLearning content like simulations, externally-built interactions, or non-standard file types. While most of these content types can be integrated into the LCMS as a SCORM object, there is typically no communication between the object and the course. Today, LCMS is still mostly about assembly of existing assets. Enabling an externally referenced media element to communicate with the course is currently outside the functionality of all commercially available LCMS. Yet, this is an essential feature.

If an organization wants to integrate Raptivity interactions or Firefly or Captivate simulations into a course, it's likely that these interactions will need to communicate with the course. A simulation, for example, should communicate - at a minimum - completion status or a pass/fail status. Flash interactions might communicate the overall percentage completed or even pass resulting values back to a course. These various statuses could be used by the course to determine which pages come next or to send combined results to the LMS for reporting. In the absence of this sort of communication, LCMS solutions are not providing an adequate course "backbone" from which more sophisticated learning materials can be launched. As eLearning evolves, these niche-specific interventions will become even more sophisticated and numerous, leaving the LCMS-bound instructional designer with increasingly less flexibility in leveraging the latest advances in interactive and engaging content.

Another integration challenge with niche media elements is maintenance and update. One of the central ideas promoted by LCMS solutions is ease of update and maintenance, particularly as it relates to global search and replace. The basic message is that a database backend makes global search and replace a reality. But as with reuse, this is much more problematic than it first appears, particularly with media content.

Output and development files for niche media or interactions are typically separate physical files. Most LCMS solutions, however, do not manage source files; they only manage runtime or output files. What this means is that organizations that use any interactive elements or media files that require external editing software must manage the source files outside the LCMS. When it's time for updates, these source files must be found and managed and updated in the same manner as they would be if there was no LCMS in place. In the case of external media elements, central updates means reworking the source material and then reposting to the LCMS. This also means that developers are unable to realistically do any sort of global search and replace. Instead, developers need to open and work with each individual media element in its native authoring tool. Search and replace will still work across LCMS content, but this is typically the least engaging and least interactive sort of content, and a well-designed course should contain fewer flat pages in favor of more interactive elements. In an LCMS model where search and replace is important, this would push development decisions toward less interactive, lowest common denominator content rather than interactive, engaging material.

Implementation

While some LCMS implementations can happen in under two months, the typical implementation cycle is two months or more with 38% of all implementations taking 6 months or more (Howard, slide 26). If one of the most important criteria for a modern development team is a "need for speed," a nine-month-long implementation cycle does not contribute to success. LCMS implementation, like LCMS usage, can be involved. Depending upon which features will be used by the organization, the implementation may need to define taxonomies, workflow rules, administrator rights, and a host of other usage-related issues. Server architectures need to be built and IT staff must be assigned to implement and support a solution.

Given this complexity, it's not surprising that 16% of all Bersin survey responders ranked successful implementation as the biggest challenge in using their LCMS (Howard, 52). In many ways, LCMS solutions face the same implementation challenges as other database-driven, enterprise-level systems. Change management, organizationally specific customizations, training, user adoption, and ongoing updates and maintenance are just as important with an LCMS solution as they are with other enterprise solutions. Unlike the purchase and implementation of individual authoring tools, LCMS solutions can sometimes take years to fully realize their value (Howard, 53). While not unusual for enterprise systems, this does seems counter to the needs of most modern development teams. What is required is not a solution that will take years to deliver value, but rather a solution that will take weeks or months. Learning organizations are asked to deliver training in extremely rapid time frames and to drive real business results within months. LCMS solutions that take years to realize their value are at odds with the very business drivers that lead training groups to seek out LCMS solutions in the first place.

Summary

For years, LCMS has been the only option for organizations that have outgrown singleton models. Once organizations reach a certain level of development maturity, they naturally seek out ways to streamline their work and to make the overall process more efficient. With the promise of reusable learning objects, embedded workflow, and process and content management, LCMS solutions positioned themselves as the natural evolution from an individual contributor model. In many ways, however, these promises have been unfulfilled. Actual learning objects reuse is significantly lower than analysts predicted, and advanced LCMS features like workflow, defect management, and storyboarding are barely used at all. For all of their promise, LCMS are, for the most part, being used as over-engineered authoring platforms.

Perhaps more challenging still is the failure of these solutions to keep pace with the evolution of modern eLearning development teams. If, as the research suggests, these tools are being used as authoring platforms, then development speed is a top priority. According to Bersin's research, 69% of all corporate training programs can be addressed by a rapid eLearning approach. Yet almost nothing about an LCMS solution is designed for speed - tagging, designing for reuse, managing and integrating external media assets, integrating with an LMS, even implementation - none of these tasks is about speed or about creating content.

What this means is that organizations need to make some sort of trade-off. One trade-off is to sacrifice speed in favor of LCMS usage and the promise of reuse and better management. Another is to complete the project on time at the expense of reuse and management. A third option is to maintain two different systems: one for "formal" learning and one for rapid learning. None of these scenarios benefits the learning team.

Similar trade-offs need to be made in using more interactive elements in a course. To ensure maximum reuse and ease of update, as much of the content as possible should be built directly in the LCMS, but there is an increasing trend toward more interaction in niche development tools, such as Firefly, Raptivity, and SimWriter. Even Captivate-style interactions are significantly more advanced than what is available in most LCMS tools. Once again, the development team must make similar trade-offs: Do they develop the robust and engaging content for their learners using the most advanced tools available, or do they limit themselves to less sophisticated interactions to better maintain and reuse content in the LCMS? Do they introduce additional complexity into the development process by managing separate authoring tools and source files outside the LCMS, or do they limit themselves to what the LCMS can do natively?

For all the hype, promise, and price tag of most LCMS solutions, these are not questions that development teams should be forced to address. The promise of LCMS was to streamline development and make the process more efficient - through reuse, through workflow, and through asset and learning object management. Instead, organizations are left asking themselves how they will use a single, monolithic system to deliver interactive, engaging content in a time frame where it still delivers some business value.

Read part 4: This Chair is Just Right: The Case for Collaborative Authoring