Scott Wahl, Research in Motion, Ltd.

Part 1 of 3 – Laying the Groundwork

With all of the buzz these days about content management, it can be easy for technical communicators, and especially managers, to feel the need to rush into buying or building a content management system. The pressure to keep up with our peers can be enormous. Yet any content management initiative is bound to fail if your department is not ready for it. Even if you manage to implement a new system, you’ll find yourself not much farther ahead than where you are now – and having spent a lot of time and money in the meantime.

Too often, especially in the high-technology sector, we expect new systems and tools to fix problems that can only be fixed by looking at people and process. A new system is no panacea. Implementing any system will not only require a lot of time and money, but will add work and pressure to teams that probably already feel overloaded with projects. Before seriously considering a CMS, you need to make sure that your team is ready to plan and implement a CMS successfully, and ready to take advantage of the CMS once it is in place.

So ignore the hype. Take an honest look at your own department and then decide whether the time is right to look at a content management system.

Work Environment

Implementing a content management system requires a significant commitment from your department to learn and work together. Roles will shift over time, and new roles will emerge. People will be put under pressure to continue to meet project deadlines while learning new tools. People will have to define new ways of working.

If your teams do not work well together, you should focus on addressing those issues first. Make sure that people’s roles are well-defined, people have challenging work, and people understand how their work contributes to organizational goals. Any tools are only as good as the people who use them – so focus on people first.

Your department needs to go into any content management initiative with a collaborative, positive work environment. Even the strongest of teams will be put to the test – weak or ineffective teams can collapse altogether.

Openness to Change

Your team must be open to change – even excited about it! If people don’t see the need to change the way they work, they are not likely to support the fundamental changes to their tools, processes, and roles that a content management system will bring with it. Any new system represents a threat to some people and represents a significant amount of work for everyone. Implementing a system will only be successful if people feel that the system addresses things that are frustrating them– such as the time it takes to publish documents in different formats, the effort of getting documents translated, and the inability to respond to customer demands.

The worst thing you can do is to try to force a system into a department that doesn’t want one just to meet your own objectives or those of senior management (such as reducing costs). Any system must meet, and be seen to meet, the needs of the people who will have to use it day-to-day. People will be much more likely to work through the inevitable challenges of implementing a new system if they really see the value it will bring to their work in the end.

Change management is an ongoing process, but it needs to begin at the beginning by involving the team in any decision to start a content management initiative in the first place.


Your department should have dedicated editors, or at least a very well-defined peer review process and standard tools and templates that all writers use consistently. Writers must be comfortable working collaboratively with editors, information architects, and other writers on their content. In a content management system, after all, writers are required to give up a significant amount of ownership over the structure and format of their content. The benefit is that writers can spend more time understanding users and their goals and developing high-value content. But if writers are still used to working on their own books in their own style and templates, the move to a content management system will simply require too great a leap. You won’t pull it off.

Moving into a CMS requires that content is very standardized in terms of structure, content and style. If your department does not already have a well-defined style guide and templates which writers actually use and editors enforce, any CMS initiative will be a waste of time and money. The cliché “garbage in, garbage out” applies. Garbage will continue to go into a CMS if the people, processes, and culture are not in place to review, revise, and improve content on a continuous basis.


The department must have standard processes defined for planning, creating, translating, and publishing content—and those processes should actually be followed by writers and editors on a day-to-day basis.

With a CMS, there is an opportunity to define standard workflows. Most (if not all) formatting and desktop publishing activities will be taken out of writers’ hands and automated. Writers will resist this change if they are not already used to working within a group that follows (or tries to follow) standard processes for developing, translating, and publishing content.

Implementing a CMS also puts more emphasis on content planning. Once you are working in discrete topics (or even smaller chunks of content), writers absolutely must plan their content and review it with others before starting to write. If writers are not already in the habit of producing documentation plans, defining document outlines, and communicating with their team on schedules, there is little chance that they will be able to make effective use of a CMS.


If your team has not already made a real effort to implement minimalist, user-focused design principles in their documentation, then this is the place to start. There is no point in implementing a CMS until writers and editors have taken the time to make their content as good as it can be. This doesn’t mean that all content must be perfect. But it does mean that your team must have made a real effort using the tools they have now to improve the quality of their work and get honest feedback from customers and customer-facing groups about their work.

Take a close look at your content. Is it useful? Has it been peer reviewed and edited to make sure it is consistent, conforms to your style guide, and addresses real user goals? Has anyone asked your customers lately what they like or don’t like about your documentation or if they use it at all?

Keep in mind the opportunity cost associated with implementing a content management system. If the content that your department currently produces has obvious problems, you should focus on addressing those problems rather than spending time now on a content management project. A CMS initiative is an excellent opportunity to take a close look at your content and scrub, redesign, and rewrite content to remove redundancy and improve quality. But if writers have not been able to improve their content up until now, what makes you think they will suddenly do so with a new set of tools? Your content needs to be at a certain level of quality before a new system will do much to help. Only you, with input from your team, can define the level of quality you need.

A technical editor I once worked with put it this way: Before building a system to reuse content effectively, you need to make sure that the content is worth reusing in the first place.


Before looking at any type of CMS, consider whether your team has optimized its use of the tools they have now. For example, if your team uses Adobe FrameMaker, are they trying to reuse content by using conditional text and reusing chapter files in different book files? Have they looked at Quadralay WebWorks or other tools to publish FrameMaker books in multiple formats?

Beyond authoring and publishing tools, look at revision control. Does your team use any sort of system now for revision control? Or do writers keep all of their files on their individual computers? If a team is not using some sort of revision control system, however rudimentary, it either means that there is actually no need for a CMS—since individual writers are just working on their own files with no need to share with others—or it means that the team has not yet even begun to try to share and manage content. A content management system in such an environment is overkill at best. If writers are not attempting to reuse and share content now, why would they start doing so in a content management system?

Putting together a business case for a content management initiative is much easier if you can demonstrate that you have pushed your current tools to the limit. If your team has not tried to work smarter with the tools they have now, then there are almost certainly some straightforward and inexpensive changes you can introduce without investing in a content management system.


Before you embark on a content management initiative, consider carefully (and honestly) the current state of your department and the work that it produces. You might find that you would be better off spending time putting in place a style guide and an editing process or implementing minimalism or finding out more about your customers and how they use your documentation. There can be significant benefits to a content management system but only if the necessary foundation exists on which to build it.

Answer the following questions:

  • Does your department have a positive, collaborative work environment?
  • Do you have dedicated editors that enforce a department style guide?
  • Does your department follow standard processes?
  • Has your department already tried to improve the quality of its work?
  • Has your department tried to optimize how it uses its current tools?

If you can’t answer ”yes” to all of these questions, you likely have more work to do before proceeding with a content management initiative.

In the next article in this series, I will look at some best practices for planning a content management system, including writing a business case, defining technical and business requirements, setting up a project team, selecting a solution, and conducting a pilot.

Scott Wahl is Director of Software Documentation & Localization at Research In Motion Limited (RIM). RIM recently implemented a content management system based on DITA XML. These articles represent the personal opinions of the author and are not in any way endorsed by Research In Motion Limited.