17 Dec E-Mail Collaboration Problems
Collaborative software tools offer many ways to share information. But most of us rely on good ol’ e-mail. Now there may be a halfway point.
We all use portals of various types. News portals, company portals, even customer service chat portals. Some of us use project management, databases, contact management, document management — all these are now available not only as stand alone applications but fee-based Web based applications that are available 24/7.
The problem is that despite all these powerful resources, we communicate the most important details of our businesses via e-mail. We schedule meetings, provide project updates, answer customer requests, and usually we maintain duplicate contact records — all in e-mail.
No wonder so many portals are nothing but empty shells.
The e-mail client has become a personal knowledge management tool — something it was never designed to do. E-mail really is proof that you can hammer in a nail with a screwdriver. Despite the arrival of some truly amazing tech tools in recent years, e-mail remains the most pervasively deployed and used application.
While we dwell in an environment of ever more precise and well-managed technology tools, e-mail remains the original blunt instrument — for collaborating with remote project team members, checking soccer schedules, ordering the shrubbery, getting updates on the supply chain.
Desktop applications, like Enfish, or Web-based applications like SharePoint or phpGroupWare. are used for uniting dispersed teams and for making sense of the huge volumes of information we create and consume everyday.
A little problem
You need to alter your work and computing habits to use these tools. You need to repeatedly visit the project site (or sites) throughout the day, be sure to upload your documents to the project space so that everyone stays on the same page, and don’t forget to “cc” the team workspace on that e-mail thread so that we capture the dialog for all members. They still rely on e-mail for the basic interaction.
We have folders in our e-mail software, non-e-mail desktop folders, and when you add these group collaboration software products you now have one or more project spaces with their own furnishings and quirks to check regularly. This creates too much work and extra software training and expertise.
E-mail has become the “genie-in-the-bottle.” No matter what programs, databases or websites you use —e-mail is the home base to store messages with no context that you parse and organize manually; a home base that maintains the reassurance of local files with the real-time, tap-them-anywhere power of collaboration Web portals; a way to “interact globally” and “protect locally.” The novelty of e-mail has long since passed. SPAM fills our in boxes. We find continuity and staying organized at “high velocity” is much more important. Life as a spinning wheel; e-mail the axle.
But just maybe there is an answer out there….
Our experiences using groupware and project management tools evolved around three goals: 1) compress project time by enabling parallel activities to stay in sync; 2) bridge the geographically dispersed team; 3) maintain project focus by keeping everyone’s eyes on the same ball.
Most of the available collaboration tools would do a fine job meeting these goals, but none offered the ease of implementation and adoption we hoped for.
We recently discovered a tool aimed at that intersection point where project collaboration meets e-mail habits. It’s not sliced bread, but it is fairly close. It is named Kubi and it doesn’t function as yet another distant Web island that you visit or a local application that you run. It functions as a plug-in to a space where we live our entire day — Outlook and Lotus Notes mail clients.
Our biggest challenge was creating order from e-mail chaos in fairly complex projects — the essential implementation where decisions are made, changes are documented, and how the pieces dovetail together. That process used to be a nightmare of round robin and reply-all e-mails with multiple attachments. Now they are uploaded into a Kubi Space where decisions are made and the rejected alternatives archived off.
Kubi works like this: Users see a set of buttons that give access to what is essentially a set of project spaces with the customary e-mail, calendar, to-do list and discussion spaces in each space. From that dashboard, a user can create any number of Kubi Spaces to invite other people to join (provided they have the Kubi plug-in); when they accept the invitation, the same Kubi Space is created in their mail client.
As people interact with the project space, creating e-mails, contributing to discussions, sharing files, etc., Kubi uses the mail client’s SMTP mail transport to keep all the Kubi Spaces in sync by e-mailing the changes to other participants. On the recipient’s machine, Kubi intercepts these updates, authenticates them and assigns them into the appropriate local spaces. This update process occurs in the background as users get their e-mail in their usual ways. So if you’re doing a quick check of your day or the latest incoming, you need not crawl through every Kubi Space for summary updates.
The Holy Grail?
Does Kubi represent a potentially significant step in the evolution of e-mail?
Maybe, but not for the technology. Rather, for the initial premise of accepting established user habits as the starting point. Whether you use e-mail masterfully or stupidly, Kubi accommodates you. It’s behavior alignment. Rather than start with a website that users need to incorporate into their work routines, Kubi permits people to work in a place they know and that they have their arms around, without asking them to change well-established habits.
The news here is the incremental extension of the familiar…not the shock-and-awe of the totally new.
We still believe there’s a missing piece of the ideal collaboration “personal infrastructure.
Even with Kubi collaborative functionally we still have e-mail. Organizationally, it still orders elements along a linear time line instead of enabling some other prioritization scheme. It still requires checking, although only in another e-mail folder, not some remote website, and you still have to populate it with non-e-mail elements if you want the team to have access to them. It is also uncertain whether Kubi Spaces “nest” or not. It appears that all Kubi Spaces are stand-alone things that need to be traversed individually, not linked in any meaningful way.
We are still waiting for well-behaved e-mail with collaboration benefits, that do not requite manual intervention. We desire a program that will not make us commit to beefing up our back office servers? Is there a better solution. Maybe. If you know of one please let us know!
Ben Bradley is the founder of Growingco.com (see the Darwin article) and Benbradley.net. He can be reached at firstname.lastname@example.org. Robert Hamilton currently is a partner in Dialogues Research Services, a research-consulting firm. You can reach him at email@example.com.
The opinions expressed herein or statements made in the above column are solely those of the author, & do not necessarily reflect the views of the The Wisconsin Technology Network, LLC. (WTN). WTN, LLC accepts no legal liability or responsibility for any claims made or opinions expressed herein.