12.  Collaborative Writing.     

Writing teams: 

When you were in college, cooperating with other students to write a paper or using so-called boiler-plating methods to assemble a paper may have verged on plagiarism.  Especially if the first draft came from somewhere like www.cheathouse.com.  In business and science, collaborative writing is frequent.  Teams may be variously composed.  Here are three different teams:

Topics or Job Specialty Team
Subject-matter expert:	Scientist or engineer responsible for the accuracy of the technical content.
Technical review:	Review of the literature section, fact checker, technical proof-reader, bibliography.
Graphics or Webmaster:
Technical Writer:	Assembles and unifies the document.
Legal:	Not necessary for in-house.
Security:
Physical plant, facilities, equipment:
Personnel:

Writing Process Team
Planning:	Involves everyone to decide contents, organization, and style.
Drafting:	Individuals write various sections with occasional collaboration.
Revising:	Everyone edits the various sections.
Technical Writer:	Assembles and unifies the document.

 

Boiler Plate Team
Front matter:	Abstract, keywords, introduction.
Chapters or units of the body:	Various people write individual chapters.
Back matter:	Bibliography, glossary, appendix.
Technical Writer:	Assembles and unifies the document.

Advantages of Collaboration:

• Collaboration relies on a broad knowledge pool.  Multiple authors catch mistakes that single authors often overlook.  In the review of the literature section and methods section, multiple authors simply have more knowledge.
• Collaborative documents look better.  Single authors cannot be as expert as multiple authors in the various areas of document production: designer, writer, editor, graphic artist, business manager, technical expert.
• Collaboration improves audience analysis.  Each member of the team is a kind of pilot reader who improves readability by asking questions to clarify the message at both the planning and revision stages.
• Collaboration can improve working relations.  Group members working together on a project usually get to know one another and learn something about various jobs, responsibilities, and frustrations of an organization that a single author either ignores or has little chance to discover.
• Collaboration accelerates the process of integrating new employees.  They learn:
  • how things are done
  • who has authority for what
  • what forms to submit
  • what is done and isn't done
• Collaboration can reduce the problems that arise when key personnel are reassigned, quit, or retire.
• Collaborative authorship is the norm in science journals.

Disadvantages of Collaboration:

• Collaboration takes longer to produce documents.  People have to talk with each other, documents wait on people's desk or computer, and perhaps no one assumes primary responsibility for getting the document to the final draft stage.
• Collaboration can produce the lowest common denominator kind of compromise when people are defensive or politically wary about asking tough questions or taking responsibility.
• Collaboration can produce disjointed and uneven documents, especially when various authors produce sections of a report or proposal.  To reduce this possibility, a technical writer should assume responsibility for editing the entire document.
• Collaboration can cause inequitable workloads.  Workers may feel that some of their colleagues are getting a free ride.  Junior authors (e.g., graduate students) often feel they have not gotten sufficient credit.  
• Collaboration can reduce the effort expended on the project, if everyone feels that the document is primarily someone else's responsibility.  
• Collaboration can increase office politics.  Conflicts about methods, content, or even appearance can damage working relationships long after the project is over.

E-mail seems to be the first thought in collaborative communication.  But attaching documents that quickly change from one draft to the next and identifying various versions can be more of a problem than uploading the document to an FTP or http site on either an intranet or the Internet.  The difficulty is that each team member needs a user I.D. and password to authorize uploading his or her  revision. 

Meetings:

• Define the objective.  Take time to explain each of the sections in an RFP (request for a proposal).  
  • Agree on the kind of a document that will be produced (length, graphics, other components) and the schedule for producing it.  
  • Specify as concretely as possible who the audience is and what they are likely to be looking for.  
  • Decide on how "mission critical" or important to the company the project is.  
  • Begin to determine what resources will be required.  The budget often answers many initial questions.
• Choose a team leader.  This person will schedule meetings, facilitate communication among group members, and be responsible for guiding the project to completion.
• Partition the project into chunks assigned to team members.  Each group member will continue to edit the entire document, but will have one or more sections of primary responsibility.
• Determine who is responsible for technical content; who is responsible for document production into the final draft.
• Establish communication procedures: 
  • Everyone has everyone else's e-mail addresses from the first meeting.  
  • When and where do we next meet?  
  • An agenda e-mailed prior to the next meeting?  
  • What do I have to do, by when?  
  • Do I work only on my unit or do I critique other units?  
  • Where do I find the other units?  
  • Increasingly, answers to such questions are put on a  Website.  
