A key concept of a unified content strategy is the sharing of content and collaborating on its development. Collaboration ensures that the content elements, such as product descriptions, are consistent and can be reused wherever they’re required—in a printed brochure, on the Web, on an intranet, in user guides, and so on. To ensure content elements will meet all needs, everyone involved in creating content must work together to figure out exactly what the needs are and make decisions about how elements are to be reused, structured, and written.
As discussed in Chapter 1, “Content: The lifeblood of an organization,” content is often created by authors working in isolation from other authors. Silos are erected between departments and even within departments, which leads to content being created, re-created, and re-created, causing extra work and introducing inconsistencies. Individual authors working in isolation is not possible in a unified content environment. When content is compiled into its various information products, it must appear to be completely unified; there is no room for different “colors or textures.” The finished product must be seamless. The goal of collaborative authoring is to break down the silo walls so that authors can create content consistently.
Collaboration, however, is harder than you might imagine. Collaboration, regardless of the tools in place to support it, is a human endeavor and must be supported by strong teams willing to undertake collaborative efforts. Collaboration requires everyone working together toward a common goal— unified content. To realize this goal, organizations have to change the way content is authored, starting from the modeling process and continuing through each new project.
This chapter discusses collaborative authoring and explores potential strategies for collaborative authoring in your organization.
Collaboration is not a new concept. Think of the many books authored by more than one writer or the albums produced by more than one musician. The common element in successful collaborations is a goal that all players are aware of and support. People involved in the collaboration know what the goals are, know their roles, know others’ roles, and know how to invoke change or address issues. Players should also have a stake in the outcome, whether it’s content that’s easier to access and use, a more productive authoring environment, or even a share of company profits. With all those requirements, figuring out a way to make collaboration work in an organization, especially a large one, can be problematic. But, in a unified content strategy, it’s necessary.
More and more, effective information requires many people, often with varying skills and backgrounds, and often from different departments and even different professions, working together on the same project, or more accurately, working together on different aspects of the same project. Authors cannot work in isolation from subject matter experts and users; marketing cannot work in isolation from product documentation and support; product developers and engineers cannot work in isolation from authors. This is certainly true in a unified content environment. Yet, collaboration in relation to writing is often misunderstood. Collaboration involves more than different authors creating content for different aspects of a project.
Doing a search for collaborative authoring or collaborative writing on the Internet turns up thousands of hits, most with one thing in common: the human element implicit in collaboration. For example:
On the web site for the University of North Carolina at Pembroke, a law professor posted guidelines for collaborative writing, with the number one guideline being:
“Take time at the start of your project to build cohesion. Begin your project by developing a shared understanding of your assignment and discussing basic procedural and logical issues. Build group cohesion and establish good interpersonal relations among members.” [1]
In a thesis on computer-supported collaborative writing, the author defines collaborative writing as follows:
“In a true co-authoring process, the peers collaborate on every task as opposed to the situation in co-publishing [and] co-responding…In co-publishing the individuals produce a collaborative text based on individual texts. Interaction in a co-responding environment takes place only during the revision process…In peer collaboration, the group assignment is a truely [sic] joint task, all members contribute to the interaction most of the time and each of the peers has equal control over the text as well as within the interaction.” [2]
In the OII Guide to Workflow Management and Collaborative Authoring, collaborative authoring is defined as follows:
“Collaborative authoring can be defined as ‘the use of workflow techniques to manage the creation of integrated data sets by more than one author.’ However, collaborative authoring is normally seen to include more than simply the application of workflow. It also requires facilities for defining how data created by different, parallel, processes is to be combined or linked.” [3]
For an effective collaborative authoring environment to be set up, the team must define how information is to be written, linked, and unified. The tools then support what the team decides.
In another paper on collaborative authoring of web content, the authors state:
“Information content publishing may also be performed collaboratively, where multiple geographically dispersed authors contribute to the publishing of semantically related pieces of information…The authors bring together expert knowledge needed to provide parts of the content. Collaboration enables the authors to work together on the authoring tasks by sharing the knowledge needed in the process of producing content.” [4]
From an organizational perspective, collaborative authoring requires that all authors have an understanding of how content is used in multiple situations and the ability to work together to create it. This normally requires organizational change, specifically in the way content is authored. Authors must be involved in development teams (so they can plan for reuse from the beginning); they must have solid information models (that they have helped to create and have been trained to follow); they must have usable authoring tools that assist them in following models and sharing information; they must have a stake in the outcome; and most of all, they need an understanding of what they are trying to accom-plish and the support and resources to do it. Collaborative authoring also requires technology’s assistance with some things, such as access to shared information, workflow routing, version management, check-in and check-out, as well as tools to assist authors in writing to models. Although tools are important, they play a supporting role; the focus of this chapter is on the organizational strategies for collaboration. Further information on tools and technologies as they relate to collaboration can be found in Part V, specifically, Chapter 15, “Authoring tools,” Chapter 16, “Content management systems,” and Chapter 17, “Workflow systems.”
Many companies are not structured to support collaboration. Their structure is hierarchical and as a result, many of their projects come together vertically and in isolation. When a company introduces a new product or service, many of the people involved in the project don’t even know who the other people are or what aspect of the project they’re working on. And the bigger the company, the more true this is. The technical publications people may be aware that the marketing people are “doing their thing,” creating the brochures and writing the scripts for television spots, but they see it as separate from what they’re working on, which may be the user guides. Likewise, the training people may be creating web-based tutorials, but they see the technical publications group’s efforts as separate from theirs. Once you’ve developed information models—especially if you’ve developed them by looking beyond the content that your group creates—you’ll be more aware of the content that other groups create. Yet the information models themselves are a collaborative effort, and they need collaborative revisiting at the start of new projects to ensure that they still accommodate the information needs of the new project. For example, is the granularity still sufficient to enable you to deliver content dynamically over the Web? For collaboration to occur, change must occur at many levels:
How groups are organized and managed
How groups work together
How individual authors work
How models are implemented and used
For authoring to be collaborative, project members must know and understand each others’ roles, even if they perform different functions. The information model will indicate what information products are required (for example, product catalog, user guide, internal support documentation) and based on your knowledge of who does what in your organization, you organize your team around the information products being developed. For example, if you are creating documentation for medical devices, the authoring team will consist of everyone involved in creating any type of documentation (brochures, doctors’ manuals, patients’ guides, press releases) for the medical device: medical writers, marketing writers, public relations specialists. A unified content strategy requires that all groups collaborate on their efforts so they can complement each other. As groups become more familiar with each other, they can also work together to make sure models continue to meet their needs. Use these techniques to ensure collaboration and a shared vision:
When you’re documenting a new product or service, hold a project “kick-off ” meeting (you can do this virtually if you’re geographically dispersed) at the project’s inception. Discuss the information requirements, ensure that the current information models support them, and establish how you will share information that is reusable. Get questions from everyone involved. Make sure the writing standards for elements are explicit and understood by everyone in the group. However, with that said, use the meeting as an opportunity to share, not to lecture. Additionally, open a line of communication to the project head that anyone can use if concerns pop up later (such as from those who couldn’t attend the meeting).
When you’re working on updates to existing content, revisit the information model to make sure everyone on the team understands what information is being reused and what the writing standards are for the elements being revised. Don’t assume that your group is the only group involved in an update; check the elements requiring revision against the information model to see who else is involved. As a group, you can make sure the model is still effective as elements are updated; you can also keep it current with what you’ve learned from users, so you continue to deliver what readers really need, not just what the models say they needed five iterations ago.
Collaboration also implies a change in the way work is organized. In many organizations, individual groups handle a number of projects, separate from each other. A marketing group, for example, will often work on a number of different projects for a variety of other groups in the organization. Those projects are, for the most part, independent of each other in how they’re staffed, funded, and managed. It’s difficult for groups to collaborate with an independent, project-oriented organizational structure in place.
In a unified content environment, organizations need to be resource-based, focusing on content requirements across the organization, not just for one project. A content database becomes an integrated source of definitive information, contributed to and used by everyone in the organization. When planning the information products required for a project, departments should think about what they will add to and use from the definitive source. As they develop their content, they should plan for its other uses as well. Consider allocating budgets for content development across an organization, not just to individual departments. This enables you to move to a resource-based content development model rather than a project-based one. In a resource-based model, budgets are developed for all the content your organization produces across the organization, thus replacing individual department budgets for content creation.
Resource-based project planning also reduces content creation time and costs. Because content is developed across an organization, fewer resources are needed to re-create content that may already exist elsewhere. The technical publications department doesn’t have to write a product description that has already been developed by marketing. When content is tagged and stored for easy retrieval, authors can retrieve it and either incorporate it into their information products as is or modify it for their own purposes (based on their information model). The model will tell the marketing group that technical publications also needs the product description and that it must be written and structured in a certain way so it’s usable for both purposes. To get to this understanding of the product description, technical publications and marketing must collaborate.
Even in a collaborative environment, authors don’t have to work together in groups the whole time. Plenty of work can be done on an individual basis. But crucial decisions must be made together and reaching consensus is key to successful collaboration. One author may find that the current level of granularity is insufficient, but before changing it, everyone who is affected by the change must agree. Collaborative teams, when they work, do not proceed by democratic vote. Instead, they struggle to reach consensus, even though it takes longer than voting. Consensus means that everyone agrees to a change, not just the seven out of ten who vote for it. With consensus, everyone buys into the change and will support it in their writing.
Furthermore, collaboration is significantly different from cooperation. When we cooperate, we work together, but we each produce and “own” our individual projects. We retain our separate styles and in the finished product, we can usually tell which portions are “ours,” and we can certainly tell which information products we created in their entirety. This kind of independence doesn’t work in a unified content environment, when information products are compiled from a number of different elements, often written by a number of different authors.
In a unified content environment, the concept of ownership becomes irrelevant. For instance, in an “independent but cooperative” environment, my colleague writes a procedure, which I edit. I write another procedure, which my colleague edits. But, ultimately, my colleague is in charge is his or hers, and I’m in charge of mine. We negotiate changes and we (often delicately) suggest improvements. But we “live with” what the other person produces. We do not really merge our thoughts so that it becomes transparent who wrote what. However, if a particular author’s style is discernible, the content may not be reusable in different information products. Independence often leaves documentation uneven, which is unacceptable in a unified content environment.
Instead of the usual, cooperative approach to writing that many groups use, a unified content strategy requires true collaboration, which means working together so thoroughly that you no longer own any part, any chapter, any sentence, any procedure. Elements are truly unified, based on the information model, and authors can’t tell who did what. This is difficult for many authors to get used to; they claim it takes away their creativity. We, in our role as consultants, frequently dispute this belief, emphasizing that the real creativity comes in analyzing users’ needs and figuring out the best way to meet those needs, often dynamically. The creativity also lies in building strong models, based on possible uses and potential users for content. In this way, authors truly become information architects, with more and more emphasis on the analysis and design that drive the content. Collaboration is critical in creating and sharing the information design and the standards that everyone follows.
In the past, many technical writers became technical writers because technical writing is—or used to be—a solitary profession. Many technical writers are accustomed to working independently, with little collaboration. A single writer would be assigned a single document, retreat to his or her office to complete the assignment, sometimes interrupting the day to make phone calls to subject matter experts to clarify understanding of the content. When the document was complete, it was published and distributed to those who needed it and authors continued with their next project. This would often result not only in disparities in a single author’s work, but in disparities in the documentation produced by the entire work group.
Collaboration requires not only that authors work with each other within their own departments, but also with authors from different departments. In a collaborative environment, authors work together to ensure that content is not written more than once by more than one author, and more importantly, that similar content is not written about differently. The information models must be clear about what the information requirements are; the organizational structure must be clear about which department authors which elements.
What does this mean in the workplace? It means that authors may need new skills, such as information analysis, design, modeling, structured writing, and conflict management to help them in the transition from independent to collaborative work. Strategies for helping authors switch to a collaborative authoring environment include:
Training authors in analysis, information modeling, and design; emphasizing analysis of information and users’ needs so authors learn to model based on needs
Involving authors from across the organization in developing models and in reviewing them on an ongoing basis
Training authors in following models
Training authors in structured writing
Also, often overlooked in favor of the more “technical” skills of analysis, design, and writing is the ability to handle conflict. A certain amount of conflict is necessary to motivate change and encourage creativity. However, unmanaged conflict can quickly turn to chaos. Conflict will certainly be present as groups try to reach consensus, and it’s important for team members to understand conflict responses and how to deal with them. Furthermore, in collaborative efforts across departments and even within departments, there are likely to be “turf ” wars. Departments or individual authors may feel they are being compromised, and when this happens, conflict is imminent. Jean Richardson and Lisa Burk’s paper, “Conflict Management in Software Development Environments,” [5] provides a good description of conflict management techniques, as well as a thorough bibliography.
Models are the key to a successful unified content strategy. Although not everyone in your organization can get involved in the modeling process, you should have representatives from every area that creates content. Their input is critical in defining information requirements and potential reuse. Once models are developed to accommodate needs across the organization, anyone involved in authoring content must learn how to follow them. We advocate the following:
Run workshops introducing the concept of models and how to use them not only to authors, but to reviewers of content and to managers of content creation groups. Stress the importance of models to unified content, and the importance of different groups contributing to and following models. Make the models available for reference, so that everyone who needs to use them can access them. Revisit models regularly to ensure they continue to support your information requirements.
Usability test new authoring tools and authoring scenarios with all the groups that will be using them. Provide real authoring scenarios to each group, including such things as their ability to:
Follow the model (whether it’s supported by a tool or referenced in a writing guide or spreadsheet)
Identify and retrieve reusable information
Populate a document with reusable information
Create elements
Publish elements
Store elements
Refer to Appendix A, “Checklist for implementing a unified content strategy,” for more information on conducting a usability test. There are also some references to usability testing in the bibliography.
Although tools by themselves are not the key to implementing collaborative authoring (change must occur at the organizational level), their role is a critical supporting one. They don’t replace the teamwork, the understanding, or the cohesion that collaborative authoring requires. In fact, tools can make collaboration easier, but they do not guarantee success. In working with a tool that is not conducive to the creative process, authors often feel like they’re submitting rather than creating.
The tools required for collaboration involve more than giving everyone access to the same directories on the same file server, regardless of how user-friendly the file server may be! Tools for collaboration are described in Chapters 15, 16, and 17, but some factors critical for effective collaboration include the following:
Access to shared information
Check-in and check-out
Locking and version control
Transparent authoring to support models
Managed workflow
Event notification
Collaborative authoring is key to breaking down silo walls. Collaboration means everyone working together to achieve the common goal of unified content that is truly seamless. Collaboration sounds easier than it is, though. Some elements necessary for successful collaboration include the following:
Know everyone involved in creating content and what each person’s role is; look to models to provide advice about information requirements; consider including a “responsible party” for each information type in your model so that you know what information is required as well as who is responsible for creating it. Hold “kickoff ” meetings at the beginning of projects.
Think about how your organization is structured. Does your structure allow for collaboration across departments? How do departments know what other departments are working on?
Provide authors with a stake in the outcome and an understanding of how collaborative authoring will benefit them.
Consider moving to a resource-focused approach to developing content; develop budgets based on content requirements across the organization, rather than department-specific budgets.
Start with strong models; introduce models to everyone in the organization who creates content; revisit models iteratively.
Make any changes to models, authoring processes, and standards by consensus and not by democratic vote; train authors in conflict management techniques.
Encourage authors to relinquish ownership of their content; content with a discernible style is not necessarily reusable.
Train writers in information analysis, modeling, design, and structured writing so they all have the same understanding of how to create and how to write to information models.
Provide usable tools that support collaborative processes, not impede them.
[1] http://www.uncp.edu/home/vanderhoof/syllabus/colab-rt.html, accessed on March 3, 2002
[2] http://infolab.kub.nl/pub/theses/w3thesis/Groupwork/collaborative_writing.html, accessed on March 3, 2002
[3] http://www.diffuse.org/oii/en/workflow.html, accessed on March 3, 2002
[4] Kovse, J., Harder, T., Ritter, N., Steiert, H., Mahnke, W. “Supporting Collaborative Authoring of Web Content by Customizable Resource Repositories.” Department of Computer Science, University of Kaiserslautern, Kaiserslautern, Germany. Available as PDF at http://www.tu-chemnitz.de/informatik/webdb/020.pdf. March 3, 2002.
[5] Burk, Lisa and Jean Richardson. Conflict Management in Software Development Environments. Available from www.bjr.com, June 25, 2002.