Purpose

E-mails are generally informal internal documents for sharing information. They create a document record and provide a history of information transactions, but do so without the formality of a memorandum (see later section). Although considered informal, e-mail transactions can carry formal weight in legal proceedings and are considered part of the organization’s historical record.

Application

E-mails can be used in virtually any setting and for almost any type of information sharing or transfer. They are used whenever there is a need to share information quickly, thoroughly, and asynchronously. They are used when the record may be important to success of the communications loop, but is not necessarily of historical significance.

Content

Although the information content of e-mail is widely varied, much of the information included in the document headers is consistent. Header information includes a date, the name and e-mail of the sending party, the name(s) and e-mail(s) of the recipient(s), and the subject matter included. The informational content within the e-mail may be short or long form. It may be of a formal or informal nature, but should always be treated as if it might be maintained as part of the permanent record.

Approaches

In crafting e-mail, there are a number of potential approaches. Project managers in some organizations will dictate the “Subject” information format to include only specific data elements, such as work package number, project name/code, and/or nature of the e-mail (e.g., approval request, informational, customer data, form attached). By generating specific rules for what information may be included in the subject heading, e-mail sorting and filtering can be done more quickly.

Sample E-Mail Protocol

For all project e-mail, the subject line shall read as follows:

(Work Package Number)—(Name)—(Nature)

•  Work package numbers may be derived from the WBS, stored on the LAN at w:/project/projectfile.mpp.

•  Name shall be the name of the work package involved (e.g., Foundation Excavation) •  Nature shall be one of the three following categories:

Approval request

Informational Data (attached)

If an e-mail is not directly related to a specific work package, the header shall read as follows:

(Project Name)—Project Support—(Nature)

No e-mail shall include a “trail” of more than four past e-mail transactions without a summary of those transactions in the first paragraph of the e-mail.

As for the content of the e-mail itself, some basic protocols should be followed. Use of all capital letters for any word or series of words is generally perceived as shouting. Such usage should be minimized. Also, the word you is frequently seen as accusatory in e-mail transactions. Although it cannot be eliminated, its use should be very carefully considered. And because e-mails are transacted quickly and can be broadcast to a significant number of project parties, the recipient’s list should be limited to those directly impacted by the e-mail’s information.

Considerations

The immediacy of e-mail is both bane and blessing. It is helpful in the project environment because of the frequent need for immediate information transfer. It can be deleterious because it sometimes encourages a “heated” response without time to consider the long-term implications of such a response. Few e-mails are so critical that a 5-minute cooling-off period cannot be applied. In environments where sensitivities are high or where e-mail has generated concerns in the past, such a waiting period may be well advised.