• Establish methods for resolving conflict.  Disagreements are inevitable.  On difficult issues, give everyone a chance to express his or her ideas.  If an idea is idiotic, resist the temptation to ridicule it.  
  • As much as possible, try to separate ideas from personalities.  
  • Instead of identifying a proposal as "Tom's idea," try to find a more impersonal designation: "this plan" instead of "my idea is . . ."  
  • Tell yourself not to get emotionally attached to your suggestions.  When you do, you listen to other ideas only for points to attack.  
  • Don't ignore body language.  Are people glancing at their watches?  
  • People may nod their heads to suggest they understand.  A direct question might reveal that they don't.    
• Designate someone to keep track of brainstorming ideas.  Many meetings end indecisively.  Ideas might be jotted down on a white-board or a computer with a projector so that the meeting doesn't simply ramble on with little focus.  
  • Do not be in too much of a hurry to decide things.  Part of the purpose of the meeting is to generate a team spirit so that everyone is committed to the project and not just sitting in a chair.
• Create a style sheet to avoid needless revision.  Determine things like a decimal outline, fonts and sizes for heads, methods of pagination, and citation.
• After brainstorming has suggested components of the project, establish a tentative work schedule with deadlines for each team member.  Determine which task must be accomplished before others can begin.  
• Seek to clarify or summarize what has been accomplished in the meeting.

Conducting Meetings:

• Start on time.  Try to finish on time.  The chair may be having a good time; no else is.
• Have an agenda.  Try to stick to it.  If the discussion repeatedly drifts into another direction, suggest scheduling another meeting to talk about it.
• Record significant points and decisions.  Since you are running the meeting, ask someone else to record points and go over the record with them at the end of the meeting while the ideas remain fresh in your memory.
• Repetition is good.  Summarize what the meeting has accomplished or decided.  Ask if each member of the team understands his or her assignment.  
• You may want to think about role-playing at meetings.  Some people adopt these roles without much self-awareness.  Group members may be assigned the task of playing one of these roles at a meeting:
  • Initiators: throw out ideas, propose different ways of defining the problem or defining relevant data or methods of analyzing data.  No details, just the big picture.
  • Fact seekers: ask what evidence is necessary to compel readers to accept recommendations or the big picture.  "How do we prove it?  Is this what target readers will expect?"
  • Fact providers: perhaps less focused on the abstract level of the project, they know how to get the job done or where to find the data necessary to support the argument.
  • Opinion seekers: the opposite of the person who dominates every meeting.  They seek out reticent members encouraging them to contribute.
  • Opinion givers: need to be self-conscious to avoid dominating the meeting to make it a platform for nothing but their own opinions.  When they are self-conscious of their role, they can be effective facilitators; being provocative or otherwise acting as a catalyst for the group rather than "displaying."
  • Clarifiers: speak when the group is confused or silent.  By restating points and explicitly making connections, they get meetings back on track and completed on time.
  • Elaborators: they see the next step.  Adept at inferential thinking they speculate on applications, entailments, and cautions.
  • Summarizers: often the group leader.  This person should repeat key points, conclusions, and recommendations

Critiquing a Draft:

• People are "sometimes" defensive about their writing.  Start with a positive statement: "I can see that you put a lot of work into this."
• Revision and editing are not necessarily identical.  Revision is more concerned with organization, layout, illustration, or the accuracy of large elements.  In editing the final draft, you are concerned with unity, coherence, style, usage, grammar, and readability or audience analysis.  In critiquing a draft, consider the scale of your criticism in something like this descending order:
  • organization, design, decimal outline, table of contents or conceptual components, audience analysis
  • logical flow, evidence, methods, graphics
  • unified paragraphs, complete sentences, passive voice
  • grammar, punctuation, proofreading, readability
• Talk about the document rather than attacking the writer: 
  Not: "What did you mean here?  Where did you get this harebrained idea?  You don't make sense."
  But:  "I'm having trouble understanding how this is related to the major point.  Can you explain it?"
  Not: "Why didn't you illustrate this part?  Anybody would know that it must be illustrated."
  But:  "I wonder if the report would be better understood by the target audience, if this part were illustrated?"
• Criteria-based comments measure the draft against an example.  Many documents have ancestors or predecessors.  Comparable documents can serve as standards for both style and layout or organization.  A third property like this can reduce the "me" against "you" antagonism.  Successful proposals are sometimes promulgated by funding agents to illustrate how to write your proposal.
• Reader-based comments should attempt to simulate the target audience.  Do not nod in agreement to technically sounding gobble-de-gook because it sounds technically impressive.  If you don't understand, say so.  If you get lost in a maze of details, say so.  If you think an illustration might aid comprehension, say so.
• Think about soliciting an outside reader, probably in your organization.  Like a single author, team members may be so familiar with the project that they lose the ability to simulate target readers.  Outside readers may be either expert about the topic or closely approximate the target audience.
• Revision can be never ending.  There is no perfect solution or perfect document.  Have a sense of scale.  Formal correspondence, proposals, and reports addressed to readers outside the organization have higher standards of correctness than internal memos or reports done for record keeping.
  

