Implementing a Content Management System

Home/Publications/CIDM eNews/Information Management News 05.07/Implementing a Content Management System

JoAnn Hackos, PhD
CIDM Director

You’ve made your business case and management has agreed to fund your project. You’ve developed requirements and selected a system that you expect to meet your needs. Now, what do you do to implement the content management system (CMS) you have purchased? Your CMS vendor is ready to install and configure the system and asks you to define exactly how it is going to work.

Your business case defined the goals you hope to achieve by implementing a CMS. In implementing the CMS in your environment, you must ensure that you meet the goals, especially those that promise cost savings and increased efficiency. Although your initial pilot projects may take longer than average to complete, you must still be prepared to measure your results and evaluate your progress toward your goals. Without measurable results, management may conclude that the investment they’ve made is not paying off quickly enough to justify the expense.

Implementing a CMS often takes longer than you may have predicted in your business case. Management often demands a quick success, pushing you and the CMS vendor to promise to meet an aggressive schedule. Despite that schedule, you may find yourself and your team expending more time than you had calculated getting everything defined before you can tackle a pilot project.

Part of the difficulty in meeting an aggressive schedule comes from deadline pressures around the regular work of your team members. Projects don’t stop for a CMS implementation. Your team members must continue to meet their deadlines at the same time that they work on the new implementation.

If at all possible, try to set aside real time for key team members. If you can assign a project manager full time to the implementation project, the project is likely to go more smoothly and proceed according to your original time frame. If you cannot make a full-time commitment, assign a project manager at least half time or risk derailing the schedule completely.

Ensure that the project manager is assisted by someone who understands the proposed project architecture and can assume responsibility for developing the Information Model that your CMS vendor asks you to define. At the very least, the vendor will ask you for the following:

  • A carefully defined folder structure and a naming convention for the CMS
  • A metadata scheme to categorize the content in the CMS
  • A workflow that moves content through a well-defined sequence of tasks

However, your planning may have included a more ambitious content restructuring. You may be moving from desktop publishing to XML-based content development so that you can style documents in final production by applying one or more style sheets to the unformatted content. You may want to develop new content in a topic-based architecture rather than in a book architecture so that you can more easily reuse topics in multiple contexts or engage in sophisticated conditional processing.

If you are intent on restructuring your content, you will have more work to do. It is generally recommended that you complete your new Information Model before purchasing a CMS. However, if your Information Model is incomplete or still in the formative stages, you will need an information architect and a small team to complete the model before the CMS is fully implemented.

You will also need a leadership team, a group of people who understand the project goals and are dedicated to overseeing a successful implementation. The leadership team is principally responsible for communicating with others in the organization, preparing the way for the changes that will take place throughout the implementation process.

Defining your Information Model

If you are defining a new Information Model, you must define exactly how your writers will create content in the future. Your model should include the standards your team members will use to define information types and content units either in a topic-based XML environment like the Darwin Information Typing Architecture (DITA), a proprietary structure like Information Mapping, or a book-based architecture using a DocBook standard.

Most publications organizations do not have a comprehensive Information Model in place. Most organizations have defined the content creation process in terms of the format requirements of a desktop publishing system rather than the semantic tagging of an XML-based DITA of DocBook environment. Most organizational style guides define terminology, writing style, acronyms, grammar, and punctuation rules but rarely define how content is to be consistently defined among information types.

Even if you are adopting the well-structured DITA model for your content, you must define exactly how the model is to be applied to your organization’s content. DITA provides a basic framework but none of the details of its application. Your Information Model must take the details into account.

For example, let’s say that you want to use the base DITA information types of concept, reference, and task for your new content in the CMS. The DITA model provides some guidance, especially for the task. It does not define, however, how task titles should be written, what to include in a short description at the beginning of a topic, what a context statement or a pre-requisite should contain, or even how to write the first command statement in a numbered step. Each of these content units must be defined by your team members for your particular content. When it is complete, your Information Model should describe in full the content to be included in each information type with the base topic types as a starting point. Even if you are adapting an Information Mapping structure, you must define what you mean by all seven of the IMAP types: procedures, process, concepts, structures, principles, facts, and classifications.

