I am such a fan of minimizing reliance on email. A one-to-one communication strategy is simply not as effective as a many-to-many tool. It's not just businesses resisting the change, though. Even my project groups at UT comprised soley of NetGeners find it difficult to stop pounding out emails with attachments and cc-ing everyone. My suggestion of using Google groups as a way to write documents for an assignment together (without those pesky meetings on campus) was revolutionary! I kid, but you would have thought I'd invented a time machine the way everyone stared at me like I was crazy. Thanks for advocating more collaborative and effective methods of communication. The more momentum that builds, the easier it will be to convince people to cross over!
Daniel J. Pritchett
· 1 year ago
I find that I spend a lot more time lately thinking of ways to enable my work groups to collaborate more efficiently. The hard part continues to be finding the courage (and the right time) to call them to action.
Maybe next time you could try a Facebook group for your project rather than a Google group? Those would probably be comfortably familiar to your teammates.
Thanks for the links, John! I've seen a lot of posts this year about the "abandon email entirely" movement. I'm not quite sure we need to go that far but it's doing a good job of making us think. I find myself using it far too often for the wrong purposes - probably because GMail is so fast and lets me search my archives so well.
Louis Simoneau
· 11 months ago
Yep, the ideal is to design a web-based system that conforms to the company's workflow and fires off e-mails to the appropriate parties when it's updated. That way you get the immediacy and targeted nature of email with all the benefits of a persistent online system.
Daniel J. Pritchett
· 11 months ago
I know there are some hot startups working on enterprise productivity suites like this, but I imagine what we'll see in the corporate world is cut-down versions of this functionality being ported in to Outlook and Notes. Have you gotten your hands on anything like this in the corporate sector?
Louis Simoneau
· 11 months ago
If by 'gotten your hands on' you mean 'designed and implemented' then yeah ;-) Web development frameworks are so flexible and adaptable these days that it's pretty easy to write use cases based on a company's specific workflow and implement a software solution that essentially replicates the email (or physical) communication structure in a persistent form.
While I respect the idea of making 'productivity suites' and such for corporate use, my opinion is that if you combine the total time it takes for everyone involved to learn how to use that kind of implementation, the cost will be higher than the design and development cost of a highly customized tool modeled to the specific needs of the organization (which avoids training costs by mimicking the pre-existing workflow).
Daniel J. Pritchett
· 11 months ago
So you're capturing emails at the server and piping them out into a web archive? I am not really saying that everyone ought to go and scrap their entire IT system and replace it with wikis and forums but it would certainly be nice to escape the "private by default" e-mail workflow culture we have now.
All Comments
Maybe next time you could try a Facebook group for your project rather than a Google group? Those would probably be comfortably familiar
to your teammates.
I have a post similar to this called Instead of sending an email...
http://libraryclips.blogsome.com/2007/09/08/ins...
Matt Moore has a presentation on re-purposing email
http://libraryclips.blogsome.com/2008/04/04/ema...
Here are some of my other post examining this issue:
http://libraryclips.blogsome.com/2008/05/06/re-...
http://libraryclips.blogsome.com/2008/05/09/exa...
http://libraryclips.blogsome.com/2008/05/16/whe...
While I respect the idea of making 'productivity suites' and such for corporate use, my opinion is that if you combine the total time it takes for everyone involved to learn how to use that kind of implementation, the cost will be higher than the design and development cost of a highly customized tool modeled to the specific needs of the organization (which avoids training costs by mimicking the pre-existing workflow).