Chapter 2

Project Management

In a team evaluation at the end of his project, Ryan commented:

Audrey was a great project manager. She really kept us on track. There were several times when I wasn’t sure what I should do next. Then I just looked at her minutes and saw what it was I needed to finish up.

On another team, Bill similarly attributed team success to good project management:

Steve did a great job keeping everybody updated. Because of him, everybody knew what their deadlines were and how the group was going. This was the first time I’ve been on a group project where everybody didn’t wait until the last minute to throw everything together.

Project management is one of the least understood aspects of collaboration in student teams. Before we continue discussing how to organize a collaborative project, you should understand what project management involves and why a project manager is necessary — even on small projects.

Why Do You Need a Project Manager?

Students frequently confuse the role of project manager with “boss,” “leader,” or even “dictator” and quite understandably decide that they do not want a project manager on their team. Instead of viewing the project manager as a kind of supervisor, think of the project manager as someone who plays a specific role on the team by keeping the project on course. The project manager’s primary responsibility is to track the status of the project and to ensure that all team members know what they should be doing at any moment.

The larger and more complicated the team project is, the more important the role of project manager becomes. However, even small two-person projects can benefit from someone who acts as project manager by summarizing tasks and deadlines for the group. Often the project manager will do other work for the group; however, according to Charles Stratton, a technical writing consultant, even if he or she does nothing other than coordinate the team, the project manager “has earned his [or her] keep” (Stratton, 1989).

The project manager’s specific duties include the following:

In addition, the project manager may, if needed, perform other tasks:

On most projects, the manager will be doing work in addition to coordinating the project. Thus, a project manager might also double up as a co-writer, artist, or some other role on the team. However, on very large projects, it may be sufficient to have a project manager who does nothing other than manage the team.

The remainder of this chapter focuses on the three types of documents that are essential to good project management: task schedules, meeting minutes, and meeting agendas. This chapter also describes additional documents that the project manager should produce.

Task Schedules: Publicizing Deadlines and Responsibilities

Once the team has brainstormed some initial ideas for the project and discussed how to organize the collaboration, the project manager needs to create a written task schedule that documents deadlines, tasks, and responsibilities. Such a document is absolutely essential to effective collaboration. (See Chapter 4, “Getting Started with the Task Schedule,” for more details on how to develop and schedule a collaborative process.)

At a minimum, every project (even a two-person project) needs a task schedule that lists the three Ws: who is responsible for doing what by when. This task schedule is continually updated as work is reassigned, new tasks are identified, or deadlines change. Table 2.1 shows a task schedule for a group collaborating on an instruction manual.

Each entry in a task schedule contains three vital pieces of information: a name, a deadline, and a brief description of the task. A good task schedule should also build in padding — additional downtime between major steps that allows the group to recover in case a particular step takes longer than expected. For instance, this group has built in two days of padding between 9/12 (the date that everyone’s drafts or tasks are due) and 9/14 (the date that the usability tests are scheduled). Similar padding is built into the schedule between 9/19 (the date that Amy will compile and edit a completed manual) and 9/21 (the date the manual is due). This padding allows the group to stay on schedule even if one or more of the major parts of the project are unexpectedly delayed.

To be effective, a task schedule needs to be visible. Thus, the project manager must distribute the schedule to the entire group (usually through e-mail) each time it is updated. In addition, it is a good idea to keep a copy of the task schedule in a centralized document server that the entire team can access. The project manager may also want to e-mail a copy of the team’s initial task schedule to the instructor so that he or she has a copy in case the group has problems with an individual team member later in the project.

Table 2.1. Task schedule for a three-person group working on an instruction manual

The task schedule in Table 2.1 reflects a layered collaboration model. Each team member has his or her own set of responsibilities but also has opportunities to comment and improve on work created by others. A task schedule is essential for implementing a layered collaboration. Such a carefully structured and planned project has a high potential for success.

Dangers of Operating without a Task Schedule

The need for a task schedule should be obvious; nonetheless, many student teams try to operate without one. Without a task schedule, teams are likely to:

