For organisations hoping to implement content management systems (CMS), there are many resources available to help plan, coordinate and deploy them. But there are few resources that study the various disparate considerations of a CMS in isolation. Case studies that specifically, focus on distributed authorship and the CMS, for example, simply do not exist. These types of studies are needed and necessary components of the decision-making process for organisations, especially when considering the resources involved in deploying a CMS.
Content management systems (CMS) are large software platforms that evolved from the idea that companies manage their information by storing it in a central repository allowing them to retrieve and deliver it in multiple formats for multiple purposes. Although failing to find any specific numbers stating how many companies now use CMS, the number of available systems to choose from (according to cmsmatrix.com) is well over 200. And as the CMS has gained in popularity, it has come to realise much of its speculated potential. While there was almost a deterministic quality to many of the early articles concerning the CMS, all of them correctly speculated that the CMS would change the way professional and technical communication was carried out in the future.
More specifically, CMS has brought technical communicators closer to their role as database miners – information developers who raid databases to gather content for communications (documents or online help systems) assembled later (as suggested by Albers, 2000). They have also delivered the promise of structured content, documents that live as disparate pieces of text combed through, selected and then used to create multiple types of information units in multiple forms of media from a single source. And they have delivered distributed authorship, giving organisations the ability to enact collaborative activities through time and space with content contributors working miles apart. Much of what is written about the CMS pertains to the mechanics of the system: how it works, its functionality, its cost or ease of use. However, as noted by Anderson, these items are really the simplest component of the system, because they can be easily modified.
If a software tool within the CMS is too slow or does not offer enough functionality, that tool can be replaced or the source code can be rewritten so that the functionality exists and the tool performs faster than before. However, human factors are much more difficult to identify and then to “fix.” Authors may not come out and tell us exactly why they are not using a system. In our case, we must approach this question from a number of different directions until we had a broad and specific understanding.
The steps to “correct” the “problem” were also difficult, requiring numerous interventions and components. Understanding the human factors involved when integrating a CMS is perhaps much more important than understanding the differences between the many varieties of CMS available. After all, if authors do not “buy in” to a system, it matters little what tool you give them.
Albers, M. (2000). The technical editor and document databases: What the future may hold, Technical Communication Quarterly, 9, 191-206