DIGITAL VISION

Narrative in project-related e-mails

KIM TRACY

-mail has become one of the primary communication methods for members of a project team to communicate and to make progress on a project. Even though e-mail has become so critical to project communications and coordination, it is still inherently unstructured. As a result, the effective use of e-mail by a project team can help, hurt, or just distract a project team from making progress on the project. This article looks at e-mail to see if there are narrative structures that come out of a project teams use of e-mail and whether that structure can be used to stem poor project behavior and to encourage good project behavior. This project does not consider the use of narrative to describe a project (such as books written about a project), the generation of narrative in meetings, or generating a narrative based on project-related e-mail. The problem is defined more succinctly as: How can narrative structures in e-mail be used to better guide a project?

Successfully solving this problem should help project members and managers spot useful narrative patterns that they can respond to and thereby help the project. Without solving this problem, these patterns may be missed and the opportunity to correct or leverage the pattern would be missed. The greater hope is that the study of project-related e-mail patterns could result in more effective use of this already pervasive communication mechanism to have more predictable and useful effects on a project.

Patterned approach
In starting this project, it was not clear that there are any interesting narrative structures in e-mail that would affect the project team. So, one of the first tasks was to determine if there were interesting patterns that one could consider narrative in nature. If there were, then I could look at them for interesting patterns. I could not find any prior work that was specifically concerned with the use of narrative in
0278-6648/09/$25.00 2009 IEEE

Digital Object Identifier 10.1109/MPOT.2008.931501

e-mail. There is some work done on patterns of communication in project teams that is interesting, but is not narrative related. (See examples such as Cain, et al., December, 1996.) Fortunately, I have access to a large number of project-related e-mails from participating on many technologyrelated projects for my organization. The number of these project-related e-mails range from 200 to 400 in any given work day. The approach taken is to mine this set of e-mails to look for interesting, narrative patterns. The danger in doing so is that these patterns may be atypical and peculiar to the source organization. After analyzing the e-mails for evidence of narrative, I looked for interesting patterns that may have value for affecting the course of the project. After identifying those, I had the opportunity to actually practice looking for these patterns and consciously use e-mail replies to better the course of the project and form some simple recommendations on patterns to look for and actions to take.
IEEE POTENTIALS

14

Authorized licensed use limited to: Manuel Giovannetti. Downloaded on August 25, 2009 at 12:34 from IEEE Xplore. Restrictions apply.

It is important to note a few details about the methodology used for this study. The study focused on an enterprise resource planner (ERP) deployment for a university that is in its third year. This project included the efforts of about 300 people with approximately 70 of them being in the IT organization. There were about 10,000 such e-mails used for this study that encompassed about one year of that project. My collection of e-mails was from the perspective as the leader of the IT organization (so, I did not get every e-mail affecting the project). The results of this project are not meant to be scientific but to present a typical projects e-mail experiences and give a few guidelines that are often not followed, even though they may seem obvious.

HI just wanted to let you know that so far, I have found four or five e-mails sent to me yesterday 2/13/08 that I have not gotten. some of which were very important. Is there any way to know what else I am missing? I am concerned about how to effectively work with this problem. Fig. 1 Example e-mail #1.

1.1 Background
A key insight has been that much of the communication that these project teams generate is not narrative but merely responding to a previous communication that was sent with a short answer or response. However, a string (or here, thread ) of such communication will often take shape as a narrative form where it has a context, characters, and structural elements such as an introduction and conclusion. Inherent in much of these threads is an underlying context for the communication. In addition to the technical context, many of these narrative threads will also have social context that affect the meaning of the narrative, particularly to individuals. Consider the context for the snippet of an e-mail in Fig. 1, which is part of a larger e-mail thread. This e-mail was sent in the context of many e-mail issues and relies on the larger context that this person has already experienced e-mail issues. Furthermore, this is a department chair who has also reported similar problems from his/her staff. The last statement in their e-mail shows a growing concern for the problem and the risk of escalation as this problem does not get better. Knowing the context that they are an important department chairperson also increases the importance of getting the issue resolved. The rest of the thread shows a continuing escalation of the problem but does not show the larger organization context that also plays a role. In this case, the e-mail caused me to escalate the problem and to get better status.
MARCH/APRIL 2009

Ricouer (Ricoeur, 2004) was helpful in determining the effect of memory and selective forgetting on these types of project-related exchanges. In particular, some of these messages will attempt to forge a narrative that reflects the authors perception, rather than being factual. A simple example of this is in Fig. 2. In this case, the context was that this mail was sent just after the salesperson was told by me that he was not going to get the sale of the product they were hawking. So, he sent me the email in Fig. 2. The issue was (as with many salespeople) that their facts and questions were targeted to try to get us to reconsider our choice. It turns out all of the questions were not issues. The larger effect of this e-mail (if the sender understood the context) is that I no longer trust them to provide accurate assessments of what they