Finally, without a clear task schedule that has been circulated via e-mail and/or stored in a centralized group space, teams have no way to appeal to the instructor if someone on the team fails to do his or her work. Without written documentation, the instructor has to take the word of the complaining student. A written task schedule gives the instructor a resource that he or she can use to implement penalties and reassign work.

Meeting Minutes: Building Accountability and Consensus

The following conversation illustrates a common misconception that students often have about meeting minutes:

Interviewer: Now, I noticed that in team meetings you frequently took notes. What was in those notes?

Jessica: I have them right here. . . . Here’s some, showing what everybody had to do.

Interviewer: Okay. So when you took notes, it was along the lines of what different people had to do?

Jessica: Exactly.

Interviewer: Did you ever e-mail notes out to group members? Or just say this is a reminder of what we did or what we decided on?

Jessica: No, I didn’t, but that’s a good idea. I think they all saw me write, I think. Maybe I thought they were writing them down too, so they may have them.

Interviewer: Yeah, but different people could have been writing down different things.

Jessica (surprised): That’s true. I didn’t think of that.

Many teams confuse meeting minutes with individual note taking — or with secretarial work that simply records everything that happened during a meeting. In fact, meeting minutes are managerial documents that direct the project by deciding what information is important enough to include and what needs to happen next. Good meeting minutes help the team come to a consensus on the project’s progress, who is responsible for what, and where the team needs to go next.

Good meeting minutes contain the following (see Figure 2.1):

In addition, meeting minutes must be distributed to the entire team soon after the meeting, usually within 24 hours. The minutes are useless if team members do not have them in their hands to refer to. If a team does not have time to distribute minutes after a meeting, then it didn’t have time for the meeting itself.

Randall Walker, an industrial engineer with 15 years of management experience in the military, explains that minutes are essential:

You can say one thing to five people and they will interpret it five different ways. It’s critical to put team decisions in writing because at least it gives them an opportunity to say “No, that’s not the context of what I said,” or “That’s not the way I interpreted what we agreed upon.” If you don’t have it documented, it’s he said/she said three weeks [later]. . . . So I think documentation of those encounters [is] absolutely critical in moving forward; otherwise you take one step forward and four steps back and one step forward and four steps back, and you can only take so many steps back before you drop off the cliff.

Andrew Grove, the CEO of Intel, a major computer chip manufacturer, agrees:

If a meeting was worth calling in the first place, the effort to produce and distribute the minutes is a small additional investment necessary to realize its full benefits. (Grove, 1995)

The most important information in the minutes is the list of action items detailing who will do what. Ken West, an operations research manager with more than 10 years’ experience supervising teams, clarifies:

Even if you don’t produce formal minutes, at the end of the meeting, there should be a page that says you’re going to do this, you’re going do this, you’re going do this, and you’re going to do this. The person who is the project manager better make sure that that’s written down. It’s their responsibility to follow up that things get done.

Dangers of Operating without Meeting Minutes

As the previous quotes from managers testify, meeting minutes are essential to the forward progress of a team. Without a central set of minutes, teams will

Meeting Agenda: Keeping Discussions on Track

A meeting agenda is a brief list of topics to be discussed at the meeting. This list of topics does not need to be comprehensive — in other words, the team can discuss items not on the agenda; however, an agenda helps ensure that nothing important gets left out of the discussion. When people who are not part of the team attend a meeting, a brief agenda is particularly important because it lets them know what to expect and allows them to prepare for questions team members might ask.

To allow people time to prepare for the meeting, an agenda should be distributed in advance of the meeting (see Figure 2.2).

Dangers of Operating without a Meeting Agenda

A meeting agenda is essential to make sure that the team meeting is really needed and that the team stays on track. Without a clear agenda, teams will

E-mail Reminders and Notifications: Stepping In When Problems Occur

The project manager is always focused on the future direction of the group. Even meeting minutes, which at first might seem just to be records of past actions, are produced in order to shape the group’s future direction and ensure that everyone follows through on commitments made during the meeting.

In the unfortunate event that some teammates are negligent in performing their duties or a project goes off schedule, the project manager needs to continue this focus on the team’s future. Thus, when a project manager steps in to take action on missed deadlines, missed meetings, or unacceptable work, his or her focus needs to be on finding a solution rather than spreading blame.

