There are problems with email as a collaboration tool.
The worst is email
overload. A lot of email takes a lot of management. Triaging and
curating email are especially difficult when the email lacks metadata
that enables it to be assessed without opening the email. Even the
email management approaches take effort, and still result in an
email archive of zero value to a group. For many of us, the email
management problem is exacerbated by the need to limit mailbox size.
The worst contributor to mailbox bloat is file attachments, but even
without that, email is a poor tool for storing and finding documents.
People in organisations want to hold conversations, and collaborate on documents. Work is often done in persistent groups like teams, communities of practice, and customer engagement forums. Most people collaborate in multiple groups concurrently, often spanning multiple organisations.
Common tasks include keeping track of conversations, closely following conversations, and contributing to conversations. We want to participate at our preferred time and place, using our preferred operating system and applications. Finally, we want secure, searchable archives so we can access old conversations, and so that organisations can manage knowledge retention, records and accountability.
Email supports ad hoc collaboration using “reply-to-all”, but this creates disorganised conversations that can only address one topic at a time. Reluctance to increase email load causes reply-to-all conversations to decay quickly, leaving records that are difficult to retrieve. For persistent group email, everyone in the group must maintain their own list of email addresses, and watch for changes to the “cc” list.
In a persistent group, the overhead of managing email is multiplied by the number of members in the group, but still does not result in an authoritative archive of the group’s activity.
Email’s very strength is that it privileges the user over the group. It is inherently distributed. The penalty for this is that email provides no entity, and no repository, for a group. While email is a fantastic tool for one-to-one and one-to-many communication, it sucks for many-to-many communication.
Salvation in Web Collaboration Tools
Promises of salvation from the evils of email abound. All that’s required is migration away from email to a web-based collaboration platform. We are told that wiki collaboration leads to happiness, and that Enterprise 2.0 is about building a collaboration platform that is better than e-mail. Not only is an array of web-based alternatives to email available, but there are phalanxes of implementation experts ready to wrench users away from the most successful software ever invented.
You Can’t Beat Email
Email is the most successful message and file-sharing tool that has ever existed. Consider the criteria for the ideal collaboration client.
High Functionality. Supports asynchronous conversations, and file-sharing, archiving, can be searched using metadata or full-text retrieval. Email: check! Sure, use of email for collaboration is problematic, but it does actually do the job, and most people manage around its deficiencies.
Low Cost, for licence fees and hardware requirements. Email: check! It’s already running on almost every computer there is, and it’s available for free on the web.
High Usability. Email: check! Almost every computer user already knows how to use it, and uses it more than any other tool. The switching cost is zero.
High Interoperability. Email: check! All flavours talk to all flavours (if only browsers had the compatibility that email clients do!), and email is blind to organisational boundaries.
What other collaboration client that meets those criteria so well? Email is tantalisingly close to the ideal collaboration client. Why are we throwing it out?
Throwing the Baby Out with the Bathwater
Once the licence fees, hardware requirements and deployment of the new collaboration platform are taken care of, people will have to stop what they’re doing now, and learn to use a new system for collaboration.
Each user faces the cost of abandoning the system they know, and climbing the learning curve to the new system, amidst the pressure of daily priorities. If any user baulks at this cost, you have n-1 uptake of your new system. Unless that one person is superfluous to the team, the other team members must accommodate them by duplicating communications in the new medium, and email, or reverting to just using email.
Even with 100% internal adoption, the system may not work well across organisational boundaries. Even if it does, you now to get users outside the organisation to use your new system. Hopefully, they are not being marshalled into a different collaboration platform at the same time.
In their zeal, the crusaders for change scoff at these barriers, and declare that the benefits offered by the new system makes it worth taking the pain. Not only that, but they decide that, along with the migration, there will be a purge of old bad habits that have crept across the organisation. Everyone will now start thinking about the greater good, and apply metadata to their documents and communications.
In a final blow, because the new collaboration system is web-based, it is inherently a pull medium, not a push one. It therefore uses email to notify participants of new activity. Your users can keep using email to follow conversations if they want to, but they have to leave email for the new system to contribute.
It’s Not All About Implementation
What if the cost of teaching people to use the new system was invested in teaching people to use email better?
The problems with email can be mitigated to a large extent, by adopting improved practices. Writing good subject lines is a great place to start. Using search, rather than folders, to organise email works for many people, and if you do use folders, message rules make a big difference. But improved practices alone will not overcome the limitations of email for collaborating in persistent groups.
What is required is some kind of technology that allows people to keep using email, more or less as they do now, but makes it easier to use email to collaborate in groups.
There is a Technological Solution
A system that supports group collaboration using email should allow users to contribute as well as access messages and files using email. It should also provide some shared repository that can be accessed over the web, regardless of location. The shared repository should archive all communications and be searchable, but it should also support day to day participation in conversations, and document-sharing. Ideally, the tool should provide equivalent functionality via both the its web and email interfaces.
Technology that provides this functionality is easily found: email groups. The best-known examples are Yahoo! Groups and Google Groups, and of course there is our own service at OnlineGroups.Net.
Email Groups Make Email a Collaboration Client
Email groups are a simple but flexible technology that supports semi-structured group communication, accessible via both email and the web.
The group has a name, an email address and an address on the web. Any group member can email the group, and the group sends that email out to all group members. All posts and files are accessible in a central repository on the web, where users can also add posts and files. Groups have persistent membership and discoverable privacy settings and joining criteria. Group members maintain their own email addresses and delivery settings.
Email groups overcome the primary weakness of email, by providing an entity, and an interactive repository for a group.
Email Groups Overcome the Problems with Email
Firstly, even if users do not write better subject lines, the message headers inherently contain more metadata. The group address and, if set, subject line prefix, instantly signal the context of the message, including the participants and purpose. Even if the subject line is broken, the sender, and senders of other messages with the same subject line provide further data about who is doing what in the group. If messages are not filtered, often they can be deleted or marked as read, without needing to be read, as a full transcript of the conversation is available on the web. This makes is easy to triage email, to keep track of conversations, to schedule detailed attention to conversations. Topic digests, and web feeds provide further ways to support these tasks.
The aggregation of group-related posts in a web archive supports the task of closely following conversations, and contributing to conversations. Posts are organised into separate threads or topics, and sorted by date, making it easy to follow one or more concurrent topics of conversation, whilst ignoring the others.
Files are stored in the central repository, associated with the messages that relate to them. Versioning is handled by the deceptively simple process of adding successive versions to the repository. This eliminates mailbox bloat, while providing an audit trail of all document edits.
Simple improvements to practices can increase these benefits considerably. Writing good subject lines means that even more emails can be triaged from the inbox. The text of previous messages is already in the archive, so it can be removed, increasing the signal-to-noise ratio.
With good subject lines, keeping track of who is discussing what is even easier. In the following example (from the OnlineGroups.Net Administrators group), it can be seen that Dan and Annelies are discussing Chat, and that Michael has responded to Kirsty about Adding Members.
Email Groups for Organisations
At OnlineGroups.Net, we used to use Yahoo! Groups extensively to facilitate collaboration for our clients. These were successful because of their killer feature of working as well via email and the web. Our clients, however, began to demand greater control over the context of their email groups. They wanted their branding, not that of Yahoo!, around their email groups, and they definitely didn’t want ads from arbitrary third parties. They wanted their groups at their own domain. They wanted more control over the administration and privacy of their email and document archives. They wanted their groups grouped in a single context, rather than appearing alongside unrelated groups. And they wanted to be able to associate web content with their groups.
GroupServer and OnlineGroups.Net
To meet these demands, in 2004, we built GroupServer, an open source collaboration server, providing email groups, in a web content and application framework. GroupServer has been in production since then, underpinning sites used by clients like Advanced Business Education Ltd, and E-Democracy.Org. GroupServer version 1.0? is available for free download at GroupServer.Org.
Because GroupServer sites can distribute millions of emails a day, they are not trivial to administer. OnlineGroups.Net therefore provides access to GroupServer sites and groups via its software service at http://onlinegroups.net.