"Wikis have changed the way we run meetings, plan releases, document our product and generally communicate with each other" - Eric Baldeschwieler, Director of Software Development of Yahoo!
Wiki, a writable web: Communities can share content and organize it in a way most meaningful and useful to them
If extended with the right set of functionality, a wiki can be applied to the workplace to schedule, manage, document, and support daily activities
A structured wiki combines the benefits of a wiki and a database
This tutorial explains publishing wikis and structured wiki, covers its deployment, and shows some sample applications using TWiki, an open source enterprise wiki platform
Presentation for Wiki Symposium, Montreal, Canada, 22 Oct 2007
-- Peter Thoeny
- peter.thoeny.public AT twiki.net
- TWIKI.NET
Invented the concept of Structured Wikis - where free form wiki content can be structured with tailored wiki applications
Recognized thought-leader in Wikis and social software, featured in numerous articles and technology conferences including LinuxWorld, Business Week, Wall Street Journal and more
Software developer with over 20 years experience, specializing in software architecture, user interface design and web technology
Corporations typically create their own skin or customize the PatterSkin to match the wiki to corporate branding standard
Slide 33: Why Deploy a Wiki?
Wikis are robust
Wikis are fun and easy to use
Wikis solve some of the limitations of existing collaboration software:
Maintenance of static intranets
Taming internal e-mail flood
Implementation of business processes
Slide 34: Challenges of Static Intranets
Some content is outdated
Incomplete content
When was the page last updated?
Difficult to find content
Inconsistency across departments
Special tools, knowledge and permission required to maintain
Content is static, it has a "webmaster syndrome": If an employee discovers a page with incorrect or insufficient information, the employee will often ignore it because it takes too much time to find out who the webmaster is and to write an e-mail requesting an update
Slide 35: Wikis and Static Intranets
Move some/all Intranet content into a wiki
No difference for readers to browse and search content
Employees are empowered to fix content on the spot
Ease of maintenance
No need to install client side software
Consistent look & feel
Paradigm shift
from: webmasters maintain content
to: domain experts and casual users maintain content
Slide 36: Challenges of E-mail
E-mail and mailing lists are great, but:
Post and reply vs. post and refine/refactor
Great for discussion, but ... hard to find "final consensus" on a thread
E-mail is not hyper-linked and is not structured, content can't be grouped easily into related topics
E-mail and attachments are not version controlled and it is difficult to determine the history of a document
Not all interested people / too many people in the loop
Pockets of knowledge made available to interested parties
Audit trail / domain experts
Paradigm shift
from: post & reply
to: post & refine & cross-link
Send e-mail with link to content instead of content itself
Slide 38: Challenges of Business Processes
Business processes are implemented in large scale by IT department (Sarbanes-Oxley compliance etc.)
Teams follow formal/informal workflow to accomplish tasks, which is often a paper-based process (rolling out laptops to employees etc.)
No resources allocated to implement applications to automate these processes; IT department has no bandwidth to implement lightweight applications for a variety of teams
Slide 39: Wikis and Business Processes
A structured wiki is a flexible tool to support evolving processes
in the free-form wiki way -- linked pages, collaboratively maintained
and with a structured wiki application -- forms, queries, reports
Content contributors with moderate skill sets can build web applications
Paradigm shift
from: programmers create applications
to: all of us can build applications
Slide 40: What is a Structured Wiki?
Goal of a structured wiki:
Combine the benefits of a wiki and a database application
Wiki:
Organic content: The structure and text content of the site is open to editing and evolution
Open content: Readers can refactor incomplete or poorly organized content at any time
Hyper-linked: Many links to related content due to WikiWord nature
Trust: Open for anyone to edit, "soft security" with audit trail
Database application:
Highly structured data
Easy reporting
Workflow (e.g. purchase requisition)
Access control
Slide 41: Usage Pattern in a Structured Wiki
Users typically start with unstructured wiki content
Example: Call-center status board
User discovers patterns in content
Example: Call-center status board has fixed list of users and fixed list of time slots
User or administrator builds an application, typically in iterations
Goal: Automate tasks based on discovered patterns
In other words: A structured wiki enables users to build lightweight applications
Slide 42: Example: Call-Center Status Board, v1
Requirement for status board:
Easily see who is on call at what time
Easily change the status board
Start with a simple bullet list for status board v1:
Old system: MS-Word doc based, very little feedback
12 month turn around for change requests
Introduce wiki-based Quality Management System:
Roll-out took 6 month
Big productivity gain
1 month turn around for change requests
Number of review comments increased 30-100 times
Preparing weekly report dropped from 2 hours to 15 minutes
Slide 52: Case Study: Motorola Denmark (cont.)
What happened:
Shift from word processor to structured wiki application
Shift from document owned by individual to structured content owned by team
Support iterative process improvements
Discover usage patterns while using the system; enhance process accordingly
Introduced POT teams (Process Ownership Teams) to de-centralize responsibility of reviewing change requests
Delegate security setup to team leads
Quote by manager: "TWiki as such has made this process much easier. And had opened new possibilities that we would probably never have pursued if we had stayed with MS Office docs"
Use of TWiki has now grown into all aspects of product development
Slide 53: Lifecycle of a Wiki at the Workplace
1. Initial deployment - focus on:
Getting buy-in
Training
2. Growth period - focus on:
Growing laterally across teams & departments
Achieving critical mass (to benefit from the network effect)
Organizing and refactoring content
3. Large wiki > 50K pages - focus on:
Navigation, taxonomy, search
Managing stale content
May require an official or unofficial "librarian" or "coach"
Consolidate wikis into a central wiki
Slide 54: 1. Initial Deployment: A. Role of Wiki Champion
ATasteOfTWiki - a short introduction training course for beginners
(this tutorial) - Rolling Out a Wiki at the Workplace
Do not underestimate inertia and time
Expect quick growth after slow start
Example: Wind River's wiki has now 120K pages and 20K page changes / month
Slide 61: 1. Initial Deployment: H. Get buy-in from Users
The wiki champion works with the users:
Encourage frequent use, even small tidbits
Encourage users to define the future of the wiki themselves by changing content as needed
Reward knowledge sharing with inexpensive and fun gadgets, coupons, activities, etc.
Demonstrate support from management by highlighting management use of wiki
Create appropriate wiki culture from the beginning with training
Customize the wiki skin to match the branding of your organization
Slide 62: 1. Initial Deployment: I. Wikis Induce a Paradigm Shift
Management perceives wikis as chaotic; any employee can update any page
Audit trail and "soft security" of peer pressure
Wikis can be intimidating; the wiki pages appear "official" and corporate
Overcome one's own internal resistance to edit existing content
It's OK to edit, it is good to refactor and delete content (revision control)
Paradigm shift: Content is owned by team, not individual
Users want their contributions to the wiki to be "perfect"
It is more effective to post content early and let the entire team revise it iteratively
In other words - focus on:
Communication, communication, communication
Slide 63: 2. Initial Growth Period: A. Grow Laterally
Grow laterally across teams & departments:
Other teams will see the benefits of the wiki and want to try it
Train the trainers: Identify new wiki champions
Achieve critical mass:
Especially for wikis, the system thrives or dies with the use of it
Benefit from the network effect: Metcalfe's law states that the value of a network equals approximately the square of the number of users of the system (n2)
Slide 64: 2. Initial Growth Period: B. Organize Content
Organize webs:
A web is a container of pages
Use one web per department, possibly one per project
Define process to establish new webs
Balance between number of webs and number of topics per web
Few webs with many pages each: Easy to search & cross-link
Many webs with fewer pages each: Easy to define access control & to get notified
Once a wiki grows to 50K pages it becomes harder to find content
Contributing factors:
Company reorganizations - web structure no longer reflects org chart
Turn over - content maintainers change
Project life cycles - stale content; still needed for audits
Misplaced content
Grassroot wikis - content distributed in several wikis
How to address these issues:
Improve navigation and search
Establish standardized team home pages
Use folksonomy
Manage stale content
Consolidate wikis into a central wiki
May require an official or unofficial "librarian" or "coach"
Slide 68: 3. Maintaining a Large Wiki: B. Standardized Team Homepages
Every team has a team home page - with a common layout:
Top banner with image acting as team icon
Sidebar with quicklinks, resource and administration links
Box with name of team and a "what we do" description
Optional "What's new" list (from Employee News Portal)
Organization tree with links to other team home pages
Team internal links (below the fold)
Slide 69: 3. Maintaining a Large Wiki: C. Folksonomy and Tagging
Folksonomy: Term combining "folk" and "taxonomy", refers to collaborative efforts to organize content with freely chosen keywords, typically referred to as "tags"