You may have a long-term goal to implement a component content management system (CCMS) and structured authoring, but you may only have the staff and budget to dip your toe in and wade slowly through the shallow end rather than to plunge into the deep end all at once. Is it possible to break the implementation down into manageable steps?
How do you know if a CMS is right for your organization? Many people struggle to find the answer to this question. Often, these are the questions we hear: Is my content base too small to make it worthwhile? Is the cost of a CMS too expensive for my organization? Is my staff too small to benefit from a CMS? What is the breakeven point for adopting a CMS?
You may be looking in all the wrong places for justification for a CMS. The size of your team, the size of your content base, and the cost of the system may only play a small role in the decision to implement a CMS. The more important factor is: how much will you save in time and costs if you implement a CMS? Here are some criteria to consider:
One of the hardest things to do is to get people to move from their comfort zones. When you begin to implement your content management strategy and move to structured authoring, you will likely see some resistance from a few writers who will say, “That’s not the way we’ve always done it!“ Ah, change! It can bring out the stubbornness in some people and make their boss’ hair turn gray as he drags them, kicking and screaming, into the new work environment.
As we meet people who are just getting familiar with component content management systems (CCMS) and the concepts surrounding them, we find there are a number of common misconceptions floating around. Here are some of the myths we hear most frequently:
A new year is upon us once again, and everyone is making their New Year’s resolutions. Topping the list is usually to get fit by eating better and exercising more. From a business perspective, the start of the new year is also the perfect time to think about ways to improve the fitness of your corporate assets. This year, resolve to get your organization’s content assets in shape, too.
Technical writers sometimes feel like the ugly step-child. They have too much work, and there’s never enough staff to do everything that must be done. And, the work was needed yesterday! In some organizations, the focus is placed on the engineering and marketing of the product, but the technical documentation is merely perceived as an afterthought. Since technical documentation is a cost of doing business rather than a revenue generator, it tends to get the small end of the budget stick.
When thinking about moving your content into a content management system (CMS), there are a few key principles to consider. The first principle is single sourcing. A CMS is a great place to store one copy of your content so that it can be shared with many users. By single sourcing your content, you eliminate all duplicate copies of the content and consolidate your content base down to one trusted source of content. Now, all users who access the content will always get the most current version, and older copies won’t be floating around anymore. In addition, single sourcing your content leads to higher quality documents since the content that is being reused across your publications is current and consistent.
One of the great things about putting your content in an XML content management system (CMS) is that your content is now ready for anything! Why? Because structured content is portable. You can reuse and repurpose your content into many different deliverables for your consumers. Even if you begin by putting technical documentation into your CMS, you can use this content to create many different publications in all kinds of formats. Here are some ideas for repurposing your content:
When writers create content that will eventually be translated into many different languages, they must really focus on more than just good grammar, clarity and spelling. There are a lot of things we say in the English language that doesn’t translate well – or doesn’t translate at all – into other languages. For example, acronyms and slang phrases usually don’t work so well when translated. Americans can relate to being out in left field, but people in countries where baseball isn’t popular won’t understand it.
How many people really read an entire user guide from beginning to end? Or even one chapter? The purpose of technical documentation is to provide the consumer with useful, action-oriented tasks that can be read and understood quickly. But many times the documentation is filled with lots of redundant or useless information that is meaningless to the consumer.