are trying to sell and will make every attempt to avoid interactions with this sales vehicle. It should be noted that they have been overselling this product for about a year and with each attempt, it becomes less credible. So, for the prior example, the selective forgetting (you didnt really decide yet, did you?) and the additional plea to do a demo (we had already done two full-blown ones) were damaging to the relationship of the vendor to the customer. A more interesting analysis will be to look at the effects of a longer thread of project-related e-mails and see how the narrative can enhance the project to help in accomplishing a task or furthering teamwork and camaraderie. These small examples show how simple e-mails can provide a stimulus to get something done (Fig. 1) and how they can damage an ongoing relationship (Fig. 2). It remains to be shown that a larger narrative is created by some project-team e-mail threads and that some single e-mail narratives also affect the project as narrative.

Look, categorize, determine

The approach taken to analyze project-related e-mails was to look at the entire set of project-related emails, categorize them into types, and then determine if that type was likely to have narrative patterns of interest. Given e-mails inherent unstructured nature, any given e-mail may belong to multiple types.

Hi Kim. I did do some checking on the [XXX ] solution that you are investigating for scripting/job scheduling. There were a few things that came up that should be considered: Im not sure how up to date the code is and how much customization is necessary in order for this solution to work with [YYY ] either today or in the future. What is the support structure for this solution, on-going development effort, customer base, etc? Is [XXX ] selling their code or giving it away and then you customize it? From what I understand, another Washington based institution reviewed [XXX s] solution and determined that a lot of code/customization would be necessary, that institution is now an [XXX Solution] customer. I would be more than happy to schedule a demo for you, your staff and functional users to help show the functionality of [XXX Solution] for all your applications. Thank you and look forward to talking with you soon. Fig. 2 Example e-mail #2.

15

Authorized licensed use limited to: Manuel Giovannetti. Downloaded on August 25, 2009 at 12:34 from IEEE Xplore. Restrictions apply.

In addition to static types of e-mails, interactions and relationships are also important to determining when intervention might be needed. Based on the types and interactions, patterns are identified where intervention may be helpful.

esting to see as a narrative and can have conflict (i.e., Im not doing that!) and a common goal to resolve the issue. Trying to resolve an issue via an e-mail discussion usually produces a stream of interactions many of which are narrative in form. They usually have pieces that are not narrative but the

were often in narrative form and would often bring a chorus of other e-mails expressing sympathy or other complaints. (e.g. Why are you or the project such an X ?) Both the messages themselves and the thread tend to have more narrative form.

1.2 Types of e-mail

The types of e-mail chosen are to help in determining likely sources of narrative, not necessarily to provide a useful taxonomy for any other purpose. From my sample e-mails, about 60% of all project-related e-mails do not appear to be directly part of an interesting narrative thread. These include types 3.1.1 (status), 3.1.2 (procedural), 3.1.4 (calls for action), 3.1.6 (queries), and 3.1.7 (informational). That 60% does provide vital context for understanding the context of the narratives that may occur. 3.1.3 (trying to resolve an issue) makes up approximately 20% of e-mails with another 10 or 15% being of type 3.1.5 (complaints and venting). Very few e-mails are of type 3.1.8 (errors that instigate a large number of responses).

1.2.6 Queries about status or simple questions

Some e-mail will provide no value at all and are just responding to have sent a response. For example, some people will respond to a question with a nonanswer or with no substantial content. These responses can have all sorts of motivations.

Many messages are simple questions that should have simple answers. (e.g. Who is responsible for X ?) Occasionally, these will spark a larger discussion or bring on a larger issue.

1.2.7 Purely informational

A big function of project-related e-mail is just to keep the team informed. (e.g. Heres the manual for X.) So, many messages will just be sharing notes and informational items that others need to know. These are usually not narrative in form.

1.2.8 Unintended and erroneous e-mail

sequence of such e-mails can often be viewed as a narrative. As long as the issue resolution stays in the e-mail medium, it produces a story often of the form as follows. One person will identify the issue. Others will chime in and agree and/or disagree. They quickly start to elaborate on the problem. Others may contribute we did this last time or suggest how to deal with the issue. Often these will die out at that point. . . . If we are lucky someone will decide on a course of action and then action will be taken on that action, either resolving the issue or not. Often not, causing other problems to be identified and then producing a cycle of similar interchanges. With e-mail being so easy to send out, it will occasionally be sent to the wrong people by accident or have unintended typos that offend some of the recipients or embarrass the sender. These are fairly rare events, and one may only see one e-mail in 1,000 that really has an effect. When they do, it can be a trigger for a massive e-mail thread response.