For more details about developing your Information Model for an environment that fosters reuse of content, see the discussion in Content Management for Dynamic Web Delivery1.

Setting up your Folder Structure

The folder structure that you establish in the CMS should be associated with your Information Model and support your plans for sharing common content among deliverables. Content that writers must share across all deliverables, such as copyright and warranty statements, should be maintained at the highest level in the folder structure so that it is easily accessible. Content that writers must share within a product family or subject area should be maintained at the highest level of the family or subject folders.

Many CMS folder structures follow the product or subject area. If you are translating content, however, you may want to set up the highest folder level for language. That way you have parallel structures for all content by language. If your CMS assists you in managing translation workflow, you may be able to automatically identify new or changed topics for translation rather than waiting to translate entire books.

As you define your folder structure, consider how writers will find what they need as they author particular topics and share topics among team members. The more reuse you are trying to foster, the more complex and well-defined your folder structure must be.

Creating a Metadata Scheme

The metadata scheme that you define for your CMS has at least two important purposes: to support the workflow of the information-development life cycle and to support search and retrieval of topics and other content. Workflow metadata may include the names of people who interact with the topic, the dates of their interactions, or the state of each topic from defined but not drafted to completed and released for publication. Such workflow metadata is usually handled directly by the CMS itself.

Product or subject-related metadata may be defined either in an XML or HTML source or defined in the CMS. The subject-related metadata categorizes topics by their information types and other characteristics of the content. You may, for example, categorize a topic by information type (task, concept, or reference), product and subproduct, audience type, or other content details that will help writers search for topics that they want to reuse in a particular assembly. Metadata may be used to send topics to different output media, such as print, PDF, HTML, or help.

Understand exactly how your CMS handles metadata. If you include metadata inside topics, as you can do in the DITA model, be certain that the CMS can search on the categories. Many CMSs extract the metadata from the topic files and manage it within the CMS database for ease of search and retrieval. However, once you export a topic from the CMS, all the relevant metadata must be reassociated with the topic. That action makes the metadata available for online search by users through HTML meta tags or through topic-map associations.

Assigning Roles and Responsibilities

Undoubtedly, you already have established the standard roles associated with your information-development life cycle: content author, editor, and publisher. You may have created special roles associated with planning, estimating, and scheduling projects or managing translation and localization. With a CMS, you will most likely need additional roles to maintain a clean, well-organized database with well-maintained minimal content. These roles include information architect and repository manager.

An information architect is responsible for establishing the overall structure of the content in the repository. If you are continuing to maintain a book structure for your content, you may have few architectural changes from your present structure. You are likely using the CMS to maintain version control of your standard files and automate aspects of the workflow. If you are moving from a desktop publishing system to an SGML- or XML-based model, you may want the CMS to handle the production tasks of applying styles to format the end information products at a batch level. Your information architecture may include a structure for managing content that will be used in multiple deliverables. The information architecture must include a folder structure and a consistent naming convention for your files.

If you are moving to a topic-based architecture, your information architect has a more intensive responsibility for defining the information types on which the topics will be based. In a DITA model, the information types begin with the basics of task, concept, and reference. However, your information model must demonstrate how your content will be structured to support the information types. You may want to subdivide the base information types so that they better describe your content, and you may want to create specialized information types to support content such as error message or API documentation. The information structure in the CMS must account for all the information types and the supporting content that will be used in multiple deliverables.

The repository manager maintains the security of the database, assigning permissions to give individuals access to the folders and files they need. The manager maintains the workflow, assigning individuals to roles and giving those roles responsibility for workflow actions such as authoring, editing, reviewing, and approving.

Because a database can deteriorate over time, your repository manager must periodically check for duplicate or near duplicate topics, ensuring that topics are assigned to information types and workflows so that they move through the information-development process.

Defining your Workflow