Reviewing a Draft:

Peer Review 

After revising and editing your document, ask a colleague to read it.  This will probably be someone as expert about  the content as you and more expert than later readers or target readers.  Consequently, he can catch omissions or errors in the content better than other reviewers.  Since this person is likely to be a friend, the situation is less formal and consequently the criticism less stinging.  Consider these points when asking someone to do a peer review of your document:

• Tell the reviewer exactly who the target audience is and what you want from them.  Provide necessary context about how the problem arose, what constraints you had, and whatever else may be understood by the target audience.
• Ask the reviewer to answer specific questions, like: "are the methods of data collection adequately described?"; "is the illustration on p. 7 stand-alone intelligible?"; "check the bibliography for missing references."  Avoid overly general questions.
• Recognize the reviewer's talents.  Ask him to comment on what he knows best.  Do not waste his time asking him to proofread your document.   

If you are doing the review for someone else's document, avoid general criticism: "it seems rather vague."  Try to make specific suggestions about solving problems you find.

Technical/Factual Review 

For academic or research papers this process may be associated with "blind referees" for journals who make judgments about submission regarding the significance of the problem, the adequacy of the solution, the soundness of methods, the scope and analysis of data, and the thoroughness of the review of the literature.  For industry the concerns are not to embarrass or even imperil the reputation of the firm by making a factual error.  A company is also concerned not to underbid a project because of an error in estimating some part of the proposal.

Editorial Review 

This review hopes to improve the readability of the document.  The editor tries to simplify and clarify, without altering the technical content.  This reader is not familiar with the project.  Consider these tasks as you read:

• Your first task is to read the draft for content, continuity, organization, and intelligibility.  
  • Do you understand each section and the overall organization?  
  • Like most readers, you probably start by examining the table of contents, then reading the informative abstract.  
  • When you believe you understand the document, consider how the author has  organized and illustrated the work.
• Make marginal notes as your read.  If you have to reread passages to understand them, mark those passages as vague or unclear.  Help the author by suggesting illustrations or examples for unclear concepts.
• Understand that your task is to help the writer revise his document rather than make judgments from your point of view.  If you think the entire project is wrong-headed, you are providing a "technical review" rather than an "editorial review."  Seek to place the problems you have noted within the contexts provided by the document or the author in regard to target audience, journal or organization conventions, and effectiveness in achieving the goals explicitly or implicitly stated by the document.
• In addition to your marginalia, make a list of your suggestions, ordering them from most significant to least.  
  • "The problem is construed too technically.  Why is this problem significant?  To whom?  Pursuant to what?  What difference does it make?  How much money would it save?"
  • "The description of collection methods is too abbreviated for your target audience to understand.  Explain each step of the process.  Think about illustrating . . . ."
• Finally, read for grammar, mechanics, punctuation, acronyms, citations, stand-alone graphics, and typos.

Managerial Review 

There is often something like an adversarial difference between staff and management concerns for a document.  Consider these conflicting concerns:

Writers' Concern	Manager's Concern
This document demonstrates what I have been doing.	This document needs to promote the organization's goals.
He won't tell me exactly what he wants.	He pitches notes and rough drafts at me and thinks I can read his mind.
I don't understand his criticism.  He is either out to get me or can't be pleased by anyone.	It takes 3 or 4 reviews to get him to produce an acceptable document.
He tries to rewrite my document to make it sound like his work.	I spend too much time trying to be an English teacher.
I spend too much time writing documents no one reads.	Does anyone read the stuff they send me!

• Managers and research directors often view reports, proposals, and presentations as steps taken to finish projects.  
• Researchers often view these documents and occasions as opportunities to prove their worth.  
• Like audience analysis, communication about various organizational concerns and responsibilities ("discourse community" roles) can sometimes reduce conflicts.

Legal, Ethical, Security Reviews 

Writers may not boast or exaggerate, but they are usually advocatory to some degree.  They write persuasively to convince readers.  Less involved readers, such as lawyers worried about implied contracts, may be concerned to have writers acknowledge alternative methods, different points of view, possibly secondary or unintended effects, gaps in logic, the limits of present technical capabilities, or standard (cost-effective) procedures.  They may wish the author to provide a larger picture or context that seems to diminish the significance of the problem or solution.  They will be picky about copyrights, patents, liability, and crediting sources.  This kind of review will also be concerned with:

• How research promises may seem to imply specific claims about products, services, schedules, facilities, and costs.
• Records of what you did, when you did it, and how you did it.  
• Proprietary knowledge, security.
• The appearance of plagiarism or copyright infringement.  

Back to navigation