Like last week, the 2-hour session was attended by 15 staff members from across the organization.
The session started with the usual introductions of facilitators and with background information from Stephen Katz, Chief Knowledge Exchange Branch, on the purpose and motivations for the KS training courses.
This was followed by the commoncraft video about "Wikis in plain English".
Romolo then explained what Wikis are and their specific characteristics such as inline editing/saving, easy and open access to history, versioning/differences information and the ability to role back, discussion tag, comparison of edits, notification of edits using emails or RSS, user management/permissions. He also talked about the need for to focus on accountability and transparency, rather than security/authority/ownership. He gave examples of how for a wiki to grow there is a need for "sense of community" and the role of culture (of an organization).
After doing an after action review on last week's session, we decided to stick to only one example per Wiki software (that is Media Wiki, Wikispaces and Google Sites). Each Wiki was described by focusing on the following questions:
- Why does the Wiki exist?
- long-term or short-term? Why – project, meeting, etc?
- Who is the Wiki for? Type of people (technical, dispersed...)? Number of users?
- How was the software chosen? How does it help/hinder?
- Show and describe history tracking
- Show and describe editing
- Is it public or private – why?
- Is it locked or unlocked – why?
- Summary of experience?
- What lessons were learned that would be useful for today’s participants?
- FAO Web Guide - using Media Wiki
- CGIAR - FAO KS Toolkit - using Wikispaces
- CGIAR Collaborative Writing Site - using Google Sites
What would be a good approach to ensure Wikis become part of the way we work?
Very often, I have seen Wikis being created but either used by only the creators or not used at all. It is important to understand why this may be happening. Some of the reasons could be that we are too used to working in our mailbox or just not willing to try out new tools.
There are several scenarios where Wikis would be best solutions when compared to using emails, however, its value often remains untapped. The approach to take, when starting to think about a Wiki-based working environment, could be to:
- Do a thorough needs analysis to ensure that Wikis ARE the appropriate tool. For example, if you would like to collectively work on a single document, the solution might simply be GoogleDocs.
- Understand the skills level of those expected to edit the Wiki. The software choice should depend on the level of willingness plus ability of the participants in editing. Some might be able to edit Wiki text but most will not.
- Ensure that all the expected contributors to the Wiki (the user community) are well aware of the value and importance of the "new way of working". Explain the benefits of using this approach when compared to the more traditional one (e.g. sending documents as attachments with different versions).
- Provide training on how to use the Wiki. This could be a one-hour hands-on session where participants can try to add/edit, embed images, etc. Giving them a sandbox to play with helps to increase their comfort level. Explain the transparency aspect of the Wiki by showing how the history function. Ensure that credit will be given where it is due.
- Nurture the community, get them involved in managing different aspects of the Wiki, regularly send out reminders for contributions. Create a community of "Wiki gardeners".
- Don't push! Give people opportunity to learn and get used to using Wikis. Don't sell it as THE solution! The more they use it, the more the will think of innovative ideas for using it in other projects.
- Promote the Wiki as a good example of using new social media tools for getting the work done in a better way.