Choosing a Component Content Management System (CCMS). How to decide

by Mette Lilienthal on June 13, 2024

A CCMS (Content Component Management System) organizes the modular content of technical documentation in a database. Usually, the content is stored in the XML format.

The CCMS manages content, layout, and metadata separately. This means that content can be reused for different publications and different documentation variants can be generated from the same source.

Redaktionssysteme und CCMS für die Technische Dokumentation
Choosing a CCMS for technical documentation

A CCMS provides functions for workflows, including role and rights management, language and translation management, terminology control, variant management, and versioning, among others.

In this article, we’ll discuss when and why you might need a CCMS, which CCMS parson has worked with and what you should consider when deciding on a CCMS.

Table of contents

Do I need a CCMS?

Whether you need a CCMS or not depends on the amount and complexity of your technical documentation. It also depends on the size and make-up of the technical communications department, the translation requirements, and the business processes. Consider using a CCMS if the following factors apply:

  • Your technical documentation is delivered in several versions and variants for which you want to reuse content.
  • Your company delivers products and the related documentation in several languages. The translation processes have to be managed with a structured approach.
  • You use many images, each in several versions and output formats, that need to be displayed in a media-specific way.
  • You deliver information products in various formats and want to automate the publication process.
  • You want to integrate data from external systems into the technical documentation, e.g. product data from a product information management system (PIM).
  • Your authors and reviewers work in different regions and time zones and collaborate on the documentation. You want to precisely control and document work processes such as technical review and approval.

Learn more: Component content management systems (CCMS) for technical documentation

Approaches for selecting a CCMS

There are several approaches for selecting a CCMS. For example, the providers can list all the special features of their CCMS in a functional overview. This way, you can find out which CCMS has which unique selling points.

However, you cannot necessarily judge how well the system fits your needs and requirements based on functions, features, or short product demonstrations. Lists are also only of limited use when it comes to system handling and usability. That’s why parson works with with a detailed requirements list containing requirements from various function categories. We also recommend working with manufacturers' test systems, testing sample content or carrying out a complete proof of concept before introducing a new system.

CCMS requirements

To define the requirements for the CCMS together with our customers, parson uses a requirements lists in the form of user stories. In these user stories, we compile the requirements of the users and answer the most important questions briefly and concisely: Who needs which function, and why?

A user story has the following format:

As a <persona/role>, I need <a function>, so that/because <motivation>.

User story example: content reuse
User story example: Content reuse

User stories in functional areas

The requirements are grouped into functional areas (so-called epics). Typical functional areas are listed here:

  • Content creation: This area includes requirements for the authoring tool, the content format, variant management, and the reuse of content.
User story example: Proof of content reuse
User story example: Proof of content reuse
  • Workflows: Requirements for controlling work processes such as review, approval, publication, and translation management are listed here.
User story example: Review by the development team
User story example: Review by the development team
 
  • Linguistic and terminological content review: These user stories collect requirements for checking and ensuring the linguistic quality of documentation content and authoring tools.
  • Localization: This area includes requirements for translation management and interaction with a translation management system (TMS).
  • Publishing and content delivery: Requirements for the creation of information products and the dynamic delivery of documentation content, e.g. in a content delivery portal, are included here.
  • Interfaces to other systems
User story exmaple: Self service in an information portal
User story example: Self service from an information portal

In addition to functional requirements, non-functional requirements are also important. These include, for instance, the licensing model, IT requirements such as cloud operation or availability as well as organizational requirements such as support service level agreements.

INVEST criteria for user stories

The format of the user stories is simple; but the trick is not simply writing the format, but writing the user stories correctly so that they meet the so-called INVEST criteria:

I – Independent: Is the requirement self-contained and independent from other requirements?

N – Negotiable: As the developer of the software do I know what the user really needs? Can I negotiate different solutions for implementing the requirement?

V – Valuable: Is this function important? Does it have any business value?

E – Estimable: Can I estimate how long it takes to develop this feature? Will it take less than two days?

S – Small: Is this requirement really the smallest increment or could I divide it into even smaller increments?

T – Testable: Can I test the implementation? And do I need more information to find out what exactly is the subject of the testing?

Invest criteria for user stories
INVEST criteria for a user story
 

User stories that meet these criteria detail concrete, specific requirements. In this way, the requirements for a CCMS can be clearly established. The next step is to evaluate which vendors can meet which criteria or user stories.

Learn more about how to write user stories

Prioritize user stories

No CCMS vendor will be able to fulfill all your requirements. It therefore makes sense to prioritize the user stories. Some of the requirements must be met for a CCMS to be eligible. For documentation for many different product variants, one such elimination criterion could be variant management. Other requirements may be useful, but are not essential, e.g. integrated translation workflows. parson recommends the MoSCoW method to prioritize the importance of requirements.

Choosing the right CCMS

