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.

A few things to keep in mind when you choose your Enterprise Wiki

Here are a few factors that you need to consider in choosing your enterprise wiki product and increasing its adoption within your organization. Naturally, this list is by no means exhaustive but most of you would anyway find them useful.

Also, not all the factors below would be relevant in every wiki decision but it won't hurt to go through the list and make sure that you have not ignored some factor that may come to haunt you later.

• Strong WYSIWYG capabilities of the Wiki is essential if you want business users to embrace it. You and your tech-savvy friends may like wiki syntax but business users, in general, don’t like or care for wiki syntax.
• A single huge all-encompassing wiki like “Wikipedia” seldom work in the enterprise - concept of “spaces” or “projects” is almost always required. This also ties back to the "In-the-Flow" usage which I will cover in a later post.
  
• Granular security with ability to specify permissions even at page level is often a required criterion in enterprise wikis.
• Features like versioning, audit trail, comment moderation are very critical in the enterprise – organizations have different level of sensitivities on what can be published.
• Strong email integration is important for wikis to get adopted. E.g. ability to email a wiki page, comment via email, receive email notifications etc .Email habits die hard and you cannot expect people to switch from email to wikis overnight.
• Strong integration with Word/PDF is very important E.g. ability to save a page as PDF/Word or Import a Word file into a Wiki Page. These are the most widely used desktop editing/reading tools and no enterprise wiki would be successful without seamless integration with these products/formats.
• Seamless integration with corporate LDAP and single-sign on is important in enterprise deployments. From the end-user point of view accessing the wiki should be as painless as possible, to ensure higher adoption.
  
• Prepare end-users to work in a collaborative environment. If they are putting up content in the wiki they should expect all type of comments and feedback - not all of which may be useful.
• There is no single best practice on how a wiki should be rolled-out within a large organization. But it is best rolled out within those groups/departments that have immediate use for it. Forcing the wiki as a company-wide mandate is usually not a good idea – it can lead to a "Oh-God-Not-another-tool” reaction.
• Let the wiki adoption grow virally. As users within the organization , send out wiki links or email a wiki page, other users automatically get interested or at least get curious to know about wikis.
• Social bookmarking and rating features is very helpful in promoting wikis. Features that show the popularity of pages e.g Most read pages or most commented pages give users a sense of what is being read by users in general. Rating allows users to actually rate articles in the wiki.
• Appreciating the work of wiki contributors by instituting awards like “Contributor of the Week” or “Best Wiki contribution” within the organization go a long way in encouraging users to contribute towards the wiki.
• Best to store content in some standard form like XML or HTML. There is no standard for wiki mark-ups and it is probably not a good idea to have all your corporate content in a specific wiki mark-up.
• Ability to scale up elegantly is paramount for large deployments. Server-side wiki solutions should be scalable via clustering. Open-source solution often fail in this criterion.
• Seamless failover is another technical must-haves for large wiki deployments running on a cluster. Even if wiki applications may not be mission critical, users don’t like to lose content if the application ever goes down.
• The wiki should work on all popular browsers with little or no impact in the functionality. This can become challenging as richer functionality like WYSIWYG, drag-drop etc get introduced into the product. Fact remains that users will be using different browsers, but would expect similar behavior.
• Ability to extend functionality via a robust and flexible plugin framework is important for any Enterprise Wiki. At some point, enterprises always need to integrate their wiki with existing applications and it is best to achieve this integration through APIs/plugins etc instead of a very tight integration.

This is it for now. I will address other issues that come up in the enterprise adoption of wikis in future posts.

Why this blog?

I am the Product Manager for eTouch SamePage, an enterprise wiki and blog solution and a significant part of my work is evangelizing Web 2.0 solutions like wikis and blogs within large enterprises and constantly learning on what works and what does not.

Through this blog, I will be sharing some of the things I learn from these experiences. While a lot of my blog posts would be based on the SamePage product, I will also attempt to relate them to general benefits and challenges of wiki and blog solutions, so readers can also relate to their own experience using wikis within the enterprise.

Finally, I will try to be as regular as possible with my posts (atleast one new post every other week) though I may not be able to keep up when things get really crazy ;-)

Please feel free to comment and share your own experiences with wikis in the enterprise.