1.2.1 Status e-mail

These are responses to earlier questions about status or are providing a status on a particular item. They may add to the context and could be written as a story to explain what happened in narrative form. Status can be done in a narrative style by telling a story about how they got from point a to point b. However, most of the ones Ive examined are not, they merely describe a point in time rather than a sequence of events with rationale.

1.2.9 No-op e-mail

Some e-mail will provide no value at all and are just responding to have sent a response. For example, some people will respond to a question with a nonanswer or with no substantial content. These responses can have all sorts of motivations from just showing interest to more devious motivations of trying to change the discussion or to later claim I did respond.

1.2.2 Procedural, administrative, and coordination

Procedural e-mail are responses or input to a procedural event, such as accepting a problem for resolution or getting a message with a request to accept a task. These are very unlikely to be involved in anything resembling narrative but could provide context for another narrative.

1.2.4 Calls for action

These are asking for something to be done by members of the team (e.g., Lets meet and discuss X ) and can result in an e-mail thread to try to do the task or have it be done outside of e-mail. These are usually not going to be part of a narrative (though they could be a story about why we need to do X and this is why it is useful, etc.). Most of these are targeted at events outside of e-mail.

1.3 E-mail interactions

The ways e-mail is used can also produce important effects. The dynamics of interchange are important as well as the content and type. Some of these interactions between multiple users that may require attention or intervention are as follows: Conversations. These are back and forth interactions between a set of individuals that are using e-mail threads to form a conversation. This can take the place of face-to-face or phone conversations. Mailstorms. Mailstorms are a rash of responses that are not helpful. These
IEEE POTENTIALS

1.2.3 Resolving an issue via an e-mail discussion

Usually this is a protracted stream of e-mails with many factors about issue X. These may be productive (resolving issue X or determining there is no issue) or nonproductive (never reaching a resolution). These e-mail threads are inter16

1.2.5 Complaints and venting

Surprisingly, in my sample set of e-mails a larger number than expected were complaints. These complaints

Authorized licensed use limited to: Manuel Giovannetti. Downloaded on August 25, 2009 at 12:34 from IEEE Xplore. Restrictions apply.

can more easily occur in large project teams where people begin responding to an innocuous e-mail by Take me off this list and others chime in, thereby destroying the utility of email to that group for some period of time. These can also be stimulated by simple errors (the mail was intended for one person but went to a large list by mistake). E-mail silence. E-mail silence can be deadly and equate to an issue or person being ignored. Threats and insults. Can also cause disastrous results and affect teamwork outside the e-mail realm.

Top Ten Considerations for Sending Project-Related E-mail:

1) Is e-mail the right method? Should you be using e-mail at all or is the phone or a personal conversation more appropriate? 2) Is this e-mail helpful? Should it be sent at all? 3) Does this e-mail have unintended consequences? Might this e-mail cause an e-mail storm or cause others to complain? 4) Is the e-mail understandable/well-written? Is the e-mail likely to cause confusion or a distraction? 5) Is the e-mail correct? An e-mail with an incorrect statement can cause a mail storm or your e-mail to be discounted. 6) How will my e-mail affect the project? If not in a positive way, perhaps it should not be sent. 7) Is this the right distribution list? If not, the extra people (or missing people) may react to cause unintended effects. 8) Does my e-mail just add value to the project? Or is it just re-stating what others have said? 9) Will my e-mail cause unnecessary or duplicated effort? Am I asking many people to respond to the same question or perform the same task? 10) Can I make a more positive impact on the project? Can I add something to the e-mail or change it so that I have more positive impact, such as giving someone credit for a job well done or getting others to think of improvement?

1.4 Patterns of interest and effects on project

My contention is that only those purpose driven e-mail exchanges trying to resolve an issue produce interesting narratives. Complaining sessions where lots jump in can sometimes also produce interesting dialogues. Interesting patterns are probably best expressed through the following examples: Chains of e-mail accomplishing tasks. (Type 3.1.3). These are interesting because they are actually making progress and getting work done. So, a chain where participants are chiming in and offering constructive help to resolve the task/issue should be helpful to a project. An example is such a chain instigated by a problem report (server X is down) and multiple people offering possible explanations and solutions until it is resolved. Chains of e-mail complaints or venting. (Type 3.1.5). These are interesting because they can actually have both positive and negative effects on a project team. For example, if a team member complains that no one is listening to my concern, and actually gets a response, it may help. It may also be needed to get issues out on the table so they can be resolved. It can be extremely devastating if the complaints are personal attacks or outside the sphere of control of the project team. Er roneous e-mai l. (Type 3.1.8). While these are rare, they can instigate a chain of events in e-mail. One example was a vendor that mistakenly delivered a personal attack against their customer to the person being attacked. That caused a flurry of e-mail exchanges as well, doing severe damage to the vendor-customer relationship.
MARCH/APRIL 2009

