Accounting for the Human Element When Planning for a Content Management System

Clinton R. Lanier

Abstract

Purpose: This article assists technical communication professionals in planning, designing and implementing a content management system (CMS) in their organization. As my organization discovered, few resources exist explaining the considerations involved in such an initiative, and there was a noted lack of information to help us plan for human-based factors affecting its success. This article attempts to fill that gap by relating our experiences.

Method: We first monitored the CMS to understand its use by our organization’s authors. Next, we conducted a survey to understand their perceptions of the system. We then made changes to the system based on the answers gathered in the survey. Finally, we monitored the system’s use once more after the changes were made.

Results: Our study suggested that authors did not want to use the new system because they were insecure in using it, perceived it as too difficult to use, and were unfamiliar with the system (among other issues). We then implemented a more familiar interface, created a version control system allowing them to revert to previous versions if they made mistakes, and created and deployed Web-based video tutorials. Finally, we tracked a noted increase in the use of the system by our authors.

Conclusion: Based on our experience, for future technical communicators considering a CMS, I suggest involving those affected as soon as possible, implementing tools that are familiar, providing multiple methods of training, and creating mechanisms to ease anxiety about mistakes and errors.

Keywords: content management system, distributed authors, organizational change, human factors

Practitioner’s Takeaway

• Content management systems can more easily be implemented when the human-factors are considered first, and technology considerations are made based on the human-based ones.
• Authors using a content management system must feel comfortable with the system, should feel invested in its implementation, and should not be anxious when using it.
• To ensure the above, steps can be taken throughout the process, such as involving authors in the planning of the system, training them throughout the process and providing support after deployment, and providing tools and mechanisms that are familiar to them.

---

Introduction

For organizations 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 organizations, especially when considering the resources involved in deploying a CMS.

This article examines a specific case at a medium-sized (less than 1,000 employees) organization that implemented a CMS (after carefully studying available resources). Among the many objectives of the new CMS was the transition away from a model of consolidated content creation, where a small group was responsible for writing and publishing, to a model that dispersed content creation over a network of distributed authors. However, within a year administrators noticed that distributed authors were not using the CMS, causing the content to become outdated or full of errors. Embarking on a research study, we set to find out how often authors used the system, what they used it for, and why they did not use it more often. Our hope was to implement interventions that would increase the frequency of the system’s use.

The next sections provide a general discussion about CMS grounded in technical communication. Following that is a brief section detailing the methodology used in the case study. Finally, the article ends with a discussion of the results found in the study and the subsequent solutions imposed.

Content Management Systems and the Technical Communicator

Content management systems (CMS) are large software platforms that evolved from the idea that organizations manage their information by storing it in a central repository allowing them to retrieve and deliver it in multiple formats for multiple purposes. This idea stems from the more general mechanisms of Knowledge Management Systems, which are “IT-based systems developed to support and enhance the organizational processes of knowledge creation, storage/retrieval, transfer, and application” (Alavi and Leidner, 2001). In this environment “knowledge” can mean a number of organizationally important categories of data, such as personnel, customer, or financial information. More generally, each system manages information within a particular system, and that information (and the consequential manipulation of that information) is discipline-specific.

For the technical communicator, it is the CMS that has become important because it has focused much more specifically on the type of information that technical communicators are involved in creating, assembling and disseminating. Techniques, ideas and suggestions for managing content (as opposed to knowledge), have been discussed for almost a decade (Hackos, 2002; Nakano, 2002; Rockley, Kostur, & Manning, 2003), but only in the last 5-6 years have commercial software companies (as well as open-source software initiatives) been driving the creation of tools (the CMS itself) that provide the functionality called for by theory (Anderson, 2008).

And in the short amount of time since it was introduced, the CMS has evolved much and it has certainly become prevalent. Although failing to find any specific numbers stating how many organizations 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 realize 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 have 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 (Rockley, 2001). And they have delivered distributed authorship, giving organizations the ability to enact collaborative activities through time and space with content contributors working miles apart (Nakano).

Author-Based CMS Integration Issues

