I want to share with you a few marketing pitches I found on various content management vendor websites:
- “Builds solutions that help technical workgroups simplify the automated creation, delivery, and reuse of content”
- “Delivers robust and feature-rich content management solutions that minimize the costs of content creation and content maintenance, maximize content reuse, accelerate content translation and development”
- “Empowers… organizations to single-source content, easily sharing, reusing and personalizing content in various publication formats and in multiple languages across global markets”
Whom to trust? The one with longer sentences or the one with a nicer web design? The advice we always give our clients: never ask a vendor whether or not they have a feature X. Because lists of features look very similar, this hardly helps you make the right decision.
A more effective approach, the one we use with our clients, analyzes the processes in a company and checks how these processes are supported by various CMSs. 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 comments, if 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 pre-defined 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 edit 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’s possible 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 versioned? 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.