How forcefully the project manager steps in depends on the situation and the severity of the offense. Usually, small problems can be handled through gentle reminder e-mails. Larger problems that threaten the project’s success may require contacting the instructor.

For instance, a project manager should always send a “gentle” reminder to a teammate immediately after a deadline has passed. Figure 2.3 illustrates a gentle reminder sent directly to a teammate who has missed a deadline. This reminder assumes that Susan plans on completing the work but either has encountered unexpected difficulties or has had some personal emergency that has prevented her from completing the work on time. The e-mail focuses on highlighting the effects that this lateness might have on the team’s future schedule.

The next step up in severity occurs when a teammate is several days behind schedule, has missed deadlines in the past, or has otherwise shown himself or herself deserving of a more pointed reminder. This reminder should gently point out the consequences that the teammate’s actions have on the rest of the team. The project manager may want to copy the entire team in the “cc” section of the e-mail. Figure 2.4 illustrates a pointed reminder.

If a teammate does not respond appropriately to this pointed reminder, the project manager might want to send an e-mail to the instructor, if for no other reason than to document the team’s problems. Figure 2.5 illustrates an e-mail notifying the instructor about a problem.

Chapter 8, “Troubleshooting Team Problems,” provides additional advice on handling problematic teammates.

Other Documents the Project Manager May Produce

Task schedules, meeting minutes, and meeting agendas should be produced for any project, no matter how large or small. These documents are essential to keeping the team on task. Projects that neglect these are destined for trouble and unproductive conflict. However, larger projects may require additional routine maintenance documents with which the project manager keeps the team on track. (See Table 2.2.)

Starting the Process with a Straw Document

A “straw” document is an excellent way to start a group writing project that is taking on a complex task for which no clear format exists. A straw document is basically an extremely rough skeleton of the project that the writer expects to be blown down, like a straw house. The purpose of the straw document is to draw the team into a discussion of the pros and cons of various directions the project might take. In this way, the straw document is a tool to facilitate group brainstorming about specific details.

With a straw document, the project manager brings in a very flimsy but relatively complete draft of the entire document or document section. The straw document should contain a comprehensive list of topics or points the document needs to address, but the details do not have to be fully fleshed out. The goal is to have something down on paper so that the team can begin to discuss the drawbacks and benefits of various alternatives.

Table 2.2. Additional documents a project manager may need to produce

Because of the nature of straw documents, they are used only in the very beginning stages of writing. The writer of the straw document must be ready to stand back and not become upset when others eventually knock down parts of the document. One engineer with extensive experience working on major proposals clarifies this point:

An important point when you put a straw [document] up is that people mustn’t be offended if other people criticize it, tear it apart, offer constructive criticism. You’ve got to take it in the light that different people have different opinions. It saves a lot of time. If you hadn’t written it down [as a straw document,] they wouldn’t have thought about it. (Sales, 2006)

Another engineer at the same company states that the great advantage of the straw document is that “it doesn’t matter if you get it wrong. In fact, you expect to get it wrong, so you can rush it out any old how. It is safe to do so because you know it will be sorted out later” (Sales, 2006).

Sometimes, groups can benefit from looking at several different straw drafts. This is often the case when there is serious disagreement about how to proceed. In this situation, one or two team members prepare multiple drafts for the group to compare and contrast.

When working with a straw document, everyone in the group needs to understand that it is intended to be a temporary document that will likely be completely rewritten later. It should not be confused with a complete draft of the document (see Chapter 6, “Revising with Others,” for information on working with more complete drafts). In other words, the straw document should be used to spark discussions about big, conceptual issues — and not issues such as word choice, formatting, or even the details of much of the content, all of which are more appropriately discussed at the rough-draft stage of the project.

Works Cited

Grove, A. (1995). High output management. New York: Vintage Books.

Sales, H. E. (2006). Professional communication in engineering. New York: Palgrave Macmillan.

Stratton, C. R. (1989). Collaborative writing in the workplace. IEEE Transactions on Professional Communication, 32(3), 178–182.