(2012: This post has been edited to remove company-specific information)
A mail I got a couple of days ago asked if we could have a discussion on how to ensure a wiki’s success. Thought about it for a while and noted down the top few factors (not in order) for the success of a wiki.
Recognition of need -
It is important that as many as possible realize the need for a change or movement to a wiki. There will be a lot of resistance even if everyone is on board but if the team don’t see the need and/or don’t know what benefits a wiki has to offer, creating a wiki-culture will be even harder
One benefit (in hindsight) that our team had was that many many things are new - we were a reasonably fresh team and were re-architecting the product and so it was imperative that we come up with an efficient way to spread the knowledge. An established team doing oft-repeated tasks would probably have resisted a wiki.
Buy-in from Senior Management
It is important that the management support you. There many be several instances when you need exemptions, resources, time and people which only management can help with. Passion
It is not important that the entire team care about the wiki but it is very important that at least some care passionately.
Though our wiki has had highs of 25,000 odd views (per month), it has never gone beyond a 1000 edits. The same set of 5-10 people contribute and help the other 300 odd
A Core Group
The initial work forms the basis of the wiki-to-be. It is much easier if a core group helps the Wiki-anchor create the content. At least until critical mass (viewership) is reached.
Our core group was comprised of leads from all the Framework teams who were conscious of the need for a wiki and enthusiastic to participate.
Authority & Empowerment
The wiki-anchor needs to be empowered & have the authority necessary. Often, a little pushing is required before people start to contribute
Empowerment: My manager told me early on that I would be able to take decisions. This trust helped immensely when difficult decisions had to be made.
Authority: Many of the initial updates were done by people under coercion - A few eventually realized the benefits wiki brought. Once they did, contributions from this minority became voluntary. The majority are still feeders & haven’t yet been motivated to seed voluntarily
Technical & non-technical Aptitude
The wiki-anchor should be chosen considering both his/her technical and non-technical skills
Being someone who enjoys teaching and documentation, I volunteered for the task. Though time-consuming, it has remained enjoyable for almost 2 years now Time/Planning/Process - Eventually all ‘initiatives’ die their natural deaths. It is important to incorporate these as processes
Several topics on our wiki were not just knowledge-sharing documents but also part of the project processes. For instance, every team had a page where details of the Database, URL could be shared. Once information is made this accessible, people rarely regress back to mails. Skeletal Structure, Gardening and Identifying opportunities
Because of the very nature of a wiki, it can grow without any structure and soon become a maze. It is therefore important to first create a solid base and then maintain it regularly to ensure that people are following norms (naming, categorizing). It is also important to identify opportunities where the wiki can be used and point them out to people
Structure & Gardening
A wiki should ideally end up as a tree with branches and nodes. Exactly how it will look will depend on each project.
Identifying Opportunities:
Early in our wiki’s life, we realized that simplifying the interface would help encourage contributions. All the SMEs were getting repeated questions. We put in a FAQ system which allowed folks to ask and categorize a question in under a minute. The anchor could view questions categorized by topic and could answer. This system avoided repetitions & helped add to the wiki. Today, the FAQ system constitutes more than 50% of the pages on our wiki