Monday 23 July 2007

Organising a workshop using a Wiki

Following from my recent post, 15 productive uses for a Wiki, I have been thinking about how wiki's can help improve collaborative working - No. 16, Organising a workshop using a wiki .

Workshops are used to gather small groups of people over a short period of time to concentrate on a defined area of concern. They are used to brainstorm, discuss ideas, help in decision making, and to plan a course of action.

Usually a workshop is organised by a facilitator, who will invite participants to attend via email. This email will include the title of the workshop, date & venue, a brief description of what is to be discussed (background, progress-to-date) and the list of invitees.

At this stage, the facilitator will probably field a number of questions in relation to the workshop from invitees requesting further information. So, when the facilitator responds to each individual question, we are in a situation where the workshop has already been siloed into a number of individual channels - before it has already begun!

This is where I see the opportunity for improvement. I think it would be useful for the facilitator to setup a wiki for the workshop. The wiki would include:
  • Workshop Wiki Homepage - (Title, Brief description, Aims & Objectives) This page sets the scope of the workshop, and is the entry point to the wiki.
  • Admin Details - (Date, Time, Venue, Contact details, List of Attendees etc.) This would help eliminate the standard phone calls and other queries in relation to the basic information for the workshop.
  • Agenda Page - (List of items for discussion, Presenters, Workshop Structure) This page will allow invitees to remind themselves of what will be discussed. This can be updated/altered in accordance with comments/suggestions in the time leading to the workshop.
  • Background Information - (Documents, Intranet Pages, Presentations, and other related material) This would help invitees to prepare themselves for the workshop by having quick access to all relevant material which will support the workshop on the day.
  • Workshop Discussion Page - (Facilitators' answers to pre-workshop queries) This would allow all invitees to keep up to date with any queries, additions to the agenda, and comments/suggestions by all involved.

The main challenges to managing the communication via email, and keeping invitees up-to-speed in the time leading to the workshop are well presented by Jeff Oxenford in his post Death by e-mail. Jeff points out that:

While e-mail is a wonderful thing, it's not designed as a discussion tool for the following reasons:

  • E-mail is one-way communication, not discussion.
  • Written words and tone often get misinterpreted - 90% of communication is non-verbal.
  • Messages often cross in cyberspace, so you're commenting on proposal 1 while others are commenting on proposal 3.
  • It's much easier to be negative when talking to a computer screen
  • People don't read every word of an e-mail message.
  • Many important decision makers tune out when the flow of e-mails get too great.

Like Jeffs' guidelines for email, I would say that:

  • Send out the Invitation by e-mail (in the form of an invitation to the new workshop wiki).
  • Accept comments/queries, responding with an acknowledgement, and a link to the page on the workshop wiki where the comment has been noted/addressed/been posted for collaborative reaction.

So the advantages are:

  1. Capture Knowledge - Gather all the relevant background documentation and information required for the workshop.
  2. Organise Knowledge - Setup the workshop wiki, with areas for confirmation, collaboration, and communication. Avoid crippling delays and irrelevant discussion on the day by allowing attendees to contribute ideas and suggestions before the workshop takes place.
  3. Target Knowledge - Allow all of the attendees to get up-to-speed before the workshop. The wiki also allows for those unable to attend to contribute in some way.
  4. Transfer Knowledge - Document action plans and outcomes of the workshop for all attendees to see. This allows all involved to keep up-to-date with the "What next?".
  5. Maintain Knowledge - Allow future reference to the work carried out in this process so as to help in other projects and prevent re-work.

Please let me know what you think. I may consider exploring collaboration-enabling topics such as this one for my KM dissertation.

Related:

Application of Wiki's (wikipedia)

Supporting Community Through ICT (Rountable Workshop)

Wednesday 18 July 2007

15 Productive Uses for a Wiki

Here is a great resource from Web Worker Daily, called 15 Productive Uses for a Wiki, posted by Leo Babuta.

The 15 uses listed are:
  1. To-do list
  2. Project Management
  3. Operations Manuals
  4. Checklists
  5. Plan an event
  6. Log client work
  7. Track invoices
  8. Notes & Snippets
  9. Goals
  10. Contacts
  11. Workspace
  12. FAQS
  13. Collaboration
  14. Reference
  15. One place for everything

Depending on the size of your team, the culture in your workplace or your personal preferences, any number of these suggestions are applicable to improving your working environment.

Wiki's won't change the world, but I like them, and I believe that they will appeal to younger professionals in the future who regularly use social networking and collaborative tools as part of their daily college experiences.

Be sure to check out all of the "responses" below the post, as there are many testimonies from individuals and groups who are using wiki's to improve how they work.

I am using a wiki, (early stages at the moment), to manage my KM dissertation. I chose Wetpaint, which allows me to setup custom page templates enabling me to document categorised case studies and paper reviews in a consistent manner. I am hoping it will also provide an interesting medium for collaboration with my supervisor.

You can see the Extacit Wiki here.

Tuesday 17 July 2007

An introduction to Knowledge Management

Here is a nice resource from CIO.com called An Introduction to Knowledge Management, which was wriiten by Meridith Levinson.

It briefly covers the following aspects of KM:

What is Knowledge Management (KM)?
What constitutes intellectual or knowledge-based assets?
How can tacit knowledge be transferred?
What are the benefits of KM?
How can I sell a KM project in my organisation?
How can I demonstrate the value of a KM initiative?
Best approach to KM?
Challenges of KM?
How to gain support for, and ensure sustained engagement with KM systems?
Who should lead the KM efforts?
What technologies support KM?