Literature exists on the choice, development and implementation of the CMS (see for example, Jones, Mitchko, & Overcash, 2004; Wiggins, Remley, & Klinger, 2006; Wisniewski & Stenstrom, 2007), and there are also articles which deliver best practice advice for the long term use of the CMS (see Goodwin, Burford, Bedard, Carrigan, & Hannigan, 2006; McKeever, 2003); however, few case studies exist that examine aspects of the CMS in long term use. The point is important, because as organizations transition from pre to post implementation, they will need to understand what issues may arise six months or a year later. Planning for contingencies is only benefited by case studies demonstrating the actual contingencies.

Specifically in the case of my organization, there existed no studies on how a CMS is actually used by its users—or more to the point, by the people who contribute content to the content management system—over a period of time. This gap was important to us when we researched the possibility of implementing a Web-based CMS. While we were confident that it had the functionality we required, we were concerned about its use by the distributed authors who would be writing, editing and generally maintaining information within the system.

Some peripherally-related literature about distributed authorship did help us make considerations about the system. They demonstrated, for example, the need for interfaces based on the authors and not simply the functionality of the system (McKeever, 2003, p. 689; Rockley et. al, 2002, pp. 297-309). We also learned about potential methods for enhancing collaboration between authors while they used the CMS (Rockley et. al, 2003, pp. 366-368). However, we did not know what to expect, and as it turned out, we encountered a number of problems related to the gap in knowledge after the CMS was deployed: authors were not using the system as we had expected them to, and we did not know why.

To help us understand why the authors chose not to use the new system, we designed a small research study to help us answer our main questions. Specifically, we wanted to know:

• How often authors would use the system
• For what purpose the authors would use the system
• Why some authors might use it more than others

Our hope was that the results of this study would help us employ changes that would encourage the authors to more frequently use the CMS as it had been designed.

The remainder of this article relates our experiences in deploying a Web-based CMS, and focuses specifically on the use of that CMS by its distributed authors. The following section discusses the information we were missing, our specific case and a research study employed to help us answer some of our questions. Following that is a brief discussion of the results of this study, and then the changes we undertook to encourage a more regular use of the system.

Case Study Context: Employing a Web-Based CMS in a Medium Organization

In the summer of 2008, my organization directed me to create a new Web site to replace the very outdated, HTML-based Web site in use at that time. The planning committee set numerous objectives for the new site; among these were:

• Facilitate distributed authorship
• Facilitate easy maintenance and updating
• Provide multi-media abilities for authors
• Allow site visitors to interact with content through reorganizing, manipulation and delivery options
• Provide easy retrieval of information
• Provide an easily searched repository of data

In short, all of the reasons cited by Hart-Davidson et al. (2008) that organizations give for transitioning to CMS. Many of objectives focused on the site’s visitors and were established to make the Web site—and the organization itself—more competitive and on par with other similar organizations. However, just as many focused on the creation of content by our authors. These objectives were established to make content creation more effective and efficient across the organization.

Prior to the creation of a new site, we were using traditional ftp access to update the previous Web site. Because our server administrators did not want the login information in too many hands, they restricted access to only a small group of people. Thus, we depended on an outdated model of Web site content authorship.

In this model, one small, central group was responsible for updating, maintaining and sometimes creating content. This was inefficient because it required subject matter experts to transmit changes to this small group who then made the required changes and updates. This often took a lot of time, and overburdened the group with content updating when they were also required to make site-wide changes and updates.

This model was also ineffective because in many places on the previous site, content became outdated, full of errors, or was simply missing. Visitors were frustrated and often contacted subject matter experts directly rather than try to find information on the site.

So it was important for us to give authors the ability to create, update and maintain content directly. Many content management systems can create user groups with multiple users and access control mechanisms. Content creation and maintenance becomes a simple matter of logging in through a Web interface and entering information and data into the system’s editor. Because a Web-based CMS seemed to fit all of our needs, we decided to implement one.

Our structure of distributed authorship put the responsibility for creating, editing and generally maintaining Web site content into the hands of a single person from each of the organization’s departments for a total of 42 authors. The Web site content they were responsible for included any information produced by their respective departments, and included a variety of data and file types, including standard XHTML pages, PDF files, images, Microsoft Excel files, and Microsoft Word documents. Many of the departments also used various forms that either delivered the user-provided information via e-mail or inserted it into various databases.

Our small, eight-person Web development team spent nine months planning, designing and implementing the new Web-based CMS. Because we knew the importance of the distributed author role in the success of our new site, we spent numerous hours in resource development for them. We also conducted literature research to better understand what steps we could take to ensure they would use the system frequently. The specific steps we took to ensure authors were prepared before the system was deployed included the following:

