Practice Insight: Seven Points to Negotiate for Document Collaboration

A Practice Insight: Seven Points to Negotiate for Document Collaboration

Download the PDF here:

Document Collaboration: Avoid Being Lost In Immediacy 

Any document that requires co-creating, meaning input from more than one author, and/or feedback on the structure, concept, meaning or grammar of a document, requires collaboration, and good collaboration requires negotiation.

Note that I said good collaboration requires negotiation. There are a lot of people working collaboratively, and a number of collaboration vendors, that are just fine with emergent collaboration. They follow this philosophy: Just let stuff happen, the right stuff will eventually happen and it will bubble to the top and then we will skim this good stuff off the top, call it good and move on to the next thing. The moment rules.

Unfortunately, that approach doesn’t lend itself to deep thinking or the critical review of big ideas that require not just time and collaborative input, but collaborative structure such as the order of ideas and the words chosen to express them.

Organizations that require focused collaboration around a document or concept will find that posts and links, hasty scribbles and disconnected commentary are unlikely to serve their needs. They should consider these seven areas of negotiation that can help design a better work experience related to document creation, and provide insight into collaboration tool features .

Analysis

Successful collaboration is the result of negotiating very specific agreements about how work will be conducted and what success looks like. The myth that organizations “know how to collaborate” comes from a convergence of accepting poorly executed collaboration as the norm, and believing that having tools in place will create good collaboration.

Before a team embarks on a significant collaborative effort around a document, consider the following seven negotiation points critical to creating a good document in a timely way.

 

1. Intention

Teams must clearly state the intention for any co-created document. If the document collaboration is for gathering feedback on an existing document without the intention of permitting reviewers to actively edit the body of the document, that is an entirely different experience from the co-creation or co-editing of a document in its native format.

Intentions can vary widely from creating a proposal for a potential client, to developing a marketing white paper aimed at establishing thought leadership in, say sustainability. Regardless of what the “intention” is, it should be clearly stated after being negotiated. No one working on a shared document should wonder about its purpose.

2. File format and applications

Although many applications can read and write other formats, when collaborating on a document it is imperative that teams choose one format and stick with it. Embedded items like dates and images are often not supported at the same level of fidelity, if at all, by other programs. This will affect not just the formatting of a document but its structural integrity.

PDF documents or other static file formats are very poor targets for the co-creation of content. They should be used primarily for collecting feedback, ideally against a single, shared copy of the document (see item 5, How to collect feedback).

It is ideal to select the application which is both most common to the co-creation group, and which supports the collaboration features required of the task. Tracking changes by user and accepting in-context comments represent the minimum features for word processing. Comments and change tracking on spreadsheets and presentations are also useful. Annotation overlays should be considered a complement, and not a replacement for annotation features that support direct, in-document, contextual feedback.

The document should be able to support, as much as possible, the final form the document will take. If, for instance, a word processor is selected that does not support columns, but the final document will appear in column form, the tool selection may be inadequate at giving contributors a sense of the document as it will be published.

3. The final document form

Many documents, however, aren’t published directly from the editorial tool in which they are written.  Collaboration is not complete until the document is in its final form and published, and if the authoring tools do not support production of the final document, then tiered collaboration must be planned. This means that content will be separated from form, participating in its own collaborative experience. The content will then be placed into layout and the review and feedback on layout will constitute a separate collaborative track.

Intent usually refers to the fit of the document to meet an objective, while form may be best described as a negotiated expectation for the layout, graphics, fonts and other elements of the document.

Note that content may be represented by several final forms without editorial change, thus making the final document form a collaborative exercise that may occur more frequently than content creation activities.

4. The storage repository

Almost all collaboration systems include a document repository, and those that don’t usually link to Dropbox, Box, Google Docs, Microsoft OneDrive or some other storage system. If an organization hasn’t adopted a collaboration tool, many of the products mentioned above embed collaboration into their storage solutions if acquired at the professional level. Suffice it to say that there is no excuse for not selecting a storage location for a document and sticking with that location through out the collaboration process. That means not e-mailing it around, not changing its format for convenience, or putting up a copy in a private repository for “personal” work.

5. How to collect feedback

With all of the current options available, negotiating the way you will collect your feedback may prove the most daunting task, but it is critical to productivity.

As already mentioned in item 2, most creation applications include some form of collaborative feedback collection features. Teams should use those features as implemented, and avoid workarounds such as typing comments in-line into a Microsoft Word document rather than using the comment feature. As a specific instance of negative productivity using a workaround, Microsoft Word supports the deletion of  all comments so that a clean document can be quickly created. In-line comments must be manually edited out of a document.

