Email is a great communication tool that is widely available, frequently used, and understood by "everyone". It has some inherent problems, however, and leads to many more. This is one of a series of posts trying to unpack those problems, with an eye to designing better tools or to overcoming those problems by better practices.
Confusion in Conversation Context
Extending my earlier analysis of the confusion that arises in conversation flow when email is used as a communication tool for business project teams, is the idea that confusion also arises as to the context of the conversation. The conversations held in email related to documents in the process of being written, spreadsheets being built, images being designed, or any other type of electronic file or system are undertaken separate from and in isolation to that context. People are forced to use words to associate specific emails to specific other items (eg, "regarding the latest version of the document"), rather than being able to use a communication system that automagically associates the two.
How does this type of confusion impact business teams today?
- People Have to Hope They've Got the Right One. Because the link between an email and a specific version of a document or spreadsheet is so tenuously stated (eg, "the latest version of the document"), each person has to hope that they are looking at the correct latest version. A person either gives it their best shot and hopes for the best, or becomes a fearful bundle of worry that calls around to the others on the project team to ensure they've got the right document open in front of them. It's not always made easy.
- You've Got to Have Inside Knowledge. When a person who is not on the project team finds a document or spreadsheet that the team has worked on, all of the communications, interactions and deliberations that preceded the finalization of the document are invisible (there will be times when this is valuable, but it won't always be wanted). All that's left is the final document and the name of the lead author or authors, not the history that can add richness and meaning to the document. Only those on the project team know that such a historical view is available, albeit one that is difficult to share because it is locked in email.
- The Social Fabric of the Organization is Hidden. By separating the two, the social fabric of the organization is rendered invisible. New people can't peek back and see how the social interaction between people lead to certain decisions being made. When questions as to the meaning and import of certain parts of the documents are raised, potential answers due to the social interactions are hidden and must be searched with the weariness of an archeologist, rather than the ease of a library user. With increasing standards as to due process and governance, this is important.
Email means that people have to work harder to link conversations in email with documents and other digital artifacts than if more appropriate tools were used. A shared document workspace, for example, allows the proper contextualization of interactions about a document with the document and its various versions over time. With email it is nearly impossible.
Can Human Practices Overcome Email's Weaknesses?
As I write this, I wonder to myself whether there are specific human practices that people on project teams could follow to mitigate this weakness and eliminate much of the confusion. For example, if the file names of documents were carefully chosen to reflect the date the document was saved, plus a version number and the author's initials, would that make it suitably clear as to which was the correct "latest version"? It would involve everyone on the team playing by the rules, but maybe the return is sufficient to warrant such a thing.
A second human practice could be to list the names of all of the people involved in the project in the meta-data fields of the document or spreadsheet, so that at least those that were involved in the production of the document are noted. People reading it in the future could then choose to get in contact with one or more people if they had questions or concerns. And those names could be presence-enabled so an instant messaging chat or a phone call could be easily started.
Finally, perhaps a second and separate document could be written that spoke to the history of the main document. This would contain an export from email of all of the conversations involved in getting the document written, plus the minutes from project team meetings, the reflections of the people involved, and more.
(Mmm, that seems like a pretty weak list to me. My ideas above are going to create more manual work and effort ... I don't think we're going to overcome this problem so easily.)
What's Your Experience?
Have you got a story to share about ...
- ... where this separation caused a severe impact to the functioning or outcomes of a project you were involved with?
- ... human practices that have and have not worked on the project teams you've been involved with?, or
- ... specific communication and collaboration tools that your project teams have embraced to overcome this issue?
I'd love to hear about it ...
How about this?
A workgroup email archiving function: We can define a group by adding the emails of all the teame members. The system then records each email exchanged between any member (s) in the group, sometimes with a subject filter. For example, if A, B and C work on a project D as a team, we can define a group by adding their emails. The system records every email exchanged among A, B and C that has a subject involving project D and publishes the record to a webpage accessible by all the team members. In this way, every team member is kept in the loop. We then don't need to rely on each member to CC other members each time they send emails. We should be able to implement this function by some scripting over our current email system.
Posted by: Yue Jin | February 07, 2007 at 05:52 AM
Yue Jin, thanks for stopping by and for your thoughts above. It's definitely one way of doing it ... my hesitation is the situation where a team member forgets to put "Project D" in the subject line however. We'd need some other way of adding things there after the fact.
A commercial product that offers this sort of thing is Aftermail / Quest Archive Manager. I know I go on about it, but I think it's a really neat offering.
Take care,
M.
Posted by: Michael Sampson | February 07, 2007 at 05:31 PM