Social learning adoption?

Wikis in plain English, another very good resource I found thanks to Frank Bradley. The video explains the use of a wiki in a very simple day to day real-life scenario.




I'm currently working on how we can use the wiki in my team to leverage on and share product knowledge. We have a sizable team that is distributed across various locations, and I think it would be valuable if my team members could use the wiki and the forum to share knowledge across this globally distributed team. At the current stage, there are just a couple of designated people who update process and standards information on the wiki, and the knowledge there is limited only to these topics. The challenges I see though are:

- Having people change their working style and go looking for information on the wiki or post queries into the forum. Currently, people are not used to visiting these sites as part of their day's work.
- Deciding what kind of knowledge will benefit others, besides what we document and create for our customers, so as not to duplicate information.
- Having people to be proactive enough to participate and share what they know. Currently, people seem to believe that only some folks should go out and update the wiki and they will just refer to it when needed.
- Keeping information current at all times as when the product release date nears, people would be swamped with work and only be focused on finishing up their document/courses and closing all bugs.

Generating Participation?
Some points I gathered from Control and Community: A Case Study of Enterprise Wiki Usage are:

1. Build a critical mass of contributors. Since the contributors are employed by the enterprise, it is possible to make the Wiki part of people’s responsibilities. At CorVu we found this to be imperative. Unlike a public Wiki (where there are many people who contribute huge amounts of time as a hobby), in a work context (where everyone is probably too busy already), this isn’t going to happen. So write it into job descriptions. Get managers to send emails to their staff saying that one hour a week should be spent writing up their knowledge on the Wiki. Arrange a seminar on how to use the system. Use the company newsletter to promote the value of the project.
2. Build a critical mass of topics. To be used, the site must be useful. To generate traffic to the site, make the most frequently required information available on the Wiki first, and make the Wiki the only source for that information. In CorVu’s case, for example, one significant page stored the latest product release information. When any software version was moved from internal QA to Beta, or from Beta to General Release, this page was updated. Once people learn that the Wiki contains a lot of useful information they will look there for answers to start with rather than wasting someone else’s time by phoning or emailing questions.
3. Send links rather than information. Set an expectation that when anyone is asked for some detailed information, the response should be a link to a Wiki page. If the information has not yet been Wiki-ized, don’t type a lengthy answer in an email; instead, spend an extra minute typing it into a Wiki page.
4. Provide recognition and rewards. As with most Wikis, the best way to encourage participation in the long term is to ensure that the efforts of the contributors are valued. This is easier in team and enterprise Wikis than in public Wikis because the contributors are known. Wiki pages can indicate explicitly who the primary authors were. There can also be rewards within the enterprise beyond the boundaries of the Wiki. For instance, some employees may have components of their annual review linked to their involvement in Wikis.

Please suggest what would be the ideal steps to have people adopt these social learning tools as part an parcel of their daily job.