The talk was organized in three parts. I started with an introduction to wikis, starting from the beginning, and highlighting their key features. My colleague then presented on her firm’s innovative use of Thoughtfarmer wikis. Then I discussed how my firm is leveraging Sharepoint wikis.
An Introduction to Wikis
I began with the definitive origin of the word "wiki" as I am often asked where the word came from. Wikipedia has the answer--the Wiki Wiki bus at Honolulu Airport was Ward Cunningham's alliterative inspiration for his WikiWikiWeb application, the first wiki created. Ward wanted "the simplest online database that could possibly work," and it appears he succeeded!
(I did not report that, unlike most wikis I've encountered, apparently the Wiki Wiki buses are being retired soon as "not only...somewhat inconvenient and uncomfortable" but also "a huge strain on the building structure due to their weight and level of activity.")
The word "wiki" means "quick" in Hawaiian. On a wiki, you can quickly edit, save, link, and restore.
Edit -- Wikis always have a large friendly Edit button somewhere, and the whole point is that wikis are available to an entire group (or anyone who sees it).
Save -- There is normally no moderation before the edit takes place. On Wikipedia articles that have an established history of unproductive editing or great controversy are “locked down,” but that is not the norm.
Link -- There are two kinds of links in a wiki.
As in any HTML-based platform, adding a link to a web site or other URL-related resource is a matter of selecting a word and hitting a button or a keyboard command such as “Ctrl.-K” (Hopefully this shortcut is becoming this decade’s version of Ctrl.-C “copy” Ctrl.-X “cut” and Ctrl.-V “paste.”)
Additionally, one can create a new web page by creating a link to it (the exact procedure varies from wiki to wiki). Easy page creation is a key feature because it enables editors to add structure to the wiki and to limit the amount of content displayed on a given page. (Usability concerns mandate avoidance of “walls of text,” even in a content-rich context like an encyclopedic wiki.) Once one creates a page it is easy to create another link to it, either from a drop down or by some use of the page name. Easy interlinking greatly enhances the ability to relate different topics within a single wiki.
Restore -- A wiki captures each page version and allows reversion to a previous version (the reversion becomes the latest version).
Modern wikis also serve not just as living documents, but also as communication platforms because they have built-in notification of changes of one kind or another (ideally RSS, but often email as well).
The communications aspect of wikis leads to wiki happiness, contrasted with the email sadness from wasted time sending documents as email attachments, editing, saving them, sending them again, rinsing, and repeating.
Another way that "wikis" is a wonderful word, as I have previously blogged, is that it forms a KM acronym (knacronym?):
What
I
Know
I
Share
(Thanks to Attensa and Patrick Slesinger of Wallem Group for that one!)
Thoughtfarmer—Wikis as Intranet and DMS
My colleague then presented on her firm's innovative use of Thoughtfarmer wikis. Thoughtfarmer comes complete with cutting-edge (for a law firm) Enterprise 2.0 features like tagging and commenting, Her firm did not have either a formal DMS or an intranet, so they used practice-specific wiki pages as a means of organizing documents as well as other substantive and practice-related content. Hers was the kind of presentation that makes me wonder how a large organization would organize its information if it could start from the ground up with cutting-edge technology instead of having to address the innumerable complexities of legacy systems.
Sharepoint Wikis at Goodwin Procter
I then turned to what we have been doing with Sharepoint wikis at my firm. Sharepoint “native” wikis and blogs are actually part of the reason why I became interested in blogs and Enterprise 2.0 in the first place. They come built-in to Sharepoint, and my firm rolled Sharepoint / MOSS 2007 in late spring 2008.
Unfortunately, due no doubt in part to the necessarily long development cycle (they may have been state-of-the art in 2004), Sharepoint wikis have their weaknesses. The alerts of changes are horrible (see “Sharepoint wiki disaster”). Sharepoint email alerts send the whole page, worse than a simple notice of the fact of a change and much worse than a display of the change to the page as we had been accustomed to from another wiki platform. Furthermore, a surprising “simultaneous editing” flaw allows multiple users to edit the same page, but gives priority to the person who saves first.
Sharepoint wikis also have two strengths compared to some other wiki applications. It is really easy to get started with a Sharepoint wiki; the page linking in particular is simple, intuitive and effective (just put [[double brackets]] around words to link or create other pages). And because, under the hood, Sharepoint wikis are built on the powerful if complex Sharepoint “lists,” there is a huge variety of categories and metadata that can be applied to a page.
Wikis For Project Management
This last feature gives Sharepoint wikis strength in one of their most prominent roles inside my firm—project management. In my KM team’s wiki, many pages embody KM projects; these pages are tagged with the names of project participants, and also with a status tag like “Active” “Completed” “Subsidiary” and so forth. My boss or I can quickly see my active projects at any time by looking at a view of the pages in the KM team wiki, showing only “Active” pages tagged to me and sorted by most recently edited. I learned this week that is even possible to display the content of a wiki page in a view of pages like this.
On a given wiki page devoted to a project, it is easy to record and share the latest project status, with project goals, business plans, and links to related projects, people, and resources.
At my firm, project management-style wikis have spread to a number of administrative groups including professional development, recruiting, and legal department management.
Meeting Management
The KM Team also uses wikis to manage its meetings. An agenda on a wiki does not just list what team members wish to discuss; it can link to the project or discussion page and thereby avoid the necessity for giving background information about a new item at the meeting. Wikis are also used on occasion to take notes at a meeting.
Discovery Sharing
One litigation-specific use was sharing and developing a nucleus of facts arising out of discovery in related cases. An early adopter used a wiki to share information among many people on different matter teams. The cases had different procedural aspects and parties, but shared a common set of underlying facts about the technology and related patents that were developed through discovery. Not surprisingly, this wiki had a very steep uptick in use as it got started, and then, as the discovery period wrapped up, use slowed down again.
Success?
As a project management tool I think Sharepoint wikis have been a qualified success. Despite a complete absence of any sort of internal marketing of this tool, there are now over 900 wiki pages (compared to ~500 pages on our long-developed intranet), and I am getting requests for specific targeted uses of wikis. The jury is still out on the other uses, which are still arising as use spreads.
Lessons Learned
The relatively primitive nature of Sharepoint wikis means you have to manually add in some features that are automatically generated in other platforms. One of these is simply a link [[Home]] to the wiki’s home page. Similarly, in wikis with what are substantively subsidiary or tiered groups of pages the navigation to and among those pages needs to be manually generated.
There is a built-in “help” page that is automatically generated for every new wiki; we’ve replaced it with a link to set of help pages in a central location.
As with other wikis, we’ve learned not to let a wiki page be a dead end. Find and link to other related wiki content.
Finally, show users what will happen when they click on a link beforehand. If the content is not another intranet, internet, or wiki page, you need to prepare users by indicating the document type (.doc .pdf). Where linking to a document in our DMS, we indicate the document number as that insures against link breakage and misspelling.
I then turned to what we have been doing with Sharepoint wikis at my firm. Sharepoint “native” wikis and blogs are actually part of the reason why I became interested in blogs and Enterprise 2.0 in the first place. They come built-in to Sharepoint, and my firm rolled Sharepoint / MOSS 2007 in late spring 2008.
Unfortunately, due no doubt in part to the necessarily long development cycle (they may have been state-of-the art in 2004), Sharepoint wikis have their weaknesses. The alerts of changes are horrible (see “Sharepoint wiki disaster”). Sharepoint email alerts send the whole page, worse than a simple notice of the fact of a change and much worse than a display of the change to the page as we had been accustomed to from another wiki platform. Furthermore, a surprising “simultaneous editing” flaw allows multiple users to edit the same page, but gives priority to the person who saves first.
Sharepoint wikis also have two strengths compared to some other wiki applications. It is really easy to get started with a Sharepoint wiki; the page linking in particular is simple, intuitive and effective (just put [[double brackets]] around words to link or create other pages). And because, under the hood, Sharepoint wikis are built on the powerful if complex Sharepoint “lists,” there is a huge variety of categories and metadata that can be applied to a page.
Wikis For Project Management
This last feature gives Sharepoint wikis strength in one of their most prominent roles inside my firm—project management. In my KM team’s wiki, many pages embody KM projects; these pages are tagged with the names of project participants, and also with a status tag like “Active” “Completed” “Subsidiary” and so forth. My boss or I can quickly see my active projects at any time by looking at a view of the pages in the KM team wiki, showing only “Active” pages tagged to me and sorted by most recently edited. I learned this week that is even possible to display the content of a wiki page in a view of pages like this.
On a given wiki page devoted to a project, it is easy to record and share the latest project status, with project goals, business plans, and links to related projects, people, and resources.
At my firm, project management-style wikis have spread to a number of administrative groups including professional development, recruiting, and legal department management.
Meeting Management
The KM Team also uses wikis to manage its meetings. An agenda on a wiki does not just list what team members wish to discuss; it can link to the project or discussion page and thereby avoid the necessity for giving background information about a new item at the meeting. Wikis are also used on occasion to take notes at a meeting.
Discovery Sharing
One litigation-specific use was sharing and developing a nucleus of facts arising out of discovery in related cases. An early adopter used a wiki to share information among many people on different matter teams. The cases had different procedural aspects and parties, but shared a common set of underlying facts about the technology and related patents that were developed through discovery. Not surprisingly, this wiki had a very steep uptick in use as it got started, and then, as the discovery period wrapped up, use slowed down again.
Success?
As a project management tool I think Sharepoint wikis have been a qualified success. Despite a complete absence of any sort of internal marketing of this tool, there are now over 900 wiki pages (compared to ~500 pages on our long-developed intranet), and I am getting requests for specific targeted uses of wikis. The jury is still out on the other uses, which are still arising as use spreads.
Lessons Learned
The relatively primitive nature of Sharepoint wikis means you have to manually add in some features that are automatically generated in other platforms. One of these is simply a link [[Home]] to the wiki’s home page. Similarly, in wikis with what are substantively subsidiary or tiered groups of pages the navigation to and among those pages needs to be manually generated.
There is a built-in “help” page that is automatically generated for every new wiki; we’ve replaced it with a link to set of help pages in a central location.
As with other wikis, we’ve learned not to let a wiki page be a dead end. Find and link to other related wiki content.
Finally, show users what will happen when they click on a link beforehand. If the content is not another intranet, internet, or wiki page, you need to prepare users by indicating the document type (.doc .pdf). Where linking to a document in our DMS, we indicate the document number as that insures against link breakage and misspelling.
No comments:
Post a Comment