Planning & Sustaining Wiki-based Collaboration Projects
Nov 09 2007, By Maish Nichani, (8) Comments
Many organizations are experimenting with wiki-based collaboration projects. But only a small percentage of these projects make it past the initial excitement or pilot phase. One of the reasons for the drop-off is that there’s not enough thought given to them other than deciding which wiki product to install. This article presents a framework that can help groups wanting to use wikis for internal projects better plan and sustain their collaboration efforts.
Modern work is collaborative. It’s no longer about about few people having the answers and others depending on them for it. Now it’s all about many people having bits and pieces of the answers and each depending on the other for it.
There is desperate need for collaboration in the enterprise. And were it not for some humble technologies, this need would still be unmet. Wikis along with blogs, social bookmarking and the like are giving staff a reason to cheer. Not only is the technology readily available and largely cheap, but for the first time staff can focus on the work and not on working the technology.
There are many articles written on the benefits of using such tools - collectively referred to as Enterprise 2.0 - and on adopting them across the enterprise. In this article we’ll narrow our focus. We’ll target groups within the enterprise that are thinking about starting collaboration projects.
Framework
Since there is a strong tendency to start using a wiki, we’ll base the framework on this stage. There are two additional stages, one before the install stage and the other after the install stage. This is illustrated in the diagram below. Although adding the Plan and Sustain stages is plain commonsense, the trick is in asking the right kind of questions and getting the right kind of thinking going.
Plan
It is the nature of wikis to inspire a freewheeling attitude, but this should not stop us from thinking and planning to use it right and use it well. Here are some questions that need answers:
- Why this project? Is there a real need or is it just an experiment?
- What are current collaboration grievances the project is going to address? Focus on the collaboration aspect. The last thing we want is for the wiki to become a file server.
- Will existing ways of doing things still be available? This is crucial. We don’t want an existing way of work to cannibalize the new way of work. That is why we need to pay attention to the collaboration processes. See the British Council example below.
- Who are the members of the group? Do we have their support for this project? Have we managed their expectations? The last thing we want is for members to be taken by surprise.
- Will members require training? This is not so much training on the wiki software as it is training on the nature of collaborative work and on accountabilities and responsibilities of being in such a group.
- What is the budget? And can we get it?
- What infrastructure will be required? Is it available or will it have to be purchased?
- Who will be championing this project & does he/she have the time for it? If the champion cannot provide dedicated time and effort to this initiative then it could easily loose momentum.
- Do we have any senior management person on our side? If not, can we get someone’s attention? Having a senior manager's blessings can do wonders when when it comes to money and matters of influence.
Next is to focus on the collaboration process itself.
This is an often neglected area, but it offers the most benefit in terms of sparking real collaboration. The basic question here is “can we tweak the certain processes to increase the energy of participation and collaboration?” An example is needed here.
The British Council in Singapore has been experimenting with wikis for many years. One of their long standing concerns was that people were not updating their profile pages on the wiki. These pages not only had their names and contact details but also had their project details. The past and current project information is something of value to others. The challenge thus was to have regularly updated profile pages. They found a solution by tweaking the induction process of new hires. New inductees now had to meet project members and find out about them and their projects. Fresh with this new understanding they were made to update the profile pages of each member they met. This way new hires got to know other members and the profile pages got updated.
Note: Looks like I've misinterpreted the above story. Mark Hamilton from the British Council has described the 'real' deal. See the comments section below.
Here are some questions that can help.
- What are the current process? List and flag out the ones that require collaboration and those that are merely administrative.
- How many of them are now redundant, outdated or trivial (ROT)? If there are ROT processes, can we eliminate all of them?
- What new processes will increase contribution and keep wiki pages updated?
- Which traditional individual processes will benefit the most by opening up to collaboration?
As you might guess, getting answers to the above questions itself requires collaborative effort. What better way to build a shared mindset than by agreeing on the rules of engagement.
Use
Many new wiki projects dive directly into this stage, and its easy to see why. This stage delivers the most in terms of excitement and satisfaction. But it pays to be a little prudent here.
If there’s no wiki system already in place, then this is the stage where one is selected and installed. Remember, a wiki is but a tool to enable collaboration. It makes sense, then, to base the selection of a particular wiki on the collaboration needs and requirements. This framework’s Plan stage can help in this regard by helping uncover current and future needs.
If there’s already a wiki system in place, then this is the stage where the system is evaluated and prepared based on the understanding gained from the Plan stage.
Sustain
This stage is about seeing the project through. They key to sustaining the collaboration effort is to realize that this cannot happen automatically. It requires considerable time and effort.
There are three factors that need attention:
- Support
- Housekeeping
- Improvement
Support efforts will be mostly around learning and training. Here are some points to consider.
- Help new members get up to speed with the wiki. There will be many who harbor fears, uncertainties and doubts (FUDs) on working the wiki way. The “Be bold and don’t worry about messing up” feeling takes time to rack up. The sandbox page does work wonders here, but it still needs some perseverance and creativity to remove the FUDs.
- Help members understand collaboration and the behaviors that successful collaboration requires. Having one-hour "sparking collaboration" sessions where case studies, best practices and new thinking are discussed can do wonders in keeping the motivation going. If face-to-face sessions are not possible then make the materials available online.
Housekeeping is about being fresh & tidy. Here are some points to consider.
- Pressure members to use their own names and not nicknames. Although a small requirement, this goes a long way in building trust.
- If there are stub pages - pages with incomplete content - then give the owners a date by which to fix it or remove it.
- If there are duplicate pages or pages focusing on the same topic, then its best to combine them.
- Get the IT team to regularly take backups and update the wiki software when new versions come in.
- Fix any lingering organization, labeling and navigation issues.
Improvement is about getting better and raising the bar. Here are some points to consider.
- Have an area to discuss new ideas and insights.
- Have an area to review progress - what is working and what is not.
- Have an area to document the learning. This is going to help others in your organization leverage the new knowledge.
- Have an area to track the improvement initiatives so that members can actively monitor and discuss them.
Conclusion
There are many who jump start wiki-based collaboration projects by directly setting up the wiki and inviting others to contribute. While this might work for groups where the wiki concept is already well-grounded, our experience tells us that this approach does not work for groups that are new to the concept of collaboration, let alone wiki-based collaboration. Hence the need for some guidance and structure. This article presents but one such approach to help groups plan to see a project through. If you’ve come across a different approach, we’d like you to share it with us.
8 comments so far
The commenting section is closed for this article.
You have a valid point Venkat. That is why this framework should be used as a thinking framework not as a top-down directive to kick-start projects. I was contemplating putting the number of days for each stage but thought that might be too much information. From our experience the Plan stage should not take more than 1-2 days for small projects and 3-4 days for larger projects, the major effort going towards understanding and designing simple collaboration processes. The Sustain stage is ongoing but should not take more than 2-3 days to nail down much of the guidelines.
From our experience and from the experience of others, see Ross Mayfield’s interview http://www.socialtext.com/how-to-start-a-wiki, there is a tendency to use wikis without any goal or direction in sight. And it just takes a few such experiments to take dilute the power of wikis in organizations.
This article was written for those groups in organizations who are past the experimenting stage and now want to put it to real use.
By Maish (website) on Nov 11 2007 | comment permalink
Planning is good.
Too much planning without action is bad.
No planning is worse.
By Dennis McDonald (website) on Nov 11 2007 | comment permalink
Looks like I misinterpreted the British Council story. Here’s the actual implementation. Thanks to Mark Hamilton from the British Council for the clarification.
The pages are not ‘profile pages’. The document is a staff handbook which gives staff all they need to know about living in Singapore and working at the British Council in Singapore. It’s mainly for new staff, but useful for all staff. It was originally a Word document. Now it’s on a wiki.
The problem was that nobody was updating the material in the Word document. The reason for this was that the content ‘owners’ were managers who were not best placed to know what changes needed to be made to keep the document up to date. These managers were also too busy - updating the document was a very low priority for them. The document quickly became out of date and useless.
The people who were best placed to know what needed changing were the new staff who actually needed to use the document. By giving them the
task of updating the document during their induction, we managed to
* keep the document up-to-date,
* ensure all new staff read the document (and since they’re responsible for editing it, they read it more carefully than if they were told that it’s just ‘for information’),
* get newbies talking to oldies to check parts of the document (this is particularly good for the inductees because it helps them establish relationships and communication channels).
By Maish Nichani on Nov 12 2007 | comment permalink
I like this very pragmatic approach combined with the urge to think it through and not doing wikis for wiki’s sake.
I’ve blogged about an example where we worked with a client to use a wiki for collaborative policy drafting - the process we were replacing was a long drawn out series of committee meetings and endless circulation and recompilation of Word documents for comment - we used a half day “wiki-raid” where 80% of the draft was completed in a single meeting with everyone working in the same room on a wiki, drafting and revising each others’ pages. With a clear objective and a focus as you say on the collaboration rather than on the technology, the real value of the tool can be realised.
http://www.greenchameleon.com/gc/blog_detail/thinking_about_wikis_and_wiki_raids/
By Patrick Lambe (website) on Nov 12 2007 | comment permalink
I mentioned this post in my own blog here:
By Dennis D. McDonald (website) on Nov 14 2007 | comment permalink
Very nice article. I’ll use this article as a toolkit for future planning. I like the planning stage as it forces us to be really sure of ourselves before implementing a Wiki.
I feel the level of planning scales depending on the size of the implementation. For example, it may be worthwhile to consider a low-maintenance access-control framework and manpower resource for organisation wide implementation. Like it or not, there will be people out there who are apprehensive about mass sharing. Pre-defined access control models endorsed by management can help ease some future admin overheads and patchwork.
In the sustaining phase, it may be good to also plan about conflicts resolution, e.g. when 2 parties are reverting back to their version of the article. And with a strong purpose for Wiki established, someone must be out there to confidently market the use of Wiki, in contrast to other collaboration means available. Overuse of email is often the culprit.
By Simon Goh (website) on Nov 15 2007 | comment permalink
Without planning, there is only luck. Great article. I appreciate your time you put into this.
By HDTV (website) on Mar 01 2008 | comment permalink
Thanks for a very good article Maish. A minor point to ponder though: While the detailed set of guidelines will no doubt help one to plan, introduce and sustain wiki-based collaboration on projects, I am also afraid the exhaustive nature of these guidelines may also intimidate someone contemplating wiki use, perhaps lured in by its purported simplicity, ease-of-use, and organic growth. Detailed planning, training, deadlines etc., run the risk of turning a wiki into a top-down IT initiative.
By Venkatesh Rajamanickam on Nov 11 2007 | comment permalink