• We designed a comprehensive user manual for the authors that extensively covered the activities they carry out on the Web site.
• We included them very early in the process by giving the information about the project’s status and impact via e-mail updates.
• We selected an editor with an interface structured very similarly to the interface of Microsoft Word, hoping to create familiarity and ease anxiety about a new system.
• Two weeks before deployment we scheduled two days of classroom-based instruction. Through a presentation we explained the new system and the author’s role. We then allowed the authors to explore the new system and get hands on experience.
• After the classroom-training we allowed the authors to interact and “play” with the system for two more weeks before it was deployed so that they could get used to the interface and become comfortable with their new role as distributed authors.

Though we felt we had done enough, eight months after deploying the system—in January of 2010—we noticed how infrequently authors were actually using the system. Though information should have been created or updated, very little changes were actually being made.

Understanding How The Authors Used the CMS

Methods

To find out how frequently the system was being used, we tracked authors over a 32-day span from March 22 to April 22, 2010 (32 days total, 24 work week days) to find out how often each was logging in to the system. Table 1 displays the frequency of logins for the set of authors, while Table 2 displays the number of authors who logged at different frequencies during this time.

Table 1. Mean and Standard Deviation of Logins per Author at the Beginning of the Study.

Mean number of logins per author	3.8
Standard deviation	6.6

Table 2. Frequency of Site Logins per Author Before Changes Were Made.

Number of logins	Frequency
0	23
1	6
2-10	8
< 10	5

Not surprisingly, we were disappointed at the low number of logins per user, and the wide range of deviation from the mean, suggesting that many authors rarely if ever logged in. Content should have been changing frequently to accommodate a number of commonly updated items, like department news and announcements, but these results told us that these updates were not happening.

Our next step was to find out why users were not using the system more often. To this end we created a survey. The purpose of the survey instrument was to:

• Find out why infrequent users do not use the system more often
• Identify what factors authors find difficult about updating/changing information
• Identify what factors authors find easy about updating/changing information

The survey (see the Appendix) was posted on the online survey hosting Web site, surveymonkey.com, for 30 days (April 30-May 30). All users were sent multiple e-mails throughout the month to solicit as many responses as possible. At the end of the 30-day survey period we had accumulated a total of 26 responses from a possible 42.

Questions 1-4 and 8 were required of each respondent and covered very basic information. They were asked so that we may gain insight into how these authors perceived their role as content contributors to the Web site.

In brief, these questions revealed that:

• The vast majority of authors (21) logged in less than 10 times per month.
• Authors were most often updating, correcting or generally maintaining content and not necessarily creating new content.
• They make changes to the site for a variety of reasons.
• Most of the authors (21) stated that it was part of their job duties to change or create content on the Web site.
• Less than half of the authors (12) had performed similar work on the previous Web site.

Participants provided more substantive information in questions 5-7, which focused on why they may have infrequently used the system, and what they did and did not like about the system.

Question 5 was an optional question, and so was answered by 12 participants. Those 12 gave two entirely different reasons for why they infrequently used the CMS. Nine of the participants indicated that they did not change or create content more often because the information they were responsible for did not change very often. Many of these nine were responsible for updating information that concerned federal regulations, and so really only needed to edit or create content when those regulations changed (which did not happen often).

The remaining three, however, indicated that they did not use the system more frequently because they generally viewed it as difficult to use.

Wished this was a little bit more user friendly and be able only (to) use Internet Explorer as the only Web browser since that is what is primarily used on campus. Very time consuming, the user is very limited with not many options.

Because it’s complicated and we’re told to make minor editing only.

It has become more frequent as I learn, but learning took a rather unnecessarily long time on both ends.

Question 6 asked participants what they specifically did not like about using the system. This question was also optional and of the 23 participants, 21 responded. Of those 21, 4 consisted of responses such as, “No opinion.”

The rest of the responses revolved around four shortcomings the authors perceived in the system. Many of the answers combined categories so that (for example) a problem was perceived both about the tool and about the process. The categories and their combinations—as well as the number identified—are shown in Table 3.

Table 3. Categories and Combination of Categories and Frequencies for the Answers Provided by Authors for Question 6

