Content Management: When do we need it?

We all use content management to some degree. When we start out our companies we use what I like to call the "unknown folder system". This folder hierarchical system is set up by one person and as the company grows the location of content within the folders is passed on via written procedures or more likely through word-of-mouth.

It is cheap and easy to use when the amount of content is small. As the company starts taking on more projects, developing more products, and hiring more employees the amount of content increases and so does the amount of people needing access to that information.

Posted to an RFP by the District of Saanich, BC Canada (which closes March 18 if you are interested in tendering a bid District of Saanich: Bid Opportunity)

"Information is an important strategic asset for the Municipality of Saanich and like other corporate assets it must be managed in order to meet strategic goals and to deliver programs and services. Increasingly, local governments are fully recognizing the value of their information assets and looking at how standards and procedures can be developed to support decision-making, minimize costs, and maximize the value of information."

Here is a municipality that understands the value of the information they have and the costs involved in writing and maintaining it. But unlike most of us they have 100's of thousands if not millions of tax dollars to take on a large project like this.

So the real question is at what point does implementing a content management system become viable. Well, like I said, you probably already have one. What needs to be implemented is a document system that can be used throughout the evolution of the change in your information as the organization grows. Yes good practices and a core understanding of the purpose of your company and its direction will make that leap easier and cheaper when the time comes.

Questions like "how can we justify the costs of implementing a CMS application", will transform to "how can we not justify the cost of implementing a CMS", which will make the time to act more clear.

In an upcoming webinar hosted by Just Systems called "Transforming Manufacturing Processes through Dynamic Documents" the speakers will be describing how "The static nature [of documents] can result in design, development and maintenance delays, mistakes, rework costs and compliance issues that can rapidly erode profit margins, customer loyalty and time-to-market advantages."

I think this goes to the thought that your documents are not static pieces of paper but living, growing, and changing pieces of information that get used and reused whether or not a process to take care of your documents has been defined. By ensuring a document process is put in place and all people in your company know where to find information, how to request changes, update, and distribute new content, and who has the permission to manage the content you will be well on your way to having a viable content management system. Adding the software to automatically manage the content will only come when core principles of the organization require it.

CMS or Version Control - which one for documentation?

Version control has been and is being used by 1000's of companies to manage their software design. Software programmers check out files from a server to their local client. They can then, make changes and update or check the files back into the server at any time, as long as the connection between the client and the server is available. The version control software keeps the change history. Version control is often used by the documentation department of small companies to track the changes in documents. So why would anyone need a Content Management System (CMS) to look after their documentation? I believe now that CMS tools are becoming more available and cost effective this questions is being seriously asked but the habits of the past are making it hard for us to justify the cost of the change.

In the 60's and earlier technical writing was a very narrow field, comprised mostly of defense and aerospace documentation content writers. It wasn't until the age of the personal digital computer and the explosion of software applications that the technical writer became an invaluable person in the design, distribution, and marketing of these new products. Before this age documents were paper based, stored in boxes. Design history was a function of process and procedure, tracked by a paper-driven system. Even as late as eleven years ago I can remember clearly the physical effort involved in updating a procedure or manual. It required:

• many trips to the active and archived document filing system
• the walking around of drafts for sign-off
• walking around beta for testing
• filing drafts
• archiving current documents to a physically different filing cabinet located in a different room
• holding a release meeting to have the traveler signed off by all officials
• filling the final released document to the active document location.

The process itself is not unlike what is used today, but we did not even have internal email so every question, response, check, and issue had to be physically walked from person to person.

As computer memory increased and word processing applications became more accessible the ability to store documents electronically became more feasible, but the systems that were available to the average company where for tracking the history of code changes. Using version control to track document changes was really a stop-gap solution with no alternative.

I don't know the exact history of CMS applications but I do remember witnessing the increase in hype amongst the technical writing community with respect to XML and CMS about 9 years ago. With the responsibility of a technical writer changing quickly, the hype was more of a plea for a solution to be able to organize, share, and search the increasingly growing size of paperless content. Content writers where now often responsible for coding (HTML, XHTML, XML, JavaScript, CSS, XSL), designing (print, web, help, training, blogs, FAQ's, knowledge base), doc management, graphics, web marketing, regulatory, usability, user validation, applications expertise and evaluation (Word, FrameMaker, WebWorks, RoboHelp, Flare, CMS software, bug reporting, version, screen capture, publishing, e-mail) and finally publishing.

And again I ask, "what is the value of a CMS to a company?"

Content is not code. Software code is written for a specific function, used in a specific location, in response to a specific action or inaction of the hardware, user interface, or the software itself. Content is the description of a concept or procedure that can be used in multiple ways to define a product or company. The design of software code cannot be changed without a consequence to the quality of the product. The content can be written in multiple ways to mean the same thing or sometimes written exactly the same to mean something completely different. The consequence of changing content may or may not affect the quality of a product. At best it is merely inconsistent.

Kevin Ballard of L-3 Communications says, "CMS allows authors to maintain unique names" as well as "maintain the [relationship of] links" between document files. I believe he is right and here is why. As the volume of the content increases, the location of specific wording becomes impossible to track and remember. Content reuse is only possible if the relationship between the new document and the current content is known.

File Relationships
In a version control system files are checked in to a files system designed to store code. The file is checked out to any location on a clients computer. In a CMS system the relationship of file system is maintained when files are checked out. This means that when ditamaps are created for XML files or images used in marketing are imported into a user manual, the relationship is the same on the authors computer as it is when it is checked in. The knowledge of where a file is stored is related to the file it is linked to, not the absolute file location.

Unique Names
Files saved to a version control system use specialized naming structures to meet coding standards. This nomenclature often makes it difficult to determine the actual content or purpose of the document.

Metadata
Another very important functions of a CMS is the ability to search for and find information using metadate. The term "information mining" is become very prevalent in this age of information. The more products and models, the more content that is created and the harder it becomes to find pertinent information. Text files and some word processing files can be easily searched but binary files like jpg, cdr, and quark files cannot.

In a CMS environment files can be categorized using metadate so that the information can be quickly grouped and located. For example, lets say we are a moderate sized medical device company that has 80 products on the market. Within those 80 products there are three target markets (hospitals, government, and personal use). How would you search for all products that can be sold to both the hospital and government market? Well if it was a Word document and you happen to put the target market in the document content then you will find those with a simple search using Windows Explorer, but what about marketing documents designed in Quark or Indesign, or jpg images, FAQ responses in XML, and HTML help topics?

Result
As the amount of content in a company grows over the years, the ability to find specific information becomes more difficult. Without a way to search content across an enterprise, information is lost and then re-written causing similar products in current release to have different wording. If technical documentation is explained differently in different documents there is a potential for misinterpretation, incorrect product use, product failure, product damage or worse, injury. If updated in one document but not in all locations this content resides the problem can continue to haunt the company. The location of all content must be known to ensure consistent, reliable documentation and guaranty the reliability and trustworthiness of a company. Companies are built on brand, brand is built on trust and trust is not implied or expected, it is earned.

The CMS system is a tool required for this information age. Without this type of tool there is little hope of finding our way through the mountains of information we create every day.