Chapter 1

Planning Your Collaboration

At the end of a semester-long project on advanced database techniques, Eduardo, a graduate student in computer science, reflected on his team’s collaboration:

Interviewer: Did anybody give you any input on the sections of the report that you wrote?

Eduardo: No. No, nobody gave their opinion on anybody’s work.

Interviewer: Did you expect them to?

Eduardo: Well, at the beginning, yes . . . but then everybody submitted at the last minute, so it was rushed. Umm, also we didn’t have a chance ’cause we didn’t meet after we submitted the draft. At that point, we were in finals, and we weren’t going to do anything else.

Interviewer: How do you think your teammates would evaluate your contribution?

Eduardo: Well, I would hope they would say I did the most, but I don’t know. I don’t think some of them read [the final report].

Thomas, a biology student in a technical writing class, also feels that his collaborative project did not live up to his expectations:

Thomas: Personally, I thought we could have used class time better.

Interviewer: How so?

Thomas: Because I think we could have got more of it done outside of class. . . . It took us 50 minutes to revise about half a page because of word choice or how we wanted to say it. I think that we thought we were actually more ahead than what we were . . . and then the final deadline caught up to us. It snuck up on us.

Susan, an undergraduate majoring in math, similarly expresses frustration with a collaborative project she worked on in her technical writing class:

Interviewer: So how did you decide who was going to do what?

Susan: Well, originally we all decided that we were gonna get together and do the Web site, but Rene took the disc and drafted the site herself. And then the rest of the project was just kind of, we volunteered for stuff as it came up, I guess.

Interviewer: And how did you feel about that?

Susan: It kind of destroyed our group working together. . . . We were going to do it all together because none of us knew how to do a Web site, and then Rene just went and did it all . . . and then she had to come back and explain it to us.

These three students — and all the other students discussed in this book — were members of actual student teams observed as they worked on team projects in technical writing and engineering classes. Like the majority of the teams observed, these student groups had problems working together toward a common end. In some cases, students weren’t aware of what their teammates had done, other teams failed to budget their time effectively, and still other teams ended up with hurt feelings and resentment. This textbook is intended to teach you to replace such frustrating team situations with ones where you coordinate with your teammates to produce work that is better and much more innovative than what any one of you could have created on your own.

This book focuses on the role of writing in effective teamwork. First, you will learn to produce the types of internal team documents that are absolutely essential to a well-run project — documents such as task schedules, meeting minutes, and team agendas as well as e-mails and memos that help head off potential problems. Second, you will learn how to write and revise large documents as a group. This focus on large documents is important because so much collaboration in fields like engineering, business, computer science, medicine, and hard sciences (to name a few) involves major written documents such as design plans, proposals, reports, manuals, and Web sites. This book teaches you specific writing strategies for managing such large documents.

Before you continue reading, take a moment to review the three preceding scenarios and reflect on why these student teams experienced breakdowns. What could these teams have done differently to prevent the problems they experienced?

Why Teamwork?

These three scenarios illustrate the various problems that student teams can encounter. Given the problems with collaboration, why do teachers assign team projects in the first place? Group projects are typically assigned in school for two reasons:

Let’s take each of these reasons separately. First, collaboration has become the norm in most workplaces. On large, complex projects, no one person has all of the expertise and experience (let alone time and energy) to complete the project by himself or herself. Even smaller projects tend to take advantage of teamwork. People working together can often produce better outcomes in less time than any one person could produce independently. Team members benefit from a diversity of approaches and perspectives that lead to innovative insights.

However, teams often fail to work together effectively — and that failure threatens the entire project. For instance, Tom DeMarco and Timothy Lister (1987), experienced software specialists, write:

The success or failure of a project is seldom due to technical issues. . . . If the project goes down the tubes it will be non-technical, human interaction problems that do it in. The team will fail to bind, or the developers will fail to gain rapport with the users, or people will fight interminably over meaningless methodological issues. (p. 88)

Because poor team skills waste so much company time, businesses are now putting pressure on educational institutions to provide authentic team experiences that will produce college graduates with strong interpersonal, management, and coauthoring skills. Instructors assign team projects to give students opportunities to develop these skills.

Second, instructors assign team projects so that students have opportunities to learn from their peers. Many students are motivated by collaborative learning. Co-writing and collaborating give students opportunities to share expertise, learn from others’ mistakes as well as successes, and — most importantly — solidify what they have learned by teaching it to others.

Unfortunately, teams in school settings do not function just like teams in the workplace. Unlike school-based teams, work-based teams can develop longer histories of working together and are more likely to have clear-cut lines of authority. Thus, school-based teams have some unique challenges that are not present in work-based teams. This textbook attempts to teach you how to navigate some of these challenges using strategies that you can also carry into the workplace.

