Another take on email v/s wiki

One of the biggest barriers for wiki adoption is our mindless slavery to the habit of emailing each other. No doubt , email is a great means of communication for both one-to-one and one-to-many scenarios. But, lets accept it. It was never really intended as a many-to-many collaboration tool - which is unfortunately how it often gets used in the enterprise.

I thought I will use this post to clearly illustrate the distinction between how emails and wikis would work in a typical real-world collaboration scenario. Consider the case where John, Tim, Mike and Sue are working together on a software project. John is the project manager-cum-designer, Tim is the lead developer, Mike is the UI designer and Sue is the business analyst .

In a pure email world, this is how it would work (it starts getting a bit convoluted...so please bear with me)

• Sue emails the business requirements in a Word document format to John.
• John creates the software design document and emails it to Tim and Mike. Since this goes into several iterations, they decide to keep Sue out of the loop to avoid spamming her.
• Meanwhile, Mike needs UI details from Sue since they were not covered in the original document. So they start a separate email thread exchanging screen shots pasted on Word.
• According to Sue, she had forwarded one of these emails to John to "keep him in the loop". John says he never got it. There is some friction between them because each one feels he or she is right.
  
• Due to the number of versions of screen-shots emailed back and forth, Mike loses track and accidentally uses an older version to create the UI code.
• Mike, then, goes on a two day vacation and forgets to email his UI Assumptions Word document to John before that. So John has to either wait or call him to search for the document in his dekstop.
• Tim makes some assumptions and emails to John but forgets to copy Mike since he feels it is not UI related. But there is some UI implication which he does not realize.
• Sue has some new requirements now and she decides to email this again to John. John is in a meeting all day so he gets to forward it only at the end of the day.
• In the middle of all this chaos, all of these users have a common complaint. Their mail boxes get full every week because of huge email attachments.
• When the project wraps up, John wishes all the project documents were safely archived in one place - but, alas, they are spread across in emails and Word documents.
  

It is clear that the collaboration is pretty chaotic and inefficient. Of course, the situation has been stretched a bit to illustrate the point. But you can extrapolate the chaos when we are talking about a large team and much more complex processes.

Now consider, how would this work in the wiki world (assuming an enterprise wiki like SamePage).

• John creates a project(wiki) and adds all of them as members. He creates different pages like Business Requirements, Assumptions, Design, UI Assumptions etc. Everyone in the team has access to everything.
• Sue edits the Business Requirements wiki page, importing it from her Word document. She also emails that page from the wiki to John to call his attention. Since the business requirement is the main driver, everyone in the team adds that page to their watch list so they know as soon as it changes.
• John, Tim and Mike work out the design specifics and create/update different pages. Sue is always in the loop and occasionally comments as needed.
• Mike and Sue are working separately on the UI specifics , but since they are always updating wiki pages, John and Tim are always aware. They see the latest UI changes in the "Recently Updated list" and make the relevant changes to their design.
• Since the wiki is now the "single source of truth", there is no friction between John and Sue as to who emailed whom about what.
  
• Further, since the wiki always shows only the latest version, Mike does not have any confusion. So he uses the latest version of screenshots to create the UI code.
• When Mike goes on his two day vacation, his latest assumptions are still in the wiki. John does not have to wait or hunt for it in his desktop.
• Similarly Tim also updates his assumptions in the wiki. Even though Mike misses it in the recently updated wiki pages, he notices that Tim has changed the Assumptions page in the daily digest email he gets from the wiki.
• Sue updates the Requirements page and immediately all of them get notified that the Requirement page has changed. Though John is in the meeting all day, Tim and Mike are able to atleast analyze how the new requirements will affect their design and code.
• Finally, everyone is happy that their mail boxes are not getting choked with attachments. Everything is in the wiki. They can delete email notifications sent by the Wiki as soon as they have read it, since it will always be available in the wiki.
• When the project wraps up, John knows all the project documents will remain intact in the wiki for the future.
  

In short, the situation is much more efficient and organized than it was in a pure email world.

I hope this helps you visualize how wikis are better than email as a means of collaboration in a typical real-world scenario.

This whole concept has also been captured much more succinctly in the picture below, that I have copied below from Anthony Williams's blog on the Wikinomics site and originally used by Chris Rasmussen at US National Geospatial Intelligence Agency.