Questions to Ask Before Replacing Corporate Email

April 11, 2008 Dennis D. McDonald

Email is not necessarily a good collaboration tool. This document discusses some of the questions you can ask about your organization’s current use of email and how improvements can be made. Also discussed is email’s impact on the adoption of new tools more suited to supporting workgroups and collaboration such as blogs, wikis, and groupsites for sharing information about people and projects.

Much has been written about email’s shortcomings. In April 2007’s I only use email to communicate with old people,Jeremiah Owyang discussed generational differences in the use of email. More recently, Luis Suarez has been posting results of his personal efforts to reduce his own use of email and has been pointing out email’s shortcomings as a collaboration tool. My own research with project managers documented that a major benefit of using collaborative tools such as blogs and wikis to support project management is a reduction in email and its associated inefficiencies.

Some of email’s basic problems include:

Basic email offers inefficient workflow management associated with attachments.
Email usually doesn’t enable a group of people to work simultaneously on the same task.
Email can magnify inefficiency — and clogged mailboxes — via easily proliferated and forwarded message copies.

Despite such shortcomings, email is not going to disappear overnight. Email is ingrained into the daily behavior of too many people, it allows for messaging between applications running on different platforms, and it is adaptable across a very wide range of devices and systems. It’s also a reliable way for one person to communicate with another when other communication channels are not available or appropriate.

The following are some questions about email that will help you understand how to best take advantage of existing email as well as available collaboration and group-oriented software applications:

How are people using email now?
What groups, inside and outside the organization, are using email?
What processes and systems are currently email-enabled?
What would be involved in moving people, processes, and systems to more collaborative work environments?
What types of costs are involved in moving away from email?

1. How are people using email now?

This question has both both quantitative and qualitative answers.

Quantitative analysis can be very simple or very complex. It can range from an analysis of internal email logs to measure physical traffic patterns, to more sophisticated analysis to assess word patterns algorithmically to estimate sender and receiver “expertise” categories.

Whatever the sophistication of this analysis, you need an idea of how people are using email, volume wise, in the different parts of the organization.

One issue is the frequency with which people use email systems other than those managed by the organization. Externally managed email systems may account for a significant portion of work related email. To get this data you may need to go directly to users to track individual usage.

If you are considering the introduction of an internally or externally hosted collaboration tool, you will also need an understanding of the types of work related usage being made of email. Here are some relevant questions:

What kinds of messages are being generated and received?
How often are attachments used?
In what kinds of situations do people use email (sitting at a computer, from different computers throughout the day, via a mobile device or other interface, once per day, as they arrive, etc.)
How does email use compare with other channels (e.g., face to face, conference call, phone, instant messaging, etc.) for specific types of situations?
To what extent do email usage patterns mirror the organizational or department structure of the company?
Are there any formal or informal restrictions over addressee or message content?

This part of the analysis can take ranges of sophistication or complexity, depending on how much detail is desired.

In my opinion, there is no substitute for sitting down individually with a range of selected email users and walking through with each a sample of their own email, checklist in hand, to gain a profile of individual users’ usage, reasons for usage, and the relationships of that usage to the overall success — or failure — of the task or function being supported. Special attention should be paid to having those interviewed describe the different groups that are involved in emailing (see next section).

2. What groups, inside and outside the organization, are using email?

A basic definition of “collaboration” is “a group of people working together to solve a common problem.” There are many types of groups — formal, informal, temporary, permanent, composed of people who know and work with each each other, composed of people with little in common, groups composed of people within and outside the organization, etc.

Email initially is very flexible in how it engages with groups. One value of email is its ability to distribute information very rapidly to a single person, to a permanent group (e.g., via a stored address list), or to a temporary or ad hoc group (via an address list constructed on the fly). Once a message is initiated, however, message content and task cohesion can break down due to delays in opening email, difficulty in opening or acting on attachments, or delays in responding.

In many cases, the larger or more complex a group is, the more opportunities arise for email-linked communication failures and delays. While communicating rapidly with a big group can be a plus, the negative impacts of proliferating individual emails on accomplishing work though collaboration include the difficulty of synchronizing message and attachment content. This is especially true when the nature of the work task and associated messages change rapidly over time.

The basic purpose of this “group” portion of the analysis is to to understand the number, size, and types of the different “communities” that email supports. These same “communities” may be the starting points for technology-enabled collaboration services.

My recommendation is to interview the different users not only about their use of email but also about their involvement in different groups or communities that are inside or outside the organization, independent of their use of email with these different groups.

The most direct way to pursue this would be to start with a description of the individual’s work activities. From there, identify the groups inside or outside the organization that touch on those activities. Then, characterize each group with a short list of standardized descriptors (e.g., name of group, duration, location, size, methods of communication, etc.), and obtain a description of the methods of communication that are used so that the current “context” of email in a group setting is well understood.

