About 4 months ago I watched a learning and development manager and a technical documentation lead have a 45 minute conversation on the best content management system for a company. They are both highly intelligent people trying to do highly important work. However, they were essentially having a conversation about completely different things even though they used similar terms and acronyms.
This conversation has been stuck in my head for a number of reasons, but primarily because it seemed to me on the surface to be a standard software argument between the learning and development manager of a company and the technical documentation lead. In actuality, however, the two were arguing about the nature of content and what it is supposed to do. And they were both right.
They’re solving different problems
Learning content is an experience. It starts at a point, progresses through the middle to an end. It is molded in some way to deliver the learning experience that it is. It is designed to do something with the learner. It is designed to change behavior, build skills, test the learner in some way. The system around the content is also designed in a specific way. The content is worked through in a sequence. The content is assessed in some way. The learner’s progress is recorded in some way as they go through the content.
The Technical Documentation team on the other hand treat content as a database of facts to draw from as required. A single warning label, a single procedure or a detailed technical specification that can be reused throughout twelve different technical manuals written by different people within the organization. None of these items are ‘guiding’ the learner through an experience. They are factual information to be used by the learner at the correct time, in the correct context.
However, these are not trivial differences between two tools that could satisfy the needs of both teams. In fact, the way in which a Learning team works with content in order to support their customers’ goals and in order to achieve their own goals is supported by different architectures for different types of content than those which support the goals of a Technical Documentation team and their customers.
Where the systems actually diverge
Most Learning Content Management Systems (LCMS platforms) are focused on the learning object and therefore authoring, workflow and distribution of learning content is all focused around that learning object. This also means that they typically interact with other systems such as Learning Record Stores (LRS) and Learning Management Systems (LMS) and can track things such as xAPI, SCORM and other completion statistics for learners and therefore are focused on the question of the learner: did you do the thing and have we recorded it.
Component Content Management Systems (CCMS) on the other hand are obsessed with a single chunk of information (or content object) that can be used repeatedly in many deliverables. A single warning for example can be used for all products in a company, in all languages. The biggest obsession of these systems is that the information (content) remains consistent. Structured authoring is at the heart of these systems and the ideal is that once information has been published (say the name of a product) it can be updated in one place and automatically published to all other deliverables. However a lot of discipline is required from the start to achieve this ideal and unfortunately most organizations today underestimate the amount of discipline required.
For a more detailed look at the differences between the two systems, it’s worth reading the article by a learning and development manager and a technical documentation lead who spent 45 minutes arguing about whether or not the company should use an LCMS or a CCMS. The LCMS vs CCMS article by the MadCap team compares both learning content management systems and component content management systems.
| Feature | LCMS (learning-focused) | CCMS (technical docs-focused) |
| Core content unit | Learning object or module | Reusable content component |
| Primary output | Courses, assessments, learning paths | Manuals, help systems, PDFs, web portals |
| Key integrations | LMS, xAPI, SCORM engines | Publishing pipelines, translation tools, DAMs |
| Authoring focus | Instructional design workflows | Structured authoring, DITA, XML |
| Reuse model | Reuse within learning paths | Single-source reuse across all outputs |
Reuse!
Reuse of content is supported in both LCMS and CCMS platforms. But again, there’s a huge difference between the two architectures in how they approach reuse. Just as there’s a huge difference between a scalpel and a chainsaw – both are cutting tools but are used for very different types of cutting – so too are there huge differences in how both an LCMS and a CCMS implement the reuse of content.
Re-use in an LCMS (e.g. LMS / LRS integrated content system) is typically to re-use entire learning objects / courses within other Courses, i.e. within another learning program. There is an example of a solid compliance learning object that is re-used within the organization’s onboarding course as well as within the organization’s annual refresher course. This type of re-use is typically very clean and very easy to do, because the learning object / course is being used in its entirety.
The CCMS model is generally organized around the smallest units of content that can be written and reused. In learning content, this would be the learning object or module, reused from course to course. But in documentation, even the smallest learning object – a single sentence or even word – can be extremely valuable if used correctly. Thus, the CCMS is set up to support the reuse of very small learning objects, such as a single procedure or warning, or even a simple caution statement. In an optimally organized CCMS, such small chunks of content would reside in one place (the “asset repository” or “content library”), and then included conditionally in all the places where that content is needed. And in each of those places, the content would be formatted to best effect for the particular output. For example, a caution statement might be displayed in a particular font and color when displayed on a hardware device, but in a completely different format when included in printed documentation for the same product. In this way, a very small piece of content is reused in a very large number of places. Rather than being “reused,” in fact, such content is eliminated – the documentation team does not have to write out the same information over and over again.
Signs your team is using the wrong tool
- You’re manually updating the same information in multiple documents every time something changes
- Your learning team is trying to track course completions inside a general CMS with no LMS connection
- Translation costs keep climbing because translators are seeing the same sentence fifteen times across different files
- Writers can’t tell which version of a topic is the “real” one
Is your authoring tool or documentation tool not working for you or your team? Yes, there are many other tools that may do the same thing your current tool does. However, your current tool is not working well for you and your team.
One system rarely fits both teams
Unfortunately, there is no Learning Content Management System (LCMS) that is perfectly suited for all the Technical Documentation in an organization. Some vendors may claim this, but inevitably they will disappoint. Many organizations have tried to have the Learning and Development team use the same Learning Content Management System that the Technical Writers are using for the Technical Documentation. However, this can be a long and painful process for both teams, and in the end both teams can end up hating the decision that was made for them.
It’s possible to support two different teams with very different views of content with many different systems that honor the single piece of content definition. Yes, this may require your organization to support and use two different systems with possibly two different databases. This could bring about some operational overhead. However, I can promise you that the overhead of supporting two systems would pale in comparison to the cost to the organization and the two writing teams if they were forced to support one system that was not designed to support the two different views of content and the two different workflows of the two teams.
After all this time, they finally ceased arguing. The two groups of people had now come to realize they were trying to solve two different problems. The learning team no longer had to deal with the issue of how the technical writing team could utilize the same systems to create content to support learning within the organization. Instead the two teams could now each utilize their own systems and workflows, to enable each team to do their work to the best of their ability. The two groups of people could move forward, without having to continue to fight over the issue of how to support learning within the organization.
