Seeing the Project: Mapping Patterns of Intra-Team Communication Events
William Hart-Davidson Rensselaer Polytechnic Institute 150 Pawling Ave. Troy, NY 12180 518.272.4118
[email protected] ABSTRACT This paper reports the results of a qualitative study of the communication patterns of two student teams engaged in a design and documentation task. All communication events for each team are recorded and analyzed to produce displays that show how well-coordinated each team was throughout the project. The sorting and mapping methods presented suggest a new class of features for groupware applications, features designed to allow members of collaborative teams to monitor and adjust their communication patterns during the lifecycle of a project.
Categories and Subject Descriptors H.5.3 [Information Interfaces and Presentation, Group and Organization Interfaces]; K.4.3 [Computers and Society, Organizational Impacts].
General Terms Documentation, Human Factors, Design, Management
Keywords Technical Communication, Collaboration, Diary Workflow Visualization, Document Management
Study,
1. INTRODUCTION It seems like common sense to say that a key to effectiveness for documentation teams is intra-team communication. But both the research literature on team-based communication in organizations and the applied literature in textbooks and journals of technical communication have little to say about what a significant percentage of a team’s communication looks like. Both of these literatures have traditionally focused exclusively on the outcomes of a team’s work – the deliverables – saying almost nothing about the day-to-day communication events that precede and facilitate the production of deliverables. This paper presents a study of intra-team communication patterns that lead up to the production of a deliverable. The results of this study are meant to shed some light on discussions of team process, a topic that is treated in both the research and applied literatures of technical communication and organizational communication, but which is often handled at a very high-level that glosses over the particulars of how a team
does or should actually implement a broader process model. More specifically, this study sought to develop a method for visualizing a collaborative team’s communication process in a way that might help members of the team to better understand and, perhaps, improve upon that process.
Nearly every technical communication textbook offers a description of an authoring and review process that teams should follow. These typically name stages meant to guide intra-team communication, but the models rarely go into detail about the amount, type, or even purposes of the interactions a team might have during a particular stage. Barker’s (2002) Writing Software Documentation: A Task Oriented Approach, for example, describes a nine-phase iterative process that includes the following steps: 1) perform the user analysis, 2) develop the program task list, 3) design the documents, 4) write the project plan, 5) write the alpha draft, 6) conduct reviews and tests, 7) revise and edit, 8) write a final draft, 9) conduct a field evaluation [1]. Each of these steps implies at least one and often many kinds of specific interactions that need to take place among members of the team, though these are not very carefully elaborated. For example, Barker’s description of step three, “design the documents,” lists various decisions a team will need to make such as deciding on the genres that will be produced (e.g. tutorial, reference manual), determining a layout standard to follow, and discussing the what kinds of support each product will offer to the various audience(s) it addresses. There are also specific tasks Barker recommends a team should complete during step three including “mak[ing] a detailed list of help topics,” and “outlin[ing] the documents.” Many questions remain, however. How should a team go about making these decisions? How should they interact to perform a task such as creating a list of help topics? Are there ways of interacting, moreover, that are more likely to be successful than others? Are there known pitfalls to avoid? These questions are not addressed in Barker, nor are they taken up in the research of technical communication as a whole.
Too often, it seems, the implementation of a process like the one Barker suggests is influenced more by time and operational constraints rather than by a sense of what might contribute to an effective outcome. Team members call meetings, set up conference calls, send e-mails, create and circulate drafts for
review, all in a rather ad-hoc manner. Where there are regular protocols in place, they usually involve “official” and/or extrateam communication of some sort that may not rise to the level of a deliverable, but which is nonetheless an agreed-upon checkpoint. Document reviews are one example. Client focus group meetings are another. But when it comes to planning the majority of communication events that take place during the course of a project documentation teams may have only broad guidelines, and the past experience of their members, to serve as a reference.
1.1 Ad Hoc Communication…So What’s the Problem? I am not suggesting that there is a problem with ad-hoc team communication per se. Certainly there would be a tremendous time and workload overhead required if teams had to follow detailed plans or “scripts” for each phase of a documentation project. I am not suggesting that this is what teams should do. But I do wonder if teams, and particularly successful teams, exhibit patterns of communication that are worth repeating. The research literature in areas such as organizational communication and information systems provides some guidance to teams regarding the nature of communicative exchanges, but this work tends to focus on single modes of communication (e.g. Frohlich, Whitacre, & Daly-Jones (1994) on conversation [2] or Isaacs, et. al. (2002) on instant messaging [3].)
at any given moment in the project so that they might change the way they are communicating. This study is motivated, in part, by the goal of developing a way to visualize team communication patterns so that team members, themselves, can understand and make changes that can help the team. One of the most valuable bodies of work on the communication habits of teams is applied research meant to guide the development of software and systems to support such work. Necessarily “practical” in its focus, this group of studies tends to draw inspiration for the design of new collaboration technologies from observing the interactions of team members, directly or indirectly. Generally speaking, this work examines patterns of routine activity in an attempt to identify communication software design directions. It is in this tradition that the present study proceeds. Accordingly, I will discuss some of the implications of the current project in conjunction with this body of work in the final section. A series of studies by Neuwirth et. al. [5],[6],[7] asked some questions related to the present study such as “what is the content of a team’s communication?” These lead to the development of a collaborative writing system – PREP editor. In this paper, I ask: “what does the combined set of communication events which characterize a team’s process look like?”; with the hope that the results might yield further design inspirations.
2. THE TEAMS In an early attempt to synthesize and apply work in organizational communication to technical communication team processes, Killingsworth & Jones (1989) distinguish between two models of collaboration that technical communication teams might follow: a division of labor vs. an integrated team approach [4]. In the division of labor model, coordination among team members is less important than the top-down monitoring of the process and outcomes. In its strictest form, “only managers observe and participate in the whole process by which documents are planned and produced” and “individuals are responsible for a clearly defined task which they are trained as specialists to perform.” An “integrated team” approach, by contrast, calls for “all members of a team [to] participate in all stages of production…with all team members offering advice and content at every phase.” Real teams, of course, likely fall somewhere between the two extremes, as the survey Killingsworth and Sanders’ conducted indeed showed. But there is still an obvious lack of specificity and, more importantly a problem in understanding the differences between the two models if we ask the question “what kinds of communication patterns characterize the two models?” And if real teams lie somewhere in the middle, might teams be communicating in an “integrated” fashion some of the time and a “division of labor” at other times? If so, it might be valuable for teams to know how they were doing
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Conference ’00, Month 1-2, 2000, City, State. Copyright 2000 ACM 1-58113-000-0/00/0000…$5.00.
In this study, the combined intra-team communication activity for two separate teams was tracked using a type of diary study methodology wherein each team member was asked to keep a record of each of their team’s communication events. The two teams consisted of graduate students enrolled in a course called Studio Design in HCI, a capstone experience for the M.S. in Technical Communication w/ HCI concentration at Rensselaer Polytechnic Institute. The teams were engaged in a semester-long project to design an original interface for a hardware or software device meant to transform an existing practice in the real world. This type of hands-on design project is intended to give the Masters students, many of whom are working professionals, an opportunity to bring theories and methods learned during their program together to create a tangible design suitable for their career portfolios. There are both on-campus students and distance students in the course, and teams can be comprised of any mix of these groups. For this study, one team consisting entirely of nonco-located members taking the course from their respective places of work was chosen along with a second team consisting entirely of on-campus (and therefore co-located) members. Teams were instructed to follow an iterative, user-centered design process in the course to produce their design. Along the way they were asked to create three technical memos which documented their emerging design. The second of these memos was a “conceptual design report” meant to establish the connection between user needs and requirements for the design with a set of core functions the design would provide. For this study, each team kept a record of all of the communication events they engaged in as they produced their conceptual design report,
beginning with an e-mail message from the course instructor that served as the “call” for the report and ending with the submission of the report itself. One reason for selecting teams from the Studio Design course for this project was the opportunity to examine the communication practices of teams who were doing fairly authentic documentation work, albeit for a grade in a course. Both the nature of the course and the types of students who typically enroll in it, though, made it an attractive and accessible initial testbed. All of the members of the distance team, for example, were working professionals. I learned from an interview that it was even common for the distance team members to be at their place of work when they were working on the class projects. But I also learned that both teams were strongly motivated by a desire to do well in the course, far more than they were motivated by what might be considered typical workplace factors such as the desire to create a good product/design. And while this exploratory study was never meant to produce widely generalizable results, the results that are discussed below can only be interpreted as the activity of student teams, and not workplace teams.
3. TRACKING COMMUNICATION EVENTS The diary study format used here is a relatively unobtrusive way to gather data about team activity that, due to its ad-hoc and spatially-distributed nature, is all but impossible to observe directly. Each team member was asked to make one entry for each team communication event using a structured format provided in an Excel worksheet. For each entry, team members recorded the date, number of team members participating, and the type of event (e.g. e-mail, phone call, etc.). They also indicated the purpose(s) of the event by selecting from a short list or writing in their own description. Diaries were kept for approximately a month and a half beginning in late February 2003, with the exact duration determined by the submission date of each team’s conceptual design report. To keep the team members focused on record keeping, we asked them to submit the most recently updated version of their diary at the beginning of each week. After the diary period had ended, I along with two research assistants compiled the data and assembled a master list of events for each team by comparing the diaries each member had submitted. As it happened, only one of the members on each team kept a rigorously thorough record of all team events. But because we also asked the members to forward us copies of all the texts that resulted from written events (e.g. e-mails, document drafts, etc.), we had a way to cross-check the diaries against the chains of responses to e-mails. Once we had assembled what we felt was a comprehensive list for each team, we held interviews with two members of one team and one from the other team in order to review the list for accuracy and ask follow-up questions. We were assured, each time, that we had a representative picture of each team’s communication activity. This activity is summarized in the table below.
Table 1. Communication events by type
Local team Distance team
E-mail
IM
F2F or Phone
27
0
10
1
38
57
5
2
0
64
Other
Total
We have not listed print documents or drafts circulated among the teams as separate communication events because the teams shared these as attachments to e-mail most of the time. The local team circulated five documents via e-mail, and used another extensively during a face-to-face meeting. The distance team circulated fourteen documents as e-mail attachments. For both teams, e-mail was the most frequently used mode of communication. And, as might be expected, the distance team needed nearly twice the amount of communication events as the local team did to accomplish similar goals. This difference should be noted by both teachers and students involved in distance education as well as by members and managers of workplace teams that are not co-located. The sheer amount of additional communication activity required to perform a complex task at a distance may be a factor that is taken for granted, but a glance at the event totals sorted by purpose for each team tells us that we might want to pay closer attention to these differences. To gather information about the purpose of each communication event, we asked participants to select from a list of options that included team coordination, task work, interpersonal, tech support, or other. Participants were allowed to double code events that served more than one purpose, so the numbers below reflect the total number of events that were coded for each purpose and, in parenthesis, the number of events that were coded for that purpose exclusively. Purposes team members listed as being in the “other” category included re-sending mail that had bounced, forwarding something that one team member may have misplaced, and the like. In the table below, we have combined the “tech support” and “other” categories; the local team reported no tech support events, while the distance team reported four tech support events and no “other” events. Table 2. Communication events by purpose
Local team Distance team
Team coordination
Task work
Interpersonal
Other/TS
21 (12)
12 (5)
4 (1)
10
17 (16)
26 (24)
20 (18)
4
This breakdown of events shows that much of the difference in total number of events between the two teams comes in the interpersonal and task-work areas. While we might have expected that the distance team would need more interpersonal activity to get to know one another from a distance via relatively lean media such as e-mail and chat, we had not suspected that they would need more than twice the number of task work events required by the local team. It is not quite accurate to say that the distance team worked twice as hard as the local team, but we can certainly say
that the local team communicated only half as much as the distance team in order to produce the same deliverable. The ability to meet face-to-face seemed to make a big difference for the local team in terms of task work, as we might expect. Of the twelve task work events the local team listed, half were faceto-face meetings. The distance team did most of their task work via e-mail, with two instant messaging sessions between two of the three team members thrown in, making for a tempting conclusion: have just a few face-to-face meetings and cut your emailing in half! But look at what happens to team coordination in the meantime. The local team needed, percentage-wise, quite a few more team coordination events to accomplish their work than did the distance team. The twenty-one events listed by the local team as involving team coordination constituted slightly more than half of their total number, while the seventeen events listed by the distance team constituted about a quarter of their total number of events. So perhaps the story here is that while the richer face-to-face medium allows a team to accomplish more in fewer events, it also requires more events dedicated to coordinating the team’s efforts? With such a small sample, we can’t say for sure. But we can say with some confidence that this seemed true for the local team when we talked with two of the three members. We can also say that members of both teams seem surprised by the number of events they engaged in. And when we showed them diagrams of their communication activity, they immediately began to replay the dynamics of their team’s process, suggesting that there may be some value in not only tracking team events, but visualizing patterns of events in order to give an overall image of a team’s communication during a project.
Here is the diagram for the local team. The icon key is as follows: e-mail = envelope; e-mail with attachment = envelope with a document; face-to-face meeting = oval with “f2f”; phone call = oval with “ph”; other = rectangle with slash (in this case, a to-do list on a PDA).
4. MAPPING COMMUNICATION PATTERNS TO “SEE THE PROJECT” By converting each communication event to an icon which represents the event type, we can create displays of the teams’ communication activity based on the data we have collected from the diary. The mapping method I employ below is a modification of one first proposed by Gunnarson [8]. Event icons are linked together to form chains that proceed in chronological order. The chains can proceed horizontally and vertically, with some data point being used to determine where each new horizontal line begins. In the two diagrams presented below, the data point used as a determining factor for starting a new horizontal line is the number of team members participating. This technique produces a diagram which shows when the team seems to be acting in a coordinated way – that is when all team members are participating – and when they are acting in a way that is line with either a division-of-labor approach or, perhaps, in an uncoordinated way. To put it another way, “working horizontally” in the following diagrams means to be working in a coordinated way, while “working vertically” may mean that members are working individually toward the team’s goal or, perhaps, in a manner that leaves one or more team members out of the loop.
Figure 1. Local Team Event Diagram As the diagram shows, they work in a fairly coordinated way for the first half of the total number of events, but this pattern changes as the project goes on. This display is also a bit misleading in terms of the way the events appear with respect to time. In fact, we’ve not considered time a factor at all except to create the running order of events, so any large gaps or lulls are obscured in this display. But for the sake of attending to coordination, this can be a good thing. When we showed this diagram to two of the local team members, what they saw matched their impression of the team’s progress. In particular, they saw a team that started off on the same page, but towards the end, seemed to be very uncoordinated. What was more surprising to them is that this is what my research assistants and I saw as well. By incorporating the purpose information, we were able to see that the majority of team events near the end of the project involved team coordination rather than task work and that these events often included only two of the three team members. What we suspected we saw was a team struggling with a non-responsive member, constantly needing to renegotiate the plan when one member failed to respond. What would we find when we looked at the distance team’s diagram?
Here is the distance team’s diagram. The icon key is the same with one addition: instant messaging session = word balloon.
The distance team’s pattern stands in contrast to the local team in that towards the beginning of the project they seem to be working in an uncoordinated way and despite a few spurts of coordinate effort that happen to correspond with two intermediate deadlines (one a conference call with the instructor and the other an oral presentation that acts as a kind of preview of their conceptual design), this team doesn’t communicate in a coordinated way until the end of the project. During our interview, we learned that one of the team members had been without their primary mode of intra-team communication – a laptop computer – for nearly a week towards the beginning of the project, accounting for the long string of uncoordinated events. This did cause the team to “get off on the wrong foot” according to our interviewee. In fact, the incommunicado member had not realized that the other two team members had been communicating as much as they had without him, a fact he learned only after viewing our diagram after the project (and the course) was over. He told us that the team began to function well towards the end of the project when they were working more “horizontally,” but by this point there was too little time to capitalize on their new-found coordination. For this team even more than for the local team, a glance at a diagram like this one early on in the project could have helped the members to fashion a more coordinated communication effort, possibly by switching media when it became clear that one member was not able to participate via e-mail or instant messenger.
5. ZOOMING IN: THE VALUE OF A FINER-GRAINED VIEW OF THE WRITING PROCESS As I have argued elsewhere [9], there is really no reason why we cannot build software tools that permit writers to monitor their communication patterns as they occur during a project. The data used to construct the displays in this paper is easy to gather and, in fact, is already available in many structured authoring environments. Converting the data to displays sortable by factors such as coordination, progress (perhaps as measured by task work events?), and others would be a relatively simple matter of building a database to store information about each communication event associated with a given team, and then transforming these records to iconic displays. This could be done with various levels of input from team members, depending on the kinds of feedback the team might be looking for and other factors such as time constraints.
Figure 2. Distance team event diagram
The result, I believe, would be a new class of groupware tools that focused not only on producing deliverables, but also on producing and re-producing effective patterns of team communication. The value of such tools for teams like the two whose work is represented here might be relatively minor over the short term, unless of course they are students who might use these displays to more readily do the kind of reflection on team practice that handson projects are meant to encourage. Already the team members in our study have resolved to try to “work horizontally” the next time they are faced with a group project at school or at work.
These displays could be even more valuable, though, for workplace teams with life spans longer than a single project. If, in future studies across multiple teams certain patterns of communication can be coordinated with other metrics for team success such as the quality of deliverables, team member satisfaction, etc., these displays might become powerful tools for evaluating a team’s work process during a project. Veteran teams might use displays like the ones presented here to catch potential problems before they threaten to undermine a team’s work. This study represents only an initial step toward such tools. We have not addressed many of the most important questions that came to light as we started to “see” the teams working through their diagrams. More qualitative research with larger sample sizes that include teams in a variety of institutional settings should be conducted in order to turn conjecture into knowledge. There are also opportunities to do more controlled studies using the communication maps to determine if teams could use them to make changes which would influence the overall quality of a project. The diary study approach used here yielded valuable information, but it also presented several problems that must be addressed in any subsequent study. First among these is the method of recording communication events in the diary. Ours was an almost strictly “manual” approach, with participants responsible for recording each event for the designated diary period. This proved to be tedious for participants, even though we tried to keep the entry format as simple as possible. As a result, we did not get complete diaries from every participant. We were able to construct reasonably complete records by comparing entries from each team member, but some members’ records were clearly more complete than others. Our participants tended to use their e-mail clients and personal information management software to keep track of communication events. This suggests that we may be able to write or adapt a simple PIM for the purposes of data-gathering that would make record keeping easier.
Still, I hope that the value of this modest study is obvious: it illustrates an argument that we need to “zoom in” on conceptions of the writing process, examining real-life instances of the process in action in order to gain insight about how we might better understand and support it. Using the communication event diagrams as a baseline to see a writing project, we can also imagine zooming in yet further to look at the patterns in the content of individual events or, alternatively, zooming out of a given event diagram to view the larger process model of which it forms a part. I should mention, in closing, that the view of team communication practices the diagrams above afford is one that could easily be used (and abused) to construct or extend a panoptic work environment. This fact is not news to those would use communication monitoring systems in these ways, however. Workflow software in content management systems is already routinely used to monitor and limit interactions, systematically shifting control to supervisors and administrative users of such systems. What is missing from these systems, often, is the ability for non-administrative users to view and manipulate workflow, even when users are knowledge workers with relatively high levels of autonomy over the ends and means of their work. There is very little heuristic emphasis in workflow systems as a whole, in fact, despite the potential that exists to allow users to visualize and learn from their own practice.
6. ACKNOWLEDGEMENTS Thanks to Professor Cheryl Geisler for permission to solicit participants from her course and special thanks, as well, to Kellie Carter for her assistance with recruiting and data-gathering for the project. Thanks to my co-investigators, graduate students Kofi Amponsah and Shaun Slattery for their hard work. Finally, thank you to the anonymous reviewers for your helpful comments.
7. REFERENCES [1] Barker, T.T. (1998). Writing software documentation: A
A second problem with the diary study is the limited amount of data available as compared to richer qualitative methods such as participant-observation. We were able to triangulate and add to the rather lean data stream afforded by the diaries by conducting interviews and collecting texts for each communication event that took place in writing. While this paper does not report any analysis of the texts, two other papers included in these Proceedings do (see Amponsah [10] and Slattery [11]). Using a diary study approach is definitely a trade-off, shifting most of the responsibility for gathering data and some responsibility for interpreting what should be gathered at all (e.g. what events should be recorded) to the participants themselves. The result is a method that could scale to larger N studies a bit more easily than participant observation-based methods could, but the drawback is that we must rely on retrospective accounts, by and large, from both users and researchers when making sense of the data we collect.
task-oriented approach. New York: Allyn & Bacon.
[2] Whittaker S J, Frohlich D M & Daly-Jones (1994) Informal workplace communication: What is it like and how might we support it? Proceedings of CHI '94: 131-137. New York: ACM SIGCHI.
[3] Isaacs, E., Walendowski, A., Whitaker, S., Schiano, D.J., & Kamm, C. (2002). IM everywhere: the character, functions, and styles of instant messaging in the workplace. Proceedings of the 2002 ACM conference on Computersupported cooperative work. 11-20. New York: ACM.
[4] Killingsworth, J.M. & Jones, B.G. (1989). Divison of labor or integrated teams: A crux in the management of technical communication? Technical Communication (Third Quarter), 210-221.
[5] Neuwirth, C.M., Kaufer, D.S., Chandhok, R., & Morris, P. (1990). Issues in the design of computer support for coauthoring and commenting. Proceedings of the 1990 ACM
conference on Computer-supported cooperative work. 183195. New York: ACM.
[6] Neuwirth, C.M., Chandhok, R., Kaufer, D.S.,Paul Erion, P., Morris, J., & Miller, D. (1992). Flexible Diff-ing in a collaborative writing system. Proceedings of the 1992 ACM conference on Computer-supported cooperative work. 147154. New York: ACM.
[7] Neuwirth,C.M., Chandhok, R., Charney, D., Wojahn, P. & Kim, L. Distributed collaborative writing: A comparison of spoken and written modalities for reviewing and revising documents, Proceedings of CHI '94 (Boston, April 24-28, 1994) ACM Press, pp 51-57.
[8] Gunnarson, B.L. The writing process from a sociolinguistic viewpoint.Written Communication 14.2 (April): 139-188.
[9] Hart-Davidson, W. Turning reflections into technology: Leveraging theory and research in the design of communication software. Proceedings of the International
Professional Communication Conference. Portland, OR: IEEE. 455-467.
[10] Amponsah, K. Patterns of communication and the implications for learning among two distributed-education student teams. Proceedings of the 2003 ACM conference on computer documentation. New York: ACM
[11] Slattery, S. Research methods for revealing patterns of mediation. Proceedings of the 2003 ACM conference on computer documentation. New York: ACM.