Understanding Collaboration Methods

The three scenarios that begin this chapter illustrate some of the problems that arise when teams fail to fully plan out a project and agree on a collaboration method. In all three cases, the students being interviewed disagreed with their teammates over the specific steps the team needed to follow. These conflicting views of how the team should go about collaborating hurt the quality of the final projects and led to dissatisfaction with the team.

Understanding different collaboration methods and their respective costs and benefits can help teams identify and negotiate conflicting visions of how the group should proceed. When working on documents, groups can structure their collaboration using one of three basic methods (see Figure 1.1):

The type of collaboration method a group uses has significant consequences for how the work proceeds. In the interviews beginning this chapter, Eduardo describes experiences typical of groups that rely on divided collaboration. Team members completed their individual sections at the last minute, there was no time for discussion of the final draft, and Eduardo is not sure if his teammates even read the final report. Moreover, one of the team members produced a section that was of particularly low quality — contributing to the disappointing grade this group received.

Whereas Eduardo’s group never met to discuss the draft, Thomas’s group tried to complete all of its work in team meetings. The team members’ attempt to draft their entire proposal face-to-face not only was inefficient but also lowered project quality because they were rushed for time at the end and ended up dropping sections. In addition, although Thomas was not aware of it at the time, one of the group members was extremely upset with the group dynamics, perceiving the team as not valuing her input. When a team relies too much on face-to-face collaboration, such resentment is common because it is virtually impossible for three or more people sitting around a computer to contribute equally.

Susan’s group illustrates how the failure to discuss a collaboration method as a group can produce conflict. Susan felt the group should have created the Web site face-to-face; however, Rene operated using a layered collaboration method in which she completed an initial draft and then tried to hand the project off to others to revise and finish. Although this layered approach seemed more appropriate to this project than Susan’s face-to-face method, Rene’s failure to discuss her collaboration plans resulted in a major breakdown in group dynamics.

See Table 1.1 for a summary of the advantages and drawbacks of the face-to-face, divided, and layered methods of collaboration.

Table 1.1. Advantages and drawbacks of the three collaboration methods

Despite its substantial advantages, student teams tend to underutilize layered collaboration — probably because it requires the most planning and experience of the three methods. While face-to-face collaboration and divided collaboration seem to come naturally to student teams, layered collaboration requires forethought and some basic training to use it effectively. In part because layered collaboration is unfamiliar to students — and in part because it is the form of collaboration that most frequently leads to higher-quality products — this book stresses layered collaboration in much of the advice and many of the examples provided.

Alternating Collaboration Methods

Often when students are assigned a team project, their first instinct is to schedule a series of face-to-face meetings. Not only does this put a tremendous strain on everyone’s personal schedules, but face-to-face collaboration may not even be the most productive form of collaboration for the group at this stage. By figuring out which type of collaboration will be most beneficial at various stages in the project, team members can avoid many problems and ensure that they use their time together productively.

Few experienced teams rely exclusively on a single collaboration method. Most teams alternate collaboration methods throughout the project, depending on what the group is trying to accomplish at each stage. Thus, a team will often begin with face-to-face collaboration in the early stages of a project; switch to layered collaboration to complete the “heavy,” detailed work of the project; and then switch back to face-to-face collaboration to discuss revisions or to work out a presentation. Or the team might initially divide up the work so that each team member drafts a section independently and then switch to layered collaboration for the revision process.

Table 1.2 illustrates a group that alternates the face-to-face and layered collaboration methods. In the early stages of the project, the group meets face-to-face to discuss the project’s direction and to assign tasks to team members. About a third of the way through the project, the group switches to layered collaboration, with team members successively adding to, elaborating on, critiquing, and revising one another’s work. Table 1.3 provides an overview of which types of collaboration are generally most effective at various stages of a project.

Switching collaboration methods might seem complicated at first. However, with a clearly defined task schedule, such as the one in Table 1.2, groups can easily stay on task. In fact, if you take away only one lesson from this book, it should be this: a well-planned task schedule is key to the success of any collaborative project. Task schedules will be discussed in more detail in the following chapters.

Table 1.2. Task schedule from a project that switches from face-to-face to layered collaboration

Tim is the researcher and client expert; Stephen is the project manager and secondary writer; Charlotte is the primary writer and editor. Note that the task schedule can be color-coded or shaded to highlight each team member’s responsibilities.

Table 1.3. Most appropriate collaboration method for various stages of a project

Work Cited

DeMarco, T., & Lister, T. (1987). Peopleware: Productive products and teams. New York: Dorset House Publishing.