Choosing a Content Management System

With hundreds of tools for content authoring, reviewing, translating, and publishing available on the market today, it is not easy to choose the right solution.   

Working closely with leading vendors, WritePoint remains vendor-neutral. We evaluate different tools and recommend the one that solves your needs in the most effective way.

To identify and analyze your content management requirements, we use a process-based approach. We analyze the processes in your company and check how these processes are supported by various CMS applications.

To learn these processes, we write business scenarios that describe the way people work with content. We write these scenarios iteratively, knowing that we will often discover (and uncover) more details with each iteration, and identify specific requirements.

For example, let’s assume we wrote this initial scenario:

“Ann is a technical writer. She authors content in DITA. After she finishes writing a user manual, she sends this manual to John, a software engineer, for review. John does not know DITA. However, he somehow edits the content, if necessary. When John finishes his review, he sends the manual back to Ann. Ann accepts or declines John’s changes. Then, Ann sends the manual to Sally, a project manager. Sally can only annotate the content, she cannot create new content. She sends the content back to Ann. Ann incorporates the comments as necessary and sends the manual for final approve to John and Sally again. If they approve the manual, Ann sends the manual to the client.”

Based on this scenario, we can identify the following initial requirements:

  1. This company’s CMS needs to provide reviewers with the ability to perform their task and work with the source material even if they do not know DITA. The company may want to consider using a web-based editor in which reviewers work with predefined forms.
  2. The ideal CMS solution enables the company to define different role-based permissions so a project manager cannot add new content.
  3. Because the review process can include multiple iterations, revision rounds must be tracked and versions saved.
  4. To avoid dealing with multiple versions, and possibly having someone inadvertently working on an older version, all content is to be stored in the central repository. When a technical writer, reviewer, or project manager finishes their task, an email notification is sent to the next person in the workflow (for example, when Ann finishes the manual, a notification is sent to John). Then, this person signs into the repository and checks out the document for the next stage in the process.

This scenario and analysis leaves us with a number of questions. It is possible that we might not have anticipated these next questions until we completed the workflow above. Having done that, the following questions might arise:

  1. How are revision rounds assigned version identification? Should it be 1.0, 2.0 or 1.1, 1.2, or something else?
  2. Should John be permitted to review Ann’s manual while she is in the process of writing it? If he is allowed this flexibility, how can the company avoid having John or Ann override each other’s work?
  3. Should John be informed about any changes that Ann declined?

When we get answers to these questions, we have to rewrite the scenario adding more details and, therefore, refining and expanding the requirements. The end product is a series of scenarios that describe different processes and detail requirements for what the CMS solution is to support and how it is to be implemented.

Using this approach, we can ensure that the chosen CMS fits the actual needs of a company and supports its processes.

To receive professional advice, call us at 02 571 6668 or send an email to This e-mail address is being protected from spambots. You need JavaScript enabled to view it to arrange a meeting with a consultant.