These three types seemed to have the most narrative character and resulted in situations where intervention could be helpful.

Only those purpose driven e-mail exchanges trying to resolve an issue produce interesting narratives. Complaining sessions where lots jump in can sometimes also produce interesting dialogues.

Project actions based on e-mail patterns

Following are some of the actions that managers or team members can take based on specific patterns of narrative that occur. These certainly are not the only needed actions but are some that came to light in my analysis of such exchanges as well as

were effective when the interventions were attempted. Noticing Excellence. In a chain of email that are trying to accomplish a task (Type 3.1.3) it can be very helpful to publicly acknowledge excellent work or behavior by an individual. The sooner that can be done the better. It not only recognizes the individual but reinforces similar behavior (hopefully) in others. Stalled efforts. Also in type 3.1.3, if the discussion and/or conversation stalls, it may need intervention to get restarted. This could lead to an e-mail silence in this thread (all of a sudden, theres no more discussion but the issue is not resolved) where someone needs to kick start the process again. It could also be that the discussion has completely gone off-track from the issue and is no longer productive in terms of helping the project. This requires someone in authority to intervene and get the team back to the issue (as well as probably reiterating the known status). Destructive complaining. (Type 3.1.5). Attacks on an individual can result in either an e-mail storm or silence. In
17

Authorized licensed use limited to: Manuel Giovannetti. Downloaded on August 25, 2009 at 12:34 from IEEE Xplore. Restrictions apply.

either case, the best action is to intervene right away and to try to resolve the issue, preferably outside the e-mail forum. Other complaining about issues that are not solvable by the team can also be (hopefully) squelched by someone in authority intervening. Erroneous e-mail damage. (Type 3.1.8). This also should be stemmed as soon as possible and, if possible, taken outside the e-mail forum. Too often once something started in e-mail, others respond in the same medium.

Read more about it

Attacks on an individual can result in either an e-mail storm or silence. In either case, the best action is to intervene right away and to try to resolve the issue, preferably outside the e-mail forum.
the intervention helpful, but it can keep team problems from becoming much worse. This paper details four simple interventions that a watchful individual can directly use in any real project team that makes heavy use of e-mail.

B. G. Cain, J. O. Coplien, and N. B. Harrison, Social patterns in productive software development organizations, Ann. Softw. Eng., vol. 2, no. 1, pp. 259286, Dec. 1996. P. Ricoeur, Memory, History, Forgetting. Chicago, IL: Univ. of Chicago Press, 2004.

About the author

Kim Tracy (k.w.tracy@ieee.org) is executive director of university computing services at Northeastern Illinois University and is responsible for all IT systems and resources. He is a member of the IEEE Potentials editorial board and a Senior Member of the IEEE.

Conclusion
There are patterns of use in e-mail that take narrative form and some of those patterns are useful from a project management perspective to look for and to intervene when they occur. Not only is

make a sound? tree falls in a forest w If a ith no one to hear it, does it
IEEE Potentials s is interested in hearing from students who are active in their Student Branch. Has your student branch grown in popularity? Do you organize innovative, fun, and educational activities? Are your Student Branch officers particularly adept at meeting the needs of members? How would you like to share your experiences with other IEEE Student Branches across the world? If your Student Branch has a story to tell, we would like to hear it. Simply p g for details. e-mail potentials@ieee.or potentials@ieee.org In your response, please include brief answers to the following questions: What are the goals of your Student Branch? What do you consider the Student Branchs most notable achievement and why? How does your Student Branch attract new members? How does your Student Branch keep members involved? A profile of your Student Branch could appear in an upcoming issue of IEEE Potentials. These profiles help open up lines of communication between Student Branches and inspire increased involvement and activity sharing information regarding what other branches are doing and what has and has not been successful. All Student Branches from Regions 110 are welcome to respond.

18
Authorized licensed use limited to: Manuel Giovannetti. Downloaded on August 25, 2009 at 12:34 from IEEE Xplore. Restrictions apply.

IEEE POTENTIALS