If collaboration outcome metrics focus on inclusiveness not productivity, then teams may choose to let people use whatever tool they want with a simple rule in place that any feedback must be readable by the person consolidating the edits. It is advisable, however, to keep productivity in balance. Open feedback could mean reading through dozens of files and incorporating a wide variety of inputs and annotations, including handwritten notes, in-line notes, comments and tracked changes, into the edit-compilation version of a document.

Because most people have access to the most common tools, teams should negotiate for the use of a single tool for feedback, and the document should receive feedback in its native format until it moves into a review of its final published form, at which point comments about layout, arrangement, typography and other visual elements will likely take precedence over word selection and meaning, and these lend themselves more to overlay annotations.

This point is moot, however, if item 2 above is effectively negotiated with tools that include feedback features. Microsoft Word, for instance, includes change tracking as well as comments, and those tools are agreed to as they work to gather feedback.

6. The workflow

All collaborative documents exist within a workflow. Some, like proposals at big consultancies or legal documents, may exist within a very structured workflow, under the auspices of business process management or some other system that puts input and reviews under tight constraints.  These tools typically encapsulate a document within a process, represented by a series of steps, actions and timings that govern its flow through an approval and publishing process.

But just because a document isn’t associated with a formal workflow executed through rules, that doesn’t mean it isn’t, or shouldn’t be, associated with a workflow. Teams should negotiate what process they want to use to co-create the document, and that process, must, at minimum, include negotiation of:

1. Negotiate intent, tools and process,
2. Conceptualize
3. Create the document. (which may include subtasks such as brainstorming or outlining)
4. Iterative feedback and review of the document
5. Approval of document content
6. Layout decision point: Publish as-is or move content into a layout process — if layout is selected, a new workflow initiates for document design review.

Regardless of the workflow approach, co-creators must know the state of a document, such as draft, review, released, etc., so that they can respond to it appropriately.

7. How to integrate the feedback

It is likely that only a handful of people will actually comb through the feedback and integrate it into the document, but it is important that the approach to feedback integration be negotiated at the start for three key reasons.

First, the process of acknowledging feedback needs to be clear so people know what was accepted, integrated and why, as well as the reasoning behind any rejection of input. As part of that process, they also need to understand how editorial decisions are appealed.

Second, by making the feedback incorporation process transparent, this process reinforces the decisions made about how feedback is collected. If people recognize that marking up a PDF with handwritten notes will prove inefficient, they will be more likely to use, for instance, track changes and comments in apps like Microsoft Word and Apple Pages, if those are the negotiated approaches decided by the team.

Third, this is the place where you also negotiate version cut-offs. Once feedback is incorporated, and a reasonable (negotiated) time elapses, it is good practice to accept all changes and create a new, clean version of the document. This means that the history associated with the current document will no longer be visible in the current version, and for all intents and purposes, you have a new document over which you are collaborating.

Additional considerations

It is highly recommended that these seven points be considered every time a document is at the center of a collaborative activity. There are other considerations, however, such as mobility, how to deal with the default communication method, typically e-mail, and how to think about “packages” of documents, that should also be considered.

Mobile collaboration

Negotiations about the application, storage and feedback must include mobile app features and capabilities for teams that work on mobile devices. While many mobile applications are now offering features on par with their desktop versions, not all do. And in the mobile world, features like annotation may actually exist in a wider variety of tools (such as marking up a PDF) than they do on the desktop—without the proper cautions, some of these documents will end up with feedback that cannot be further annotated in the “negotiated” application, or even be read by it.

Avoiding e-mail for document collaboration

E-mail is not a good tool for collaboration, although it  is probably the most common tool. E-mail, when using attachments, creates non-integrated duplicates of each document sent, meaning that any revisions or feedback must be manually or programmatically reintegrated into the original document.

E-mail also creates a lack of transparency. If, for instance, there is a clear typo in a paragraph, in e-mail, each person is likely to see that typo and correct it. Editing a document in a shared repository will reflect the first person’s edits, which will be seen by everyone, eliminating the need for duplication of effort.

E-mail can be used effectively for notifications and repository link sharing.

Creating “packages” of documents

Although this Practice Insight focuses on a single document, most documents exist in packages or groups. Marketing may create a package of collateral to support a product, and proposals are often created from various documents owned, created and curated by the functions collaborating on a proposal. Sub-teams collaborate on their content, modifying it for a particular customer need, and then the entire document might be put together, not in a “final form” but as a combined document that will require further editorial collaboration to give it a single tone and to ensure references and acronyms are used consistently throughout.

A final annotation

Good content creation is fundamentally different than ad hoc projects. Innovative thinking, reconciliation of diverse view points and conceptual consistency require a process that can accommodate structured reflection. It is important to select the right environment and negotiate the proper expectations if you want your white paper, proposal or legal document to reflect the best output the organization can muster.