Categories (including combinations)	Description	Example	Frequency
Tool-related	These were concerns relating directly to the CMS itself, including the mechanism used to create and edit content.	It is not user friendly.	3
Limitations-related	These were concerns about the limitations the development team put on the style and layout of content. As well as access limitations to certain features.	The customization is so limited that it’s difficult to emphasize new or important information and draw the user’s eye to different parts of the page.	2
Knowledge-related	These were concerns about the author’s own knowledge limitations.	I’m not familiar with all the features.	1
Process	These were concerns about the process used for creating or updating content.	The process for uploading files … is not transparent. I still have many pages that need to be converted from our old pages on the TCC and this is labor intensive and hence is not getting done.	4
Tool/Knowledge	Combination of tool and knowledge related concerns.	The https: I don’t know how to change this. Also, getting single space between lines of info.	6
Tool/Limitations	Combination of tool and limitation related concerns.	We do not have access privileges to change…headings that appear on the left-hand side of the browser. Every time changes are made and then saved, the program seems to randomly change fonts, italics, bold facing, font size, and much more.	1

Question 7 asked authors what they liked about using the system and was again an optional question. Eighteen authors chose to respond. Of these, two simply said that nothing was easy and one stated “no opinion.” The remaining 15 responses fit into three categories (table 4).

Table 4. Categories and Combination Of Categories and Frequencies for the Answers Provided by Authors for Question 7

Categories	Description	Example	Frequency
Ease of use	Comments focused on how easy the tool was in various ways and for various reasons.	Updating existing pages is straight forward.	10
Familiarity	Comments focused on how familiar the layout of the interface was.	The “MS Word” format is nice.	3
Standardization	Comments focused on the standardization of the process.	The process has been standardized so easy to learn from other users.	2

Results

Even after the steps we took to ensure that authors were trained and familiar with the system, and had time to practice and engage it before going live, we should not have been surprised that very few were even using it. After all, the implementation of a Web-based CMS introduced a new technology into an organization already familiar with a previous technology. The new technology effectively altered the very structure of this organization because it created new responsibilities and effectively a new position in each office (Kahn, 2000). Authors who had previously relied on a centralized system of content generation and maintenance were now faced with a decentralized system that made them directly responsible for the tasks they had previously outsourced.

Understanding this problem is extremely important because as Anderson points out, if they refuse to adopt the new system, it will completely fail. And though, as she cites in her study, many of the proponents of the technology would suggest that the lack of adoption is due to technological reasons—the system is not easy to use, the interface is clumsy, etc.—the “buy in” decision of the authors relies on social reasons.

When new technologies are introduced into an organization, users will decide to adopt that technology based on five different factors (Dayton, 2004; Rogers, 1995):

• Relative advantage: The degree to which an innovation is perceived to produce significant benefits for the user; may be measured in economic terms, but social prestige, convenience and satisfaction are also important.
• Compatibility: The degree to which an innovation is perceived to be consistent with existing norms and values, past experiences and needs.
• Complexity: The degree to which an innovation is perceived as difficult to understand and use.
• Trialability: The degree to which an innovation is perceived to be something that can be tried out before committing to adoption.
• Observability: The degree to which the results of an innovation are perceived to be readily visible to others. (Dayton, 2004, p. 209).

Based on the results of our survey, we concluded that the frequency of use depended on three of these interrelated factors: relative advantage, compatibility, and complexity.

Relative Advantage. Because some users felt that there was little relative advantage to the system, they used it infrequently and only to make very rote or easy updates. Only 4 out of the 23 authors stated that they used the system to create new content while the rest conducted very easy content changes. Further, nine authors only updated content when they had to because requirements and regulations changed: they saw no benefit to creating or updating other information. While definitely related to other issues, understanding the system as merely a way to edit existing content when necessary suggests no perceived advantage to creating new or original information.

Compatibility. The new system was nothing like the previous system the authors had worked with. It required they work with a new tool, learn new procedures and understand a new vocabulary. In fact, the new system was a complete change from the old methods of updating or creating online content. It was no wonder many authors felt the new system was simply not compatible with their familiar methods of authorship or procedures for updating content.

