A Study of the Role of Culture and Communication in the CMS Adoption Process
Information development groups are increasingly adopting component content management (CCM) technologies to efficiently author and manage content objects. Successful adoption of these technologies, however, requires a continuous exchange of knowledge, skills, and processes across vendor and information development group boundaries. Having an overly simplistic view of technology diffusion and insufficient training and resources, many groups struggle to achieve their CCM adoption goals. In this article, I describe some of the planning and learning challenges that one group faced when attempting to evaluate and adopt a CCM system, highlighting the role of culture and communication in that process. I end with specific recommendations for information developers and vendors.
This article highlights some of the findings of my 2006–2007 study of a Technical Documentation Department’s trial of an on-demand, component content management system (CCMS). The vendor intended for the trial to last three months; after six months of communication breakdowns, technical problems, and not making progress toward achieving trial goals, the department abruptly ended the trial and decided not to adopt the system. The vendor spent thousands of dollars on the trial and, in the end, was not able to secure a contract. Though the Technical Documentation Department did not lose a lot of money, they did lose six months of invested time and resources; the outcome of these six months was frustration and little progress toward understanding how best to transition to a single sourcing (SS) methodology supported by a CCMS. This article provides rich insight into what accounted for the failed trial.
At the time of the study, Technical Documentation was responsible for all product documentation for Smith Manufacturing, a Fortune 100 company specializing in heating, ventilation, air conditioning and refrigeration (HVAC&R) equipment and systems (to protect the identity of my study participants, all company, personal, and software names have been changed to pseudonyms).
The trial of the CCMS presented Technical Documentation a low-risk, low-cost opportunity to evaluate a CCMS and determine how best to approach their transition from a traditional desktop-publishing environment to a single sourcing content management (SSCM) environment. The trial also gave the CCMS vendor, a software company that claimed to have the leading CCM solution on the market, an opportunity to demonstrate the value of their product and potentially secure a new customer.
The findings of this study suggest that culture and communication play a big role in the outcome of a SSCM project. Information development groups moving to SSCM need to develop strategies for overcoming the cultural and communication barriers that can impede progress toward achieving goals and producing desired results.
As most information developers are aware, SSCM has forced a paradigm shift in the practice of information development and management; this shift is the move away from a desktop-publishing paradigm to an object-oriented publishing paradigm, which focuses on creating content at a granular level (for instance, paragraph, sentence) rather than at the document level. Driving this shift are customer demands for content in multiple formats delivered for a range of media, as well as organizational pressures to cut costs and increase process efficiencies.
Transitioning to SSCM is no easy feat. Making the paradigm shift requires information development groups not only to adopt new tool sets, but also to reconceptualize the business, communication, and information development processes on which they have long relied. Consultant and industry analyst groups continually see SSCM projects fail due to an over-reliance on tools. They thus warn information development professionals that implementing and adopting new tools is just a small part of a successful SSCM project; SSCM is a cultural change that is about people and processes; technology is part of the equation for sure, but it is not the full equation.
Despite a growing number of SSCM best practices resources and an increased focus on process and change management, many information development groups continue to experience problems throughout their SSCM transition projects, particularly in the CCMS evaluation and implementation stage. My research suggests that an overly simplistic view of technology diffusion is largely to blame. Technology diffusion is the process by which a new technology, such as a CCMS, is communicated or “diffused” to a target group, such as information development, and the process by which that target group adopts that new technology (cf. Attewell, Charlton et al., Fichman, Geroski, Ortt, Rogers, Shampagne). Both vendors and information development groups tend to view the diffusion of CCM technologies as a hand-off process rather than a dynamic, complex communication process mediated by the values, histories, rules, structures, languages, habits, and existing tools of the organizations of which the groups are members. The hand-off view of technology diffusion appears throughout vendor marketing materials and presentations and, when combined with management pressures and eagerness to implement SSCM, often leads information development groups to adopt a similar view.
Technical Documentation’s trial of the on-demand CCMS offered me an opportunity to study how the information development group and the vendor viewed the CCMS diffusion process and how their views guided their respective approaches to planning for and carrying out the trial.
Research Goal and Setting
The primary research goal of the study was to examine the CCMS diffusion process. More specifically, I wanted to examine the process with which the vendor attempted to diffuse the CCMS into the information development group and the process with which the information development group attempted to evaluate and adopt the CCMS.
The trial of the CCMS was intended to last three months, a time frame that the vendor felt gave the information development group sufficient time to complete the CCMS training and evaluate the full functionality of the system (an author-edit-workflow-review-publish cycle). To help the group successfully evaluate the system, the vendor provided a sample conversion of content to DITA (a standard that defines an XML architecture), DITA training and CCMS training, weekly conference calls, and web training as needed. The group began the trial feeling confident that three months would be enough time to decide whether or not to adopt the system.
When the trial began in October 2006, the trial participants, who I refer to as the “work group” in this report, had a general understanding of the advantages of moving to SSCM, but they had no training in object-oriented authoring or implementing a CCMS. Because of this, the participants approached the trial as an opportunity to gain experience with the built-in authoring, reviewing, and publishing tools of the CCMS and to learn how object-oriented authoring differs from traditional authoring. The writers and editors in Technical Documentation had been growing increasingly frustrated with the lack of consistency among related documents, the lack of reuse and collaboration, the redundancy in writing tasks, as well as the poor communication among writers, engineers, and product managers.
In light of these problems, Technical Documentation was looking to SSCM as a way to increase reuse and consistency; to improve workflow, collaboration, and communication among writers, engineers, and product managers; and to reduce translation costs. The participants hoped to see these goals materialize during the trial of CCMS.
My study participants included eight Technical Documentation employees, including the supervisor of Technical Documentation, six technical writers, and one technical editor. My participants also included five CCMS vendor representatives directly and indirectly involved in the trial; two representatives worked directly with the participants, providing technical and training support throughout the trial, and three representatives had significant influence on the direction of product development.
I used the following data collection methods to ensure a sound case-study methodological design:
- Protocol Analysis. Technical Documentation employees participated in a 30-minute protocol analysis immediately following their 30-minute interviews. Individual participants logged on to the CCMS and talked through their interactions with the system (for instance; processes, methods of accomplishing tasks, troubleshooting).
- Participant Observation. Throughout the trial, which lasted six months, I observed and indirectly participated in periodic work group meetings, periodic CCMS training seminars, and weekly conference calls related to the trial.
- Process Logs. Technical Documentation employees completed a process log during the trial. The log provided the work group a place to record their concerns and questions about the CCMS as well as any problems or successes they experienced while using the system.
- Document Collection. I collected all documents related to the trial, including email correspondence, support tickets, training materials, CCMS marketing and trial program materials, technical documents converted to XML, conference call agendas, and conference call meeting minutes.
Results and Discussion
No one factor accounted for the ultimate outcome of the trial. Cultural factors (such as organizational practices, relationships, values, and rules) and communication factors (meaning-making activities, such as correspondence, meetings, and training) shaped the technology diffusion process at every stage.
In the following sections, I highlight three key study findings:
- The culture of Technical Documentation mediated the work group’s perceptions of the CCMS.
- The vendor’s information transfer approach to diffusion hindered knowledge acquisition and learning.
- The work group’s lack of a strategic plan and know-how impeded their progress.
The Culture of Technical Documentation Mediated the Work Group’s Perceptions of the CCMS
The culture of Technical Documentation was the work group’s lens for assigning meaning to the CCMS; thus, the group members could not evaluate the system, the sample XML conversion of documents, or the vendor apart from the cultural context in which the group was an active participant.
Theories of activity and social construction assert that learning is local and situational (cf. Brown and Duguid; Driskell; Jaworski; Kaptelinin and Nardi; Lave and Wenger; Russell; Virkkunen and Kuutti). One learns through participation in a culture of shared artifacts, values, rules, habits of practice, and language (see Figure 1). Being immersed in this culture, one is continually learning how to be a member of that culture. When learning a new concept, practice, or technology, one gathers new information and attempts to make sense of what it means in terms of the culture in which the new knowledge will be put into practice.
Figure 1: Organizational Culture Mediated the Work Group’s Evaluation of the CCMS
The work group’s evaluation and interpretation of how well the vendor and the CCMS could meet their needs for SSCM was mediated by the structure, practices, habits, and ways of thinking of the culture of Technical Documentation—and its long history and relationship with other departments, subject matter expert reviewers, and product managers.
- Example 1: Concern for Reviewers. The single factor that seemed to influence the work group’s attitude toward the CCMS more than any other was the group’s perception of how the SME reviewers (engineers and product managers) would interact with the CCMS and what the reviewers would and would not like about the new review process. Reviewers were known to view their review tasks as secondary to their primary work tasks and tended not to complete their reviews by the deadlines set by the writers. Furthermore, reviewers had historically been resistant to adopting new review tools and processes, as change meant a time-consuming learning curve and potentially more work. The writers had learned over time that if they were to receive reviews that were useful back in a timely manner, they must keep reviewers happy. And that meant not complicating their work.
Even though the writers were generally excited about the functionality of the CCMS’s built-in review process (knowing the status of each DITA topic and having the capacity to pull all reviewer comments into one master file), they knew that if the reviewers did not see value in adopting a new set of tools and new processes for reviewing content then they would see little payoff in adopting the CCMS.
Reviewers were used to flexibility in how they provided feedback—some reviewers submitted written comments embedded in PDF files and others preferred to submit feedback to writers through emails, phone calls, or on paper. Because some reviewers saved the task of reviewing documents for their commute home or even from home, they chose feedback methods that were most efficient for them. The CCMS’s built-in reviewing process, however, did not allow for this kind of flexibility in how reviewers reviewed content. Though the work group members realized the benefits of reviewers seeing each other’s comments and of having all comments on a DITA topic attached to that topic, they were concerned that taking away reviewers’ flexibility and enforcing a new process for review would cause some reviewers to resist the CCMS.
In addition to not allowing flexibility in how reviewers submitted feedback, the CCMS did not allow for in-text mark-up, which many reviewers used when reviewing PDF and Microsoft Word files. If a reviewer needed to address multiple issues in a DITA element, he or she would have to carefully explain in writing where in the element the edits were needed; he or she could not simply insert the edits into the element. The work group members were concerned that this cumbersome process would frustrate the reviewers and complicate the task of reviewing content, a task to which they were already resistant. No matter how advantageous the review functionality of the CCMS might have been in other technical documentation cultures or how much information the CCMS implementation team communicated to the work group about the benefits of the built-in review process, the work group could not separate its evaluation of the CCMS review tool from what it perceived as the needs of the reviewer community. The system’s built-in review process did not match the work group’s existing understandings and expectations of what a review process should allow.
- Example 2: Default Configurations. For the trial, the vendor did not configure each CCMS application interface to meet Technical Documentation’s design needs; rather, they transferred default configurations of each application to the work group, assuming that the work group would be able to accomplish their trial goals using the configurations that other vendor customers had found useful. Because the work group’s lens for evaluating the CCMS was the culture in which the group was embedded, the group members found the default configurations to be distracting and confusing as well as a significant departure from existing practice.
The default interface configurations of the different CCMS applications worked against the work group’s habits of practice and software expectations throughout the trial. The long menus, unfamiliar terms used for familiar actions (for instance, “Audience Email Subject Key” to indicate the subject line for an email), right-clicking actions required to access menus/options and move files, and inconsistency in design and terminology between the applications are just a few of the design elements that caused the group members significant frustration when they were unsuccessful in completing tasks that they assumed to be straight forward. Throughout the trial, the group members described the interfaces as “distracting and busy,” “cryptic,” “unintuitive,” “not very graceful or user friendly,” and “cumbersome.”
In addition to knowing that the writing team would resist a tool that was difficult to learn and use, the group members knew that the reviewers would not stand for a system that complicated rather than simplified the review process. The process of adding comments is a good example. When reviewers opened a DITA topic to review, they would expect to be able to instantly review the topic and add comments where appropriate. Their existing process for reviewing documents did not require them to identify what type of comment they were going to make or to perform a series of actions before inserting a comment. The default configuration for adding a comment, which required reviewers to select a comment type, did not apply to what reviewers do. Further, some reviewers were used to submitting two to three paragraphs explaining changes needed. The default configuration of the comment dialog box, however, was a text field that did not allow words to wrap.
Because the default configurations for the review and workflow process did not accommodate Technical Documentation’s existing practices, the group came to believe that the CCMS was not compatible with Technical Documentation’s needs. If the vendor had configured the CCMS applications to meet the work group’s needs before the trial, many problems, complaints, and misunderstandings would not have taken place. For example, naming conventions, workflow set-up, and the built-in review functionality could have been tailored upfront so that those testing the system were not distracted by the extent to which the system did not match the usual way of doing things or expectations for how things should be categorized, accessed, and presented.
Feelings of being devalued in the organization, a history of contentious relationships with reviewers and other departments, explicit rules (such as workflow, review procedures, and authoring guidelines), implicit rules (such as not complicating reviewers’ work), habits of practice, and existing tools sets—all of these different dimensions of the culture of Technical Documentation mediated the work group members’ evaluation of the CCMS as well as their communications with each other and with the CCMS vendor. These different dimensions largely accounted for the work group’s ultimate perception of the vendor as dismissive and not upfront and of the CCMS as too complex and too much of a departure from existing practice.
The Vendor’s Information Transfer Approach to Diffusion Hindered Knowledge Acquisition and Learning
The work group’s ultimate perceptions of the CCMS and the vendor were largely the result of what proved to be an information transfer model of technology diffusion, evidenced most in the vendor’s approach to training and use of communication channels.
At its most basic level, an information transfer model of technology diffusion focuses on the one-way transmission of information from sender to receiver, often through information technology communication channels, and is based on an assumption that the meaning transmitted is the meaning received (See Figure 2). An information transfer model of technology diffusion assumes that if new information about a technology is well written and transmitted with reasonable accuracy from sender to receiver, the receiver will be able to successfully apply that information in her problem-solving activities. This model, however, has faced much scrutiny from communication and social science experts (cf. Brown and Duguid; Dobrin; Doheny-Farina; Miller; Rogers; Williams and Gibson), as it fails to account for how individuals come to understand what the transmitted information might mean in terms of the culture in which it is to be used.
Figure 2: Information Transfer Model of Technology Diffusion
The CCMS vendor spent a great deal of resources and time on the Smith Manufacturing trial in an attempt to help the trial participants realize the true value of adopting a complete SSCM solution. The vendor provided a DITA workshop, a three-day training workshop, and a number of web sessions; communicated frequently with the work group through email and support portal exchanges; and facilitated weekly conferences calls. All of these communication channels were meant to facilitate knowledge acquisition and shared understandings of terms, processes, problems, solutions, and progress. The trial participants, however, spent so much time trying to decipher messages from the vendor and figure out what the different CCMS applications meant in terms of day-to-day practice that they never reached a point when they were able to see how the pieces of authoring, reviewing, managing, and publishing fit together.
- Example 1: Limited Communication Channels. The vendor put a number of communication channels in place—such as a support portal, email, and weekly conference calls—to facilitate the exchange of messages between trial participants and the CCMS implementation team. The support portal (built into the CCMS) served as a means by which work group members could report technical issues and receive solutions to those issues. Email also served as a means by which group members could report progress, problems, and concerns and receive feedback. Weekly conference calls provided an opportunity for more informal, synchronous communication regarding progress toward achieving goals and any problems that arose during the week. The support portal, and to some extent email, was a way for the vendor to keep a track record of all problems encountered and solutions proposed. The portal was also intended as a resource for work group members to consult for status updates and feedback on submitted support tickets.
Although these channels had much potential to facilitate communication as a two-way process of convergence, they were used more for message transfer than for sharing knowledge and coming to a shared understanding of meaning. The channels in place, with the exception of the weekly conference call, were not set up for interpersonal, synchronous communication. They did not allow for participants to discuss non-technical questions with the implementation team, who they considered to be experts in use of the system. Further, the channels were not set up to elicit feedback on the CCMS and trial itself; the absence of such a feedback loop silenced many of the work group’s concerns that the vendor might have otherwise negotiated during the trial. In many cases, the support portal and email acted more as communication barriers than facilitators; they accounted for communication breakdowns that, over time, negatively impacted the work group’s perception of the CCMS and the vendor.
The weekly conference calls had the potential to act as a forum for negotiation and sharing of perspectives, values, language, and knowledge, but because the other communication channels in place for the trial (particularly the support portal and email) were not successful in helping to reduce barriers to understanding, the work group relied on the weekly conference calls to troubleshoot the technical problems that might otherwise have been resolved at different points during the week. By the end of a conference call, little time was left for the vendor to engage the work group members in dialogue on how they were attempting to measure progress toward achieving goals or what the vendor could do to help facilitate that process. As the weeks passed, the vendor did not realize that the work group was making little progress in carrying out any of their trial goals.
- Example 2: Instructor-Centered Approach to Training. As part of the trial, the vendor offered a three-day CCMS training workshop and periodic web sessions. The training, however, tended to follow an instructor-centered rather than student-centered approach to learning. The training sessions tended to consist of the expert instructor transmitting information to the novice students—the work group members—through demonstrations and lecture. At different points during the training, the instructor would ask if anyone had any questions; the group members most often would respond with silence or “no,” at which point the instructor would move on. These training sessions seemed to be based on the assumption that the participants, having taken notes and watched the demonstrations, could then perform the tasks covered in the training session on their own. But this turned out to be far from the case.
The work group members had little opportunity to put new information into practice during training, and when they did have such an opportunity through mini-exercises, the content with which they were assigned to work and the roles they assumed were unfamiliar; the instructor gave them generic content and default roles to test their understanding of concepts and how to complete particular tasks. This instructor-centered, information-transfer model approach to training gave students a lot of information about the CCMS but little opportunity to develop the “know how” to put that “about” knowledge into use.
Without the opportunity to practice applying their new “about” knowledge during the training sessions and to tap the instructor’s knowledge when questions arose, the work group members tended to leave the CCMS training sessions (three-day onsite training and follow-up web sessions) unsure of how what they learned would apply in practice.
The information that the vendor transmitted to the work group through email exchanges, webinars, the support portal, and even conference calls and face-to-face training proved, for the most part, not useful, as the trial participants were often unable to make sense of the information in terms of their day-to-day work. When they attempted to apply information from the vendor regarding the way the CCMS converted content, how workflow should be set up, and how to accomplish simple tasks such as moving and locating files in the different applications, they would often comment, “well, that doesn’t make any sense,” or “but that applies only to this instance and not this other.”
The bottom line is that the vendor’s approach to communication and training provided little opportunity for the work group to turn its “know that” about the CCMS into “know-how” knowledge. The vendor tended to transmit information to the work group through web sessions, the support portal, and email exchanges expecting that the work group could then use it for problem-solving. But the work group had yet to develop the kind of know-how necessary to make sense of what the information meant in terms of the immediate problems that they were experiencing.
The Work Group’s Lack of a Strategic Plan and “Know-How” Impeded Their Progress
The CCMS vendor’s information transfer approach to communication proved to be a significant barrier to successfully diffusing their system into Technical Documentation, but so too did the Technical Documentation work group’s lack of a strategic plan and know-how. At the time of the CCMS trial, Technical Documentation was not change ready.
The department did not have a change management plan in place for the trial or for their larger SSCM initative. For the trial, they had not established processses to guide them in achieving their goals for the trial, and they had not defined priorities and measures, timelines and milestones, or team roles and responsibilities to mediate (or guide) their evaluation of the CCMS. Further, they began the trial without having a content strategy in place, without having worked to develop the information models and metadata strategies necessary to support the restructuring and conversion of existing content as well as development of new content. Complicating this almost certain recipe for a failed CCMS trial, the work group had yet to gain buy-in for SSCM from the engineer and product manager reviewers who would be directly impacted by all changes related to the management and review of content.
The trial participants began the trial expecting to learn—through playing with the CCMS and their converted content—what their strategy for moving to SSCM and their requirements for a CCMS should be. This over-reliance on the tool to guide their SSCM initative, rather than on a strategic plan that included a thorough assessment of the cultural, process, and design changes necesssary to support this radical shift, resulted in the participants not knowing what they should be doing from week to week and not knowing on what criteria they should be evaluating the CCMS, the sample conversion of content, and the vendor itself. The absence of a change management plan, content strategy, and buy-in led to numerous communication breakdowns among the trial participants and between the participants and the vendor.
Surely, Technical Documentation, before agreeing to do a trial, should have done significant planning first. Such planning would have prevented many of the problems that plagued the trial. But such planning would not have prevented all of the problems. When two widely differing cultures work together, cultural and communication barriers need to be overcome if shared goals are to be achieved. For the trial, the vendor was attempting to help the work group perform a successful, useful evaluation of the CCMS. Because the two groups had different levels of expertise and backgrounds; used different vocabularies to talk about the same concepts, tools, and practices; and represented different value systems, organizational structures, and drivers, they needed common ground on which they could understand each other and successfully communicate meaning. A jointly developed, scaled-down change management plan, for example, might have provided common ground for understanding throughout the trial.
A scaled-down plan, collaboratively developed before the trial began, might have included, at minimum, clearly defined goals and processes for achieving goals; clearly defined measures for evaluating progress toward achieving goals; a detailed plan for gaining reviewer and writing-team buy-in; piloted information and metadata models; designated trial participant roles; scheduled meetings and collaborative work sessions; processes and procedures for communicating and documenting progress, problems, and concerns; and appropriate communication channels with which to do so.
The key is that the two groups needed to develop such a plan together, as the work group would not have been able to map out a plan for the trial without the help of the vendor. The work group had no experience with SSCM or the CCMS and had no idea how to go about realizing their goals. They needed guidance from the vendor in what they could reasonably expect from the trial and “how” to go about “testing” the system. They needed the vendor’s guidance, before the trial began, in defining goals, measures, milestones, and deadlines. Had the vendor and the work group worked together to develop a change management plan, both parties could have referenced the plan during conference call discussions to gauge the extent to which the work group was achieving their goals and what the vendor needed to do to help facilitate the process. A plan jointly developed would have helped the work group gain valuable “know how” and helped the vendor better understand how the group felt the trial was going and why.
Collaboratively developed, shared artifacts, such as a change management plan, CCMS evaluation test plans, and meeting agendas, would have helped the two groups overcome many of the cultural and communication barriers that prevented them from coming to shared understandings of each other’s goals for the trial, of each other’s expectations for achieving those goals, and of each other’s needs for measuring progress. As Williams and Gibson (1990) note, technology transfer is often a “chaotic, disorderly process involving groups and individuals who may hold different views about the value and potential use of the technology” and who may use different vocabularies, have different motives, and represent widely differing cultures. Jointly developed artifacts can help guide the activity of technology transfer and reduce barriers to understanding. Such artifacts can help to facilitate an ongoing, interactive process of idea exchange, negotiation, and learning between technology diffusers and potential adopters.
Data analysis revealed that the work group’s ultimate perceptions of the vendor and the CCMS can be attributed to not being able to evaluate the CCMS apart from the culture in which the group was an active participant, to the vendor’s information transfer model of technology diffusion, and to the lack of collaboratively developed, shared artifacts such as test plans to guide the group’s weekly trial activities and progress toward achieving goals. Ongoing technical and usability problems, as well as communication breakdowns, compounded the participants’ collective feeling at the end of the trial that the CCMS was too complex and was too much of a departure from existing practice.
These findings reveal how critical it is for information development groups to plan for the role of culture and communication in a CCM adoption project. Culture mediates perceptions and understandings. Without appropriate communication channels and collaboratively developed, shared artifacts to facilitate understanding and guide actions, people come to understand technologies, processes, goals, expectations, and terms differently. Different understandings of meaning result in communication breakdowns, which can impede progress toward achieving desired outcomes.
In the following sections, I briefly describe applications of these findings for information development managers as well as vendors.
Information Development Managers
My study offers information developers insight into the process with which one CCMS vendor attempted to diffuse a CCMS into a work group and the work group attempted to evaluate the CCMS. This insight, I believe, shines light on the kinds of challenges many work groups may be facing as they attempt to transition from traditional documentation methods to SSCM. This insight should be useful to information development managers who need to make informed decisions on how best to approach SSCM and plan for the CCMS technology diffusion process.
In light of my research findings, I offer information development managers about to embark on a SSCM initative the following recommendations:
- Before beginning a CCMS trial or the adoption process, assess how different dimensions of your organizational culture—such as history, values, rules, habits of practice, tools, and relationships with other departments and the larger organization—are likely to influence stakeholders’ perceptions and use of the CCMS and the new processes that it supports. Develop strategies as part of your change management plan for addressing the powerful influence that these dimensions will have on people’s individual and collective perceptions of the relative advantage of adopting the CCMS and of the relative compatibility of the CCMS with existing habits of practice, tools, rules, and processes.
You might examine, for example, the nature of the relationship that the information development team has with the larger organizational culture and with other teams who will be directly impacted by the new CCMS. Is this relationship characterized by a lack of respect, trust, or understanding? Do information developers tend to feel undervalued and underappreciated? If so, what impact do these feelings have on how information developers carry out their day-to-day work? If these feelings encourage information developers to hoard information or solve problems on their own rather than collaborate with others on the team or with others on other teams, the developers are likely to continue these habits of practice in a new SSCM environment. If these feelings lead information developers to believe that their work doesn’t really matter and that learning new processes and tools isn’t really worth their time, they are likely to resist change and resist fully investing themselves in the SSCM initiative. Throwing more tools, processes, or training at a cultural problem is not going to solve the problem—it’s not going to change how people feel and thus how they act.
The key is to develop strategies as part of your change management plan for cultivating the kind of culture necessary for achieving your SSCM initative goals. Gaining buy-in from all stakeholders is essential. So too is understanding why different teams and individuals might be resistant to change and what cultural dimensions you need to address.
- Implement communication channels that facilitate interaction, knowledge acquisition, and learning. Implement these channels for interactions among all stakeholders in the SSCM initative. Studies show that communication channels that facilitate synchronous, interactive communication, such as video conferencing and face-to-face meetings, are inherently more effective than asynchronous communication channels, such as email and webinars, in helping individuals of different groups and expertise come to shared understandings of meaning. Communication channels that facilitate interaction are particularly important when people are learning new concepts (such as DITA) and tools (such as an XML editor or CCMS) that they need to apply to or use in practice. Interactive channels allow for the kind of negotiation and guided feedback necessary for learning. One-way communication channels, such as email or webinars, tend not to elicit the kinds of meaningful questions, discussions, and feedback essential to coming to shared understandings of meaning (particularly between a vendor and a work group) and aquiring know-how.
Face-to-face meetings (or video conferencing for distributed groups) and on-site training are particularly important when a group is learning a new concept or practice or when two groups representing widely differing cultures are attempting to work together. These synchronous, interactive communication channels provide rich opportunities for participants to share and transfer knowledge, negotiate, problem solve, and respond to non-verbal cues, which might signal confusion, disapproval, or other feelings that in a one-way communication channel would not be apparent. Only through reducing barriers to understanding, which are present when participants use different vocabularies, have different motives, and represent organizations of widely differing cultures, can participants in a goal-driven activity come to shared understandings of meaning. An ongoing, interactive process of simultaneous and continuous idea exchange is essential if participants are to break down cultural and communication barriers.
- To facilitate interactions within a team or between teams that must work together to achieve a common goal, encourage stakeholders to develop shared guides, such as process scripts and meeting agendas, that serve as a common framework for understanding. An information development team assigned to evaluate a CCMS, for example, might collaborate (through interactive communication channels) to develop a test plan with clear goals, milestones, deadlines, and measures. This guide would then serve as a common framework for understanding who is going to do what, when, where, how, and with whom. It would also serve as a means for assessing progress toward achieving goals. When individual team members feel that they had a stake in the development of a plan—that they played an integral role in the negotiation process—they are much more motivated to collaborate, ask questions, offer feedback, and achieve goals.
When working with groups that represent widely differing cultures, such as vendors and engineering departments, develping guides to facilitate interactions and shared understandings of meaning becomes even more important. These guides, which might be as simple as a meeting agenda or as complex as a workflow plan, should, ideally, be collaboratively developed. When stakeholders in a meeting or a workflow process feel ownership of the agenda or the workflow, they are much more likely to ask questions, offer feedback, and identify problems and solutions. Collaboratively developed, shared guides not only facilitate knowledge acquisition and shared understandings of meaning, they also help structure interactions, making them more productive.
CCM Software Developers
My findings suggest that CCM software developers who offer trials and/or help work groups evaluate and adopt their systems can better facilitate the diffusion process by employing the following strategies:
- Research a work group’s culture before a trial or CCMS evaluation process begins. Developers attempting to diffuse their CCMS into organizations might meet with work groups with the goal of coming to a shared understanding of their day-to-day work environment—of the tools, rules, practices, relationships, and values that govern day-to-day work and interactions with people and technology. Developers would benefit a great deal from working with work groups to identify not only their goals and expectations for SSCM but also their concerns about potential cultural and communication barriers to achieving those goals and meeting those expectations. Groups who are still developing SSCM expertise would particularly benefit from collaborating with vendors.
- Tailor CCMS configurations and content conversions to meet the specific needs of potential adopters. If the CCMS vendor in my study had configured their CCMS applications and tailored their conversion of sample content to meet the work group’s needs before the trial, many problems and misunderstandings would not have taken place. Throughout the trial, those testing the system were distracted by the extent to which the system did not match the usual way of doing things or did not match individual expectations for how things should be organized, converted, and configured.
- Adopt a student-centered approach to training. Information development groups, particularly those new to object-oriented authoring and working with a CCMS, need opportunities to put new information into practice during training sessions. Work groups also need opportunities to work with their own content in the roles that they will assume post implementation. In my study, the CCMS vendor gave the work group generic content and default roles to test their understanding of concepts and how to complete particular tasks. This instructor-centered, information-transfer model approach to training gave students a lot of information about the CCMS but little opportunity to develop the “know how” to put that “about” knowledge into use.
- Implement communication channels that allow for interactive, synchronous communications. CCM technology developers attempting to diffuse their CCMS into an information development group need to provide interpersonal communication opportunities that allow for negotiation and sharing of perspectives, language, knowledge, needs, and other technical and non-technical issues and concerns. Developers should ensure these channels allow for open, back-and-forth communication between developers and work groups and that all participants have access to ongoing conversations and opportunities to response.
- Collaborate with potential adopters to develop artifacts or guides that serve as a common ground for understanding and for achieving common goals. Such artifacts or guides can be used as reference points for all communications about aspects of the CCMS adoption process—including goals, tasks, measures, processes, concepts, help documentation, plans, interfaces, training, meetings, and so on.
University of California, Davis
Rebekka Andersen is an assistant professor in the University Writing Program at the University of California, Davis, where she teaches writing in the disciplines and professions courses. Her research focuses on the diffusion of content management technologies in information-development teams. Most recently, she is studying how managers, software developers, and information developers plan for and attempt to carry out the activity of technology transfer. Rebekka has worked as a technical writer and editor and process documentation specialist. She has also presented her research at conferences hosted by the Center for Information-Development Management, the Society for Technical Communication, the Association of Teachers of Technical Writing, the Professional Communication Society, and the Association for Business Communication.
“Technology Diffusion and Organizational Learning: The Case of Business Computing.”
John Seely Brown and Paul Duguid
The Social Life of Information
2000, Boston, MA
Harvard Business School Press
Colin Charlton, Chris Gittings, Paul Leng, Janet Little, and Irene Neilson
Information Systems Innovation and Diffusion: Issues and Directions
1998, Hershey, PA
IDEA Group Publishing
David N. Dobrin
Writing and Technique
1989, Champaign, IL
Rhetoric, Innovation, and Technology: Case Studies of Technical Communication in Technology Tranfers
1992, Cambridge, MA
Professional Writing and Rhetoric: Readings from the Field
2003, New York, NY
Addison Wesley Educational Publishers, Inc.
Framing the Domains of IT Management: Projecting the Future…Through the Past
1999, Cincinnati, OH
Pinnaflex Educational Resources, Inc.
Discussion Paper Series: Centre for Economic Policy
Centre for Economic Policy Research
“Constructivism and Teaching— The Socio-cultural Context.”
Victor Kaptelinin and Bonnie A. Nardi
“Activity Theory: Basic Concepts and Applications.”
ACM SIGCHI 1997
Jean Lave and Etienne Wenger
Situated Learning: Legitimate Peripheral Participation (Learning in Doing: Social, Cognitive and Computational Perspectives)
1991, New York, NY
Cambridge University Press
“A Humanistic Rationale for Technical Writing.”
J. Roland Ortt
Managing Technology and Innovation: An Introduction
Diffusion of Innovations, 5th ed
2003, New York, NY
“Rethinking Genre in School and Society: An Activity Theory Analysis”
“Compensating for Information Externalities in Technology Diffusion Models.”
American Journal of Agriculture Economics
Jaakko Virkkunen and Kari Kuutti
“Understanding Organizational Learning by Focusing on ‘Activity Systems.’”
Journal of Accounting, Management, & Information Technology
Fred Williams and David V. Gibson
Technology Transfer: A Communication Perspective
1990 Newbury Park, CA