Note that I am not calling for an “inventory” or “census” of groups, which would be fruitless and wasteful given constant changes in the organization. What’s more important is understanding the variety of the work and communications associated with the different types of groups, and how email and collaboration tools fit in.

3. What processes and systems are currently email-enabled?

Even if you wanted to, you couldn’t just yank email out of an organization and replace it with something else. Some software systems are “email enabled” in that emails are automatically generated as a byproduct of a process or system that responds to a specific rule or condition. Some business processes, also, incorporate embedded email as an officially designated way to communicate or document work.

Examples abound in the social networking world. Members of networks as diverse as Facebook, Twitter, and Linkedin regularly receive emails notifying them that an event has occurred in the source system. The same is true of behind-the-firewall systems, where events can trigger the sending of emails (or text messages) to system managers. Examples include workflow management or project management systems where task completion or lateness are signalled to task managers via auto-generated messages.

Another example of a potential change is that some collaboration tools support the generation of RSS feeds that allow users to subscribe to a particular set of messages or event reports. Assuming that the automatic generation of emails can be partially replaced through RSS feeds, you may need to train individuals to voluntarily check a web page, web site, blog, or wiki for an update to an RSS feed; the feasibility of making this type of change may need to be carefully considered.

The bottom line is that there may be many email enabled processes that do not lend themselves to a more collaborative approach. These should be identified, just as those processes that do lend themselves to a more collaborative approach should be identified in order to gain some understanding of potential opportunities or costs.

4. What would be involved in moving people, processes, and systems to more collaborative work environments?

As noted above, you can’t simply “yank” email out of an organization, especially when it’s an important tool for engaging with external individuals and groups. Plus, you may identify certain individuals, groups, and processes within the organization that do not lend themselves to more collaborative approaches. Some individuals, for example, may prefer to continue with receiving and individually editing Word and PowerPoint attachments even if co-workers move to a more collaborative blog, wiki, or collaborative worksite.

Whether you subscribe to a “top down,” a “bottom up,” or an aggressively “viral” process for introducing more collaborative tools in support of processes traditionally supported by email, you need a plan. The plan might incorporate points such as the following:

Introduce new tools to multiple groups. As people learn to use new tools as opposed to relying 100% on email, it will help the overall adoption process when it is seen that the new tools work in a variety of different situations.
Focus on serious problem areas, not just “safe zones.” Focusing on serious problem areas will help convince the organization that you are, well, serious.
Leadership must come from business, not just from IT. Even if you are introducing a new software application, be aware that the majority of effort will be business process-, not software-related. Don’t sell this as a technology initiative, sell it as a business process initiate designed to help people do their work better.
Take time to build confidence. Don’t be in a hurry. Publish progress data but don’t set “benchmarks” that may have little to do with the unique nature of your organization.
Incorporate with existing metrics, project justification, and process management methods (e.g., innovation management). Make sure that people understand that the new tools support the business of the organization.
Pay attention to need to transition from existing tools. Since you may never be able to move 100% away from standard email, assume that you will need to maintain dual technology, systems, and processes associated with email. (Yes, that may mean that you may not be able to do away immediately with using email based listservs to communicate with certain groups!)
Don’t let ease of technology deployment disguise the need to modify processes. And don’t let collaboration system vendor claims about ease of setup and configuration create over-confidence. For example, it may be easy to suck off email addresses from an existing listserv or department, but don’t expect people to change their behavior overnight after they get added to the new collaborations system.

5. What types of costs are involved in moving away from email?

In an earlier series of posts I discussed cost-related issues related to “enterprise 2.0” system adoption:

For me a bottom line issue is understanding the costs of introducing new technology and replacing old technology, given that the old technology — email — is not going to disappear (nor should it).

This means that multiple platforms will need to be retained, and new rules and procedures will need to evolve, or be adopted, for situations where there is functionality overlap between email and collaboration tools. So it’s inevitable that extra costs will be incurred. How long these extra costs will need to be incurred will depend upon the organization and the speed of adoption, and complete adoption won’t occur overnight.

These additional costs need to be weighed against the savings of time that emerge when it is found that efficient use of collaboration software actually reduces not only the number of (inefficient) emails associated with certain types of activities but also the meetings associated with certain types of tasks.

We all know how inefficient some meetings are and that overall productivity suffers when “key players” are absent and decisions and actions lead to delays — and more meetings. Efficient use of collaboration technology can reduce such inefficiencies, but again, these changes will not occur overnight.

Finally, an area that is difficult to cost out is the impact of improvements on expertise sharing and innovation that arise from better collaboration.

When people find it easier to work together, they can work faster and can generate better, more innovative ideas. Such beneficial behaviors are not restricted to “knowledge workers” or “white collar workers” exclusively but can have impacts throughout the organization.