Complexity. Aside from the issues of compatibility, authors were understandably frustrated by learning a brand new interface to go along with a brand new process. All of the authors relied mainly on Microsoft Word as a desktop publishing mechanism and Microsoft Internet Explorer as their primary Web browser. Though the new system used an interface similar to Microsoft Word, it still contained many of the characteristics common to publishing in an online environment, such as no options to have single or double spacing between line breaks. Further, one important feature of the new system—the mechanism used to upload and insert files into a Web page—was only available by using Mozilla Firefox, an open-source Web browser completely foreign to over 90% of the authors. This forced them to work with even more unfamiliar mechanisms to carry out their tasks.

The result of these factors culminated in a reluctance to really use the CMS, or a reluctance to use it as effectively as it could be used. The rationale behind their infrequent use was represented by the results of Table 3 and the various limitations they perceived.

Our next step was to implement interventions that overcame these factors by making the authors more comfortable with the system, by ensuring they had enough resources and training to better understand the system, and by creating the perception of relative advantage in the system. We specifically looked to address the factors in Table 3 as much as possible.

Interventions

We quickly noted that education and training would address factors of both complexity and compatibility—represented specifically by many of the tool, knowledge and process-related issues in Table 3. However, because our staff was drastically cut the year after deploying the system (from eight to three members), we simply did not have the resources to work directly with each author or to provide more workshops about the CMS.

So we did the next best thing by creating a series of very brief screencast tutorials quickly explaining the various tasks involved in using the new system to create, update and modify content. The subjects of the tutorials included:

• Adding new content to the Web site
• Editing existing content in the Web site
• Uploading/Inserting images into content
• Uploading/Inserting files into content
• Linking to other content items or to information outside of the system
• Cutting and pasting from Word documents

To specifically address tool and process related issues, we worked to make both even more familiar and comfortable to our authors. We speculated that if we made the processes and tools as compatible as possible—that is, if they fit with previous and comfortable norms in the authors’ workplace—they would be more inclined to use the system. Specific changes are below.

A New File Upload System. We created a new file upload system allowing authors to utilize Internet Explorer as their browser of choice. The previous mechanism required they use Mozilla Firefox, software most were unfamiliar with, which created anxiety and reluctance to upload files when it was necessary to do so. The mechanism was also integrated into the online editor, whereas before the tool was located in a different place. This made it clumsy to use because authors had to leave the editor, find and use the mechanism, and then return to the online editor.

Cut and Paste Directly from MS Word. We created a mechanism allowing authors to cut and paste directly from Microsoft Word. Through discussions with authors we found out that instead of creating content directly in the online editor, they typically created it in Microsoft Word, and then cut-and-pasted it into the editor. The result was a number of formatting issues because Word will not only transfer text, but also the MS-native formatting. The authors blamed the system for “messing up the layout” when they transferred their content over. We initially asked them to cut-and-paste into a plain text editor and then transfer the content into the online editor. Obviously this was just too complicated and took various steps to complete. The new mechanism allowed them to create content in most any outside system, and then transfer it safely without carrying over the native layout and formatting of the system used. The layout of their content kept more general styles, like paragraph or list spacing, but font size and style was then transformed by our organization’s Web-standard templates.

A toolbar resembling MS Word. We reformatted the online editor’s original toolbar to resemble Microsoft Word, and we included similar functionality. The online editor that the authors were using was in many cases an alien mechanism for our authors. While there were some options that should have been familiar due to their similarity to MS Word (Figure 1), in general it looked and acted quite differently.

An example was the inability for authors to enter single line breaks. Because the editor’s WYSIWYG component was simply a layer on top of the HTML code, line breaks were read as

(paragraph) tags by the system and would then be double spaced—this was an unfamiliar action to our authors and they were frustrated that they could not control the spacing in the text of their content.

Our solution was to integrate a toolbar (Figure 2) with more functionality and options. The toolbar looked much more like a typical MS Word toolbar and included many of the same icons and functions they would find in the more familiar desktop publishing tool they more frequently used.

A new “versioning” system. We created a new “versioning” system, which allowed authors to revert to previous versions of content should they make mistakes while editing. Though truly unnecessary because data is always backed up in the database, this feature would add a level of security about the changes users made to content within the site in the hopes that insecurity about permanent errors would not affect the frequency the authors used the system.

To address issues of relative advantage, we began sending out regular newsletter-like e-mails containing tips and procedures demonstrating how easy and useful it is to create new content. We specifically highlighted reasons for creating new content in terms that fit the context of the authors (for example, we demonstrated that authors could create new content discussing news and items of interest from within their departments).

We also began stressing the importance of their new responsibility through the e-mail, by including site analysis so that they would understand the impact of their content (in terms of how many visitors looked at the pages they controlled).

Intervention Outcomes

In terms of the number of site logins, we have found that they have increased over the tracking we did in March-April, 2010. Tracking for a 15 work-day period—began 45 days after we made all of the changes to the mechanism and deployed the video-tutorials—displayed an increase in the mean number of logins to the system, and a slight drop in the standard deviation (table 5).

Over a period twice as long in March, only 16 people had logged into the system between 1 and 14 times. In this case, 27 people logged in during that time (table 6). More importantly to us, was the number of times people logged in frequently (at least 2-3 times per week) during that period: 15 during the most recent sample versus 6 during the March sample.

Authors are utilizing the system in a more consistent and generally frequent manner. We have not yet surveyed them to find out exactly how they are utilizing the system, but as Rogers makes clear, comfort with a technology is one of the key factors to ensure it is successfully deployed in an organization. Clearly, authors are becoming more comfortable with the CMS.

Informal feedback has been both overwhelming and positive. Authors have told us that they especially enjoy the videos they can access and watch as convenient for them. Our records indicate that the page linking to the videos has been accessed more often, and more time has been spent on it by the visitors (the page is a secure page that can only be accessed by authors). Over a two-month period, between mid-August to mid-October of 2010, the page was visited 351 times, and visitors spent a total of 282 minutes on the page. The previous two months saw 306 page visits and a total of 74 minutes spent on the page.

We have also received e-mails that question or confirm our new guidance on how the tools for the system can be used, such as the following sent in early September by one of the authors: “So does this mean I don’t have to use Firefox anymore?”

Other informal feedback included sighs of relief from an author when I explained in person the addition of the tool allowing them to revert to previous versions should they make a critical mistake while developing content. As stated before, this mechanism was always in place for the administrators, but now the authors themselves had the ability and so their confidence in using the system elevated significantly.

We have additionally seen a dramatic decrease in the amount of support that authors are seeking from us. Previously we were frustrated that some authors consistently asked us to do very routine tasks for them—such as uploading files. Such episodes have fallen from approximately five requests per week to one or two every couple of weeks (we currently have no help ticket tracking system). For those requests we do get, we first point authors to the online video tutorial that demonstrates the task being requested. Very rarely have we had to either do the task for them or demonstrate in person how to carry out the task.

Conclusion

Changes to organizations, especially as it concerns introducing new technologies, create a myriad of effects, most of which are often overlooked when planning for those changes. Though we took many of the right steps—drawn from the advice given in relevant literature—we were still quite naive insofar as the full consequences of switching our Web presence to a Web-based CMS.

The effects of these changes to the members of our organization were especially important, because the new system relied on the authors actually using it in order to truly be effective. As it turned out, many of our authors were less than pleased with the system, and resisted utilizing it. They counted many issues as reasons for not using the system more frequently, but those issues were drawn from specific factors common when new technologies are introduced.

By studying our problem, identifying the specific issues and larger factors, we were able to create an intervention program that better supported our authors in their use of the CMS. By publicizing the changes we made and by demonstrating how easy those changes made the new processes, we dramatically increased the use of the new system. Though we are waiting to conduct another full survey to reliably gauge the authors’ perceptions of the system with these changes, informal feedback has been overwhelmingly positive.

Based on our own perceptions of this case, organizations should make the following considerations when implementing a content management system. These considerations are specific to the human component of any CMS.

Tool-related Considerations

• Ensure new tools closely resemble tools authors are already familiar with.
• Integrate all needed tools into a single mechanism.
• Facilitate integration and use with other familiar systems.
• Create safety and recovery mechanisms to increase user-confidence.

Knowledge-related Considerations

• Provide numerous briefings well in advance of deployment, preferably during planning.
• Allow authors to provide feedback on system and feel like they influence its design.
• Ahead of deployment, provide in-person workshops that focus on the system and the author’s role.
• Give authors time to test or “play” with the system before the system is live.
• Provide lasting support after deployment.
• Desk side support.
• Updated user manuals.
• Screencast tutorials.
• E-mail support.
• Help system/knowledgebase.
• Regular newsletters.

Procedure-related Considerations

• Standardize the process through shared, written policies and procedures.
• Define roles that authors will play in new process.
• Make expectations throughout process explicit.
• Do not give the impression that authors are authors by ‘default’.
• Make the position valuable by stressing the importance to everyone, not just the author.

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 components 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 a not using a system. In our case we approached 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.

References

Alavi, A., & Leidner, D. (2001). Review: Knowledge management and knowledge management systems: Conceptual foundations and research issues. MIS Quarterly 25, 07-136.

Albers, M. (2000). The technical editor and document databases: What the future may hold. Technical Communication Quarterly, 9, 191-206.

Anderson, R. (2008). The rhetoric of enterprise content management (ECM): Confronting the assumptions driving ECM adoption and transforming technical communication. Technical Communication Quarterly, 17, 61-87.

Dayton, D. (2004). Electronic editing in technical communication: A model of user-centered technology adoption. Technical Communication, 51, 207-223.

Goodwin, S., Burford, N., Bedard, M., Carrigan, E., & Hannigan, G.C. (2006). CMS/CMS: Content management system/change management strategies. Library Hi Tech, 24, 54-60.

Hackos, J. T. (2002).Content management for dynamic web delivery. New York, NY: John Wiley.

Hart-Davidson, W., Bernhardt, G., McLeod, M., Rife, M., & Grabill, J.T. (2008). Coming to content management: Inventing infrastructure for organizational knowledge work. Technical Communication Quarterly, 17, 10-34.

Huttenlock, T.L., Beaird, J.W., & Fordham, R.W. (2006). Untangling a tangled web: A case study in choosing and implementing a CMS. Library Hi Tech, 24, 61-68.

Jones, C.P., Mitchko, J., & Overcash, M. (2002). Case study: Implementing a content management system. Proceeding of the Annual Summit of the Society for Technical Communication (pp. 221-224). Arlington, VA: STC.

Kahn, R.L. (2000). The effects of technological innovation on organizational structure: Two case studies on the effects of the introduction of a new technology on informal organizational structures. Journal of Business and Technical Communication, 14, 328-347.

McKeever, S. (2003). Understanding web content management systems: Evolution, lifecycle and market. Industrial Management & Data Systems, 103, 686-692.

Nakano, R. (2001). Web content management: A collaborative approach. Boston, MA: Addison-Wesley.

Rogers, E.M. (1995). Diffusion of innovations (4th ed.). New York: Free Press.

Rockley, A. (2001). The impact of single sourcing and technology. Technical Communication, 48, 189-193.

Rockley, A., Kostur, P., & Manning, S. (2003). Managing enterprise content: A unified content strategy. Indianapolis, IN: New Riders.

Wiggins, R., Remley, J., & Klingler, T. (2006). Building a local CMS at Kent State. Library Hi Tech, 24, 69-101.

Wisniewski, J., & Stenstrom, C. (2007). Content management systems. Computers in Libraries, 27, 17-20, 22.

About the Author

Clinton R. Lanier is an Adjunct Professor of Technical Communication at New Mexico State University. He also owns a professional communication consulting agency, Word One Consulting, in Las Cruces, NM USA. Contact: crlanier@nmt.edu.

Manuscript received 12 September 2010; revised 21 August 2011; accepted 31 August 2011.

Appendix: Survey Used

Question asked in survey	Answers possible
1. How would you describe the frequency with which you use the NMT website to edit or create articles?	Infrequent User (< 4 logins per month) Moderate User (4-10 logins per month) Frequent User (10+ logins per month)
2. What is your primary task when logging in to the NMT website?	Change or update existing pages or articles. Create new pages or articles. Other (please describe)
3. What is the primary reason for editing pages on the NMT website?	Inputting or updating the same type of information that routinely changes (for example, adding or changing job announcements, equipment, etc.) Keeping people up-to-date on office events, news and announcements. Updating information about your office, program or department that has changed. Other (please specify)
4. Is adding or changing content on the NMT website part of your job duties?	Yes No
5. If you answered “Infrequent User” to question #1, why do you not use the NMT website more frequently to create information or make updates and modifications? (optional)
6. What do you find difficult about updating/changing or adding information on the NMT website? (optional)
7. What do you find easy about adding or updating/changing information on the NMT website? (optional)
8. Before using the current NMT website, had you updated/changed information on the previous NMT website?	Yes No