One considerable advantage offered by your CMS is an automated workflow. An automated workflow helps to move content through the life cycle from authoring through final production and delivery. Many organizations invest in a CMS for the workflow benefits, especially if the workflow includes moving content through translation. I recommend beginning with a simple workflow and adding complexities as you better understand how to apply the system. Ensure that responsibilities for roles in the workflow are defined for groups rather than individuals. You don’t want an entire workflow halted by someone’s absence.

Not only can you use a workflow system to send content from author to editor to review and so on, you can also implement actions that take place automatically. For example, you may define a process that applies a style to an XML topic and produces a PDF output. The process sends a notice to a reviewer or approver that the topic is ready and provides a link to the topic in the repository. Comments from several reviewers may be combined on the same PDF and sent to the author when they are complete. One organization, using conditional text to manage content variations among product families, produced PDFs with marginal annotations that identified the conditions that applied to each variant paragraph so that the reviewers could easily distinguish the differences.

If your CMS has a tight integration with a translation management system, you can develop a workflow that sends approved topics to the translator as soon as they are ready instead of waiting until an entire deliverable has been completed. The topic appears in the workflow system of your localization service provider or internal localization coordinator to be prepared by the computer-assisted translation tools for the translator. When the topics are translated, they are posted back to your CMS for final production, eliminating the desktop publishing tasks provided in the past by the localization service provider. The reduction of desktop publishing tasks can result in a significant cost savings.

Your CMS may also be able to distinguish among topics that have been changed, new topics, and unchanged topics, sending the new topics for new translations and changed topics through translation memory and partial translation, as necessary.

Setting up your Pilot Project

As you finish your Information Model, establish your folder and file structure in the CMS, set up an initial workflow, and create a metadata scheme, you are ready for your pilot project. In fact, you may begin your pilot project before you have finished making all your CMS structural and modeling decisions so that you can test your ideas on a small scale before finishing them.

Your pilot project selection is based on criteria that you establish with your team. You may decide, for example, to develop a pilot project on content that has the following characteristics:

  • minimal legacy in a previous system
  • a high priority that may lead to a strong return on investment
  • handled by skilled and enthusiastic team members
  • able to be completed in a reasonably short time frame, i.e., between 3 and 6 months

You need to think carefully about the business case you made to win funding for the CMS. If your pilot project provides an early win, you will gain momentum and convince doubtful stakeholders that the project will be successful.

Be certain that you have scheduled training in alignment with the pilot schedule. You do not want to offer training too early. People forget what they learned if they don’t apply the new skills soon. Your pilot staff may require training on new tools, information structure, metadata, structured authoring, workflow, conditional processing, content reuse, and the CMS itself. Ensure that you have support from your vendors throughout the pilot process to resolve problems and clarify how the CMS should be working.

Measuring Results

Your original business case should have included a method for measuring the success of the proposed CMS implementation. You may have promised that the CMS will help your organization to

  • decrease time to market
  • decrease the cost of translation
  • reduce the amount of content being maintained
  • reduce content duplication
  • make reviews more efficient

Your pilot project should show progress toward your business goals. One project, for example, succeeded in reducing translation costs by 40 percent because the same content was used in multiple deliverables and only the master topics were translated. Another pilot project resulted in a 25 percent decrease in authoring, editing, and production time because of conditional processing and a more efficient workflow.

After the end of the first pilot and through the completion of subsequent projects, be prepared to continue measuring results. An organization that was challenged to reduce total word count in the repository by 30 percent achieved a 21 percent reduction in the first year and was able to promise additional reductions in the second and third years after more of the legacy content had been restructured.

A CMS can provide many cost savings to your organization but only if it is well planned and executed. The better your preparation, the more successful your implementation will be.

1 JoAnn T. Hackos, Content Management for Dynamic Web Delivery, New York: John Wiley & Sons, 2002.

We use cookies to monitor the traffic on this web site in order to provide the best experience possible. By continuing to use this site you are consenting to this practice. | Close