Firefox® is a registered trademark of the Mozilla Foundation. Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.
Wikis and other online collaboration tools have been around for several years now. Wikipedia is the best-known example of a wiki, and its growth has been nothing short of tremendous. From the time it was launched in 2001 until 2007, Wikipedia grew by an astonishing 19 million percent. As wikis have grown on the World Wide Web, businesses have looked for ways to implement this tool at the enterprise level. Several of our clients use wikis for collaboration, as do my colleagues here at Fredrickson Communications.
But how can you cut through the hype and make the best possible use of this tool? Is it enough just to install wiki software on your intranet and tell your employees to start writing? Unfortunately, all of the benefits and challenges of enterprise-level mass collaboration have yet to be fully explored. However, based on research I’ve done at the University of Minnesota, I can offer early adopters of enterprise-level mass collaboration tools some do’s and don’ts when implementing these technologies in the workplace:
I analyzed 50 random Wikipedia pages to see if there was a correlation between the number of editors that worked on an article and the article’s readability according to the Flesch Reading Ease scale. I was surprised to find almost no correlation between these two factors. On the organizational level, these two variables may not be significant, since readability can be judged in a number of ways and the organization may have a very limited set of potential contributors. However, the takeaway is clear: a large numbers of editors will not necessarily create consistent, readable documentation. If consistency is a goal, you’ll have to follow the tip below.
In the popular mind, wiki collaboration is sometimes thought of as completely without structure. Anyone can make any change they wish, at any time, completely anonymously. This may leave readers of wikis asking themselves, “Do I really trust the writings of a wiki contributor, knowing absolutely nothing about his or her qualifications for instilling some semblance of expertise into a wiki?” (Glass, 2007)
However, successful open collaborations do not develop without structure. When people collaborate on a large scale using tools such as a wiki, they self-organize into certain roles, such as author, editor, tester, and user. Likewise, in successful large-scale open source programming projects, such as the development of the Linux kernel, the contributors organize themselves into roles and responsibilities. Some people work on bug fixes, approve those fixes and send them out for testing, and others make the final decision on when the fix is ready to be put into the next release. Still others work on the cutting edge, creating new features for future releases. Since you are not likely to have the critical mass required for this kind of self-organization, you need to help create this structure. Who will write? Who will edit? Who will review and approve? Who will maintain the resource over time?
Finally, realize that work in open environments does not distribute itself evenly. Following the Pareto principle (the 80/20 rule), it’s likely that 80 percent of the work in an open collaboration project will be done by 20 percent of the people. Don’t expect that once you set up a wiki and establish a structure for your collaboration team, all of the team members will put forth the same amount of effort. The strength to truly open-source projects comes from their flexibility: team members contribute however much they want, whenever they want to do so. This may not be practical for the goals you have for your wiki, but ignoring the 80/20 rule won’t make it go away.
Online collaboration does promise a great deal. And it has a proven track record, as evidenced by the success of open-source software projects such as the Firefox® web browser and the Linux® operating system. But to make the most of it, organizations need to remember that it is not a panacea. You’ll still need to provide structure and leadership for it to work to its fullest potential.
In part two of this article, we’ll take a look at some specific best practices that have been proven by the success of the open-source software movement:
• Make it interesting.
• Make it meaningful.
• Make it transparent.