The next step in the evaluation process is to identify suitable systems for your needs. Here are some helpful resources for information about CCMS:

  • The vendor websites with data sheets on the functionality of their systems
  • Exhibitions and trade fairs like the tcworld annual conference with the opportunity to demonstrate products
  • Webinars by the CCMS vendors
  • Consultant service providers who have experience with multiple systems

Based on the available sources of information, make a list of all the systems that could be considered in principle, the so-called long list.

From the longlist to the shortlist: CCMS requirements catalog

Since you cannot test many systems in detail, the next step is to identify the best candidates from the long list and create a shortlist. You do this by using the available information to compare which of the systems are most likely to meet your core requirements. You can then make specific and detailed comparisons between the systems on the shortlist and, for example, start a tendering process: Send the fully formulated and prioritized user stories to the CCMS vendors as a requirements catalog. The vendors then provide an answer as to which of these requirements they can meet and how. Many requirements are often already covered by the standard functionalities.

However, some requirements cannot be implemented out-of-the-box and have to be customized. This will cost accordingly. Other features are already being developed by the manufacturers, but are still in the development phase and therefore involve a certain amount of waiting time.

Conflicting priorities of time, budget, and full functional range

When choosing a CCMS, you may find yourself caught between time, budget, and full functional range: If the CCMS needs to be implemented quickly, you may have to sacrifice functions or pay more for the CCMS. Greater customization, which leads to more functions, often also costs more money and/or time.

Time, budget, and full functional range

That's why you should define your requirements as precisely as possible in advance. Then you'll know what effort and costs you can expect.

The importance of sandboxes, proofs of concept, and content prototypes

A CCMS will usually accompany you for many years. When it is introduced, new processes are defined and implemented. The documentation format and document structures are often also changed. The decision in favor of a particular system therefore has a serious impact on the way technical communication works.

To avoid the risk of a failed launch, you can use the following means:

  • Sandbox: Many vendors offer a trial access to their systems. These allow you to try out the CCMS features with some sample content and get a feel for working with the system. Access is often time-limited and sometimes free.
  • Proof of concept (PoC): In a PoC, you test selected requirements from the requirements catalog (user stories) in a system specially provided for you with your content. Acceptance criteria are defined for the individual stories and the functions are tested accordingly. Because PoCs involve configuration and customization work by the vendor, they are usually subject to a charge.
  • Content prototype: If you are changing the information architecture as you implement the CCMS, e.g. because you are switching from documents to modular, topic-based documentation, you should test the planned information architecture with representative content in the new system. The content prototype can also be implemented as part of the PoC.

The money and effort you invest in such upstream testing is money well spent and helps you avoid bad investments in unsuitable systems. You can identify weaknesses and advantages of a CCMS well in advance and thus avoid a rude awakening when the system is actually deployed. In addition, the expenses incurred for the PoC will benefit the subsequent live system so that they will not be incurred again.

Introducing the live system

When introducing a CCMS, you can proceed according to agile principles: You define two- to four-week sprints, in which a certain number of the defined user stories are implemented and tested. This allows you to incrementally implement the functionalities of the system.

At the same time, you can transfer content to the new system. How much you transfer and which content comes first usually depends on several factors:

  • Will there be a new information architecture, i.e. does the content need to be restructured fundamentally? Then, Content Engineering would be necessary.
  • Will you be changing the documentation format? Then the format can be migrated (semi-)automatically if necessary, e.g. from one XML format to another.
  • Are you planning a new product or a new release? Then you can implement this content in the new system first.
  • Do you need to publish existing content from the new system? If not, you can freeze it in the existing formats and make it available as legacy documents. This can save you significant migration costs.

Market overview. Which CCMS are available?

The following are examples of CCMS parson has already worked with (in alphabetical order):

Beyond these, there are many other CCMS from various vendors.

We can support you with the introduction of a CCMS

parson provides vendor-neutral consulting in the CCMS selection. We can help you develop user stories, prioritize them if required and evaluate the vendor’s responses for you. This is how we work

Add new comment

Your email address will not be published.

You might also be interested in

Publish DITA content at the click of a button: the DITA Open Toolkit

by Marion Knebel , Fabian Klopfer on December 07, 2023

Do you write and publish technical documentation in DITA-XML? It sounds easy: At the click of a button, an XML authoring tool or a web application magically creates a PDF, HTML documentation or WebHelp. But is it really that simple? What happens under the hood? And what if you want to customize the output formats? The answer is the DITA Open Toolkit (DITA OT). more...

gds and parson partnership adds information architecture to its portfolio.

August 16, 2023

gds and parson have expanded their cooperation: customers implementing an information management solution from gds can now draw on parson’s many years of experience in modern and sustainable information architectures. With a solid information architecture as a foundation, companies will maximize the potential of their component content management system (CCMS) and content delivery portal. more...