Doug Cornelius .com

I finally got an answer to our major problem with wikis in Sharepoint. It is bad news.

One of the advantages to using a platform approach is the integration of the various pieces in one place, with a unified look and searching. We have been using Sharepoint as the platform for our intranet for many years, starting when Sharepoint was just “Sharepoint” then onto Sharepoint 2003 and as of April 1, Sharepoint 2007.

It was the feature set of Sharepoint 2007 that got me interested in blogging and enterprise 2.0.

We have been experiencing problems with the notification feature for wikis in Sharepoint. When there is a change to a wiki page, it sends out the whole wiki page with no indication of the changes. It is very frustrating to have a whole document, that you have already read, being sent to you with no indication of changes. That is why track changes in Word and document comparison software exists.

The wiki is creating a new version each time it is saved. The changes are there in the wiki to be discovered and presumably to be transmitted. Sending out a notification of the change is core wiki functionality. Isn’t it?

I cornered Lawrence Liu at the Enterprise 2.0 Conference to find out what we were doing wrong. I was stunned to find out the problem was not us. It was them. The Sharepoint wiki will not send out the changes. It merely sends out the entire wiki page.

This is a disaster. It removes the communications aspect of the wiki. It makes it hard to see the activity in the wiki. I see something is happening, but I have to go into the wiki, click on the history and go through each version to see the changes.

As I have posted before, it is important to have both the artifact and the flow of knowledge: Knowledge is an Artifact and a Flow. Sharepoint’s design of wikis destroys the flow.

Everyone knows that the Sharepoint wikis are basic. I have been willing to live with the simplicity. It makes them easier to understand and easier to show people how to work with them. After all, training is just another barrier to adoption.

Thanks to Lawrence for giving me a straight answer to my question. Even if the answer was terrible. Lawrence Liu can be found on his blog: Lawrence Liu’s Report from the Inside
and on Twitter: Twitter/LLiu.

In early April we rolled out Sharepoint 2007, upgrading our intranet platform from SharePoint 2003. I have been keeping track of the number of wiki pages and wiki libraries.

As of today we have:

wiki libraries: 8
wiki pages: 205

Progress has been a bit slow as we debated the wiki structure and security models. The notification system still has some problems and we want to get those fixed before we start pushing too hard.

The Firm has taken its second step into Enterprise 2.0 with the launch of our first wikis in SharePoint 2007:

Our first wiki was an import of our existing knowledge management wiki into the SharePoint platform. I wrote about that wiki in a previous post on Making Wikis Work – Success Factors. That wiki had been very successful on the external platform and I expect it will continue to be successful on the SharePoint wiki platform. There have already been several edits.

The downside to moving the wiki was that all of the links in the wiki broke. The links to our intranet were already broken as a result of the upgrade of the intranet from SharePoint 2003 to SharePoint 2007. Now the internal wikis links are broken.

We had debated on whether to move the wiki. The winning argument for the move was that “we need to eat what we cook.” If we are going to pitch the use of wikis in SharePoint, we needed to be using them ourselves.

We also launched a second wiki for managing HotDocs and our HotDocs templates. The vision for this wiki was to create the manual for each of the HotDocs templates and to share information among the HotDocs developers. The wiki page becomes the item returned on a search for the HotDocs template.

We found one great feature of wikis in SharePoint is their ability to combine structured and unstructured information on the wiki page. At the bottom of the image above you see the words “Template In Production.” I had created a new column/field in the wiki page library called “Template.” In the Template column I allowed for the choices of “In Production”, “Under Development” and “N/A.” You can edit the field right from the wiki page.

By adding the structured content we can also create views of the wiki page library to expose content, rather than having to rely solely on links in the wiki pages. In the image below, the sections labeled “HotDocs Templates”, “HotDocs Templates Under Development” and “HotDocs Wiki Recent Edits” are all separate views of the wiki pages library.

With my use of wikis and the adoption of wikis at The Firm, I have been focusing a lot of attention on the behaviors towards documents. After all, a wiki page is just another type of document. When producing documents, I have noted five types of behaviors: collaborative, accretive, iterative, competitive and adversarial.

Collaborative
With collaborative behavior, there are multiple authors each with free reign to add content and edit existing content in a document, and they do so.

Accretive
With accretive behavior, authors add content, but rarely edit or update the existing content. Accretive behavior is seen more often in email than documents. Each response is added on top of the existing string of information with no one synthesizing the information in a coherent manner. I have seen this in wikis as well where people will add content but not edit others content.

Iterative
With iterative behavior, existing content is copied to a new document. The document stands on its own as a separate instance of content. The accretive behavior is distinguished from the iterative behavior by the grouping of similar content together. With accretive behavior the content is being added to the same document, effectively editing the document. With iterative behavior, the person creates a new document rather than adding to an existing document.

Competitive
With competitive document behavior, there is a single author who seeks comments and edits to the document as a way to improve the content. However, interim drafts and thoughts are kept from the commenters. The transmission of the content to a client or a more senior person inside the firm will result in a competitive behavior.

Adversarial
Adversarial behavior is where the authors are actually competing for changes to the content for their own benefit. Although there may be a common goal, the parties may be seeking different paths to that goal or even have different definitions of the goal.

Collaborative, accretive and iterative content production are largely internal behaviors. Competitive and adversarial are largely external document behaviors. Of course, a document may end up with any or all of these behaviors during its lifecycle.

I have an article coming out in KM Legal and Inside Knowledge magazine that further discusses these behaviors in more detail and in the larger context of wikis and document management systems.

I am sitting in on a webinar from PBwiki on using wikis for project management. Chris Yeh ran the presentation. (Of course it was focused on using the features of PBwiki for project management.)

One feature that I like about PBwiki is that it is easy to create a template. Just tag any wiki page as a “template.” When you create a new wiki page, the splash page allows you to pick a template. Any page that you tagged as a “template” shows up on that list.

Chris showed us a Projects Tracker page with a summary of the few projects and their status. From this Tracker page, there are links to each individual project.

Each individual project page, started with an overview of the project, the objectives of the project, the team members, the timeline and the tasks and milestones.

Obviously using a wiki means the information is not in a structured format. So you cannot create dependencies and all the fancy stuff that something like Microsoft Project does. (Of course I have been trying to use Project for years but it is frustratingly hard to learn and use. I have found a wiki page to be so easy to use, that it is easy to get people trained [2 minutes] and using the wiki page.)

It sounds like PBwiki is looking for ways to structure some data to allow it to roll-up into other places in the wiki. (SharePoint 2007 has some interesting abilities to deal with this. I will post on this later.) In the wiki, you need to double enter information on the project page and on the master page. If you design which data goes where, you can minimize the double entry.

With a wiki, you give a common space for the project team to keep information and share information on the project. As items on the project are updated, the subscribers to the wikis get the notification of the change. (We have been using PBwiki to manage our knowledge management projects for almost year. A wiki is a great way to centralize information and publicize information at the same time.)

The webinar large ran through the features of PBwiki and lots of requests for functionality in the wiki. Since I have several active PBwikis and am familiar with many of the features so I got a little bored.

One challenge with a wiki is the lack of structured content. I have found that the more structured content you have, you more complicated you make the tool. My IT development manager and I always butt heads over whether to use a structured data or unstructured. Since I am an attorney, I am used to the unstructured content of document contents. He is from IT and is used to databases.

The key to using a wiki for project management is making sure everyone on the project team has an RSS feedreader. (Even better get an enterprise RSS feedreader and push out a subscription.) The wiki compresses the updating of information and the distribution of the updated information into one step. You edit the wiki page and the wiki page sends out a notification.

I have been using a wiki to run a client team for a few months. Each matter has a separate wiki page. On that page is a list of the needed diligence information and list of the closing documents and their status. I keep my notes on the page as does my junior associate and paralegal. I can go to the wiki page and see the current status. I would have gotten RSS notification of changes to the items. The old method was keeping the list of diligence information and closing documents in a word document in the document management system. The responsible person would edit the word document and then email it around to the working group. I would have to open the email and open the word document to see the changes. If the document was redlined to show changes, then I need to decipher the mess of edits to see the current status. If the document was not redlined, I would have to try to distinguish the changes.

As we are working on deploying wikis and blogs inside The Firm, we have been working on ways to explain these tools. Most of the lawyers have heard the terms, but are not familiar with the tools.

One question that arises in the difference between a blog and a wiki. The distinction between the two becomes less clear inside the enterprise.

Mark Miller at endusersharepoint.com put it beautifully when he said:

Blogs are great when one person is trying to communicate to a team or group. Think of a blog as pushing out information from a single source to anyone who is willing to listen, “one-to-many”. The listener has the ability to participate in the communication through comments, but the main direction of the message is controlled by the person writing the blog posts. . .

By the very nature of wikis, many people will be adding content and that content can be consumed by any number of readers, “many-to-many”. At first, it seems like a free-for-all, but in an intranet situation, it is extremely useful for letting content experts participate by contributing in their area of expertise. In general, someone sets the basic beginning structure of the wiki by creating a table of contents and some starter pages. From there, user generated content drives the expansion of the wiki, based upon the needs of the participating audience.

Simple test: one or two people providing content, use a blog; many people providing content, use a wiki.

Over at the Wikinomics, the Blog, Anthony Williams published this picture of the process comparing email collaboration versus wiki collaboration: Wiki collaboration leads to happiness.

One point of contention was whether the faces on the email said should be happy faces or frowning faces. Anthony goes on to say in Wiki collaboration leads to happiness:

“Are occupational spammers blissfully overflowing your email inbox with overweight word documents and seemingly ignorant of the rising tide of wiki enlightenment that is bestowing happiness on a growing legion of devout followers? Or, are emailers painfully self-aware of the tragic cycle of email misery that obscures their path to wiki salvation?”

There is a huge buzz around the launch of Google Sites. This is apparently what Google decided to do with its acquisition of the wiki company JotSpot.

I found it curious that Google has erased an mention of the word wiki in Google Sites. Stewart Mader also picked up on the omission of that four letter word: The nasty four-letter word that must be banished from the web. It looks like a wiki and acts like a wiki why not use the term. Editable webpage is not very descriptive.

I found it problematic that Google packaged it into their Google Apps rather than as a more free standing application. I have my issues with the Google Apps. I like using Google Docs, but have a hard time navigating around the rest of Google Apps. I can get a PBwiki set up in seconds. Google Apps does not match that speed.

Dennis Howlett complains about the usability issues.

Ross Mayfield notes that Google is targeting Sharepoint and Lotus Notes.

Judi Sohn of Web Worker Daily gives a quick overview of its features.

Lee Rosen, the president of Rosen Law Firm, took a few minutes to talk with me about his firm’s experience with wikis.

Rosen is replacing his Lotus Notes platform with an externally hosted wiki from PBWiki. You may have read about the cash prize contest he ran for his employees in a story on CNN.com: Boosting Teamwork with Wikis. He offered up the chance to win a cash prize for contributing to the wiki. The more you contributed, the better your chance of winning.

Lee was drawn to the concept of using a wiki because of its purported simplicity. He found it much easier to develop and add content. Setting up the wiki was quick. The firm started with the free version of PBWiki and had their wiki up and running in minutes. Some of his administrators worked with the wiki for a few months to see its functionality and how it might work within the firm. Then others in the firm started asking to join and it took off.

Over the last year, his firm has created three to four thousand pages in the wiki. Lee estimates that 60% of his employees make at least one change to the wiki each day.

Lee really likes the flexibility of the wiki platform. People can work in the wiki the way that they want to work. Of course, that has lead to some disagreements over the way to organize content. The upside to the disagreement is that people are working together to add content and organize it. They would not bothering disagreeing if they did not care about the content.

Lee sees a conflict between the need for rules and the freedom to contribute. There are places where the wiki is not organized in a way that works for him. But it does work for others.

There is a great deal of latitude on what people can do with the wiki at Rosen Law Firm. Many have created a personal page where they update information about themselves. This social component has been well-received and keeps people engaged in using the wiki.

Lee also likes that the wiki is externally hosted. He lets PBwiki worry about keeping the server up and all the “plumbing” headaches. He wants to be out of the IT business. That benefit was a little offset by the long term viability of wiki providers. It’s great the PBwiki does not charge much for their product. But what is their long term plan? His firm’s thousands of pages of content get dragged along with their long term plan.

One of his biggest issues is keeping the wiki in people’s minds as a way to communicate. It takes some time for people to realize that they can communicate through the wiki. Lee still sees lots of email communication that could be better handled in the wiki. They are also still transitioning some of the content from Lotus Notes into the wiki.

Lee also drives people to the wiki by only publishing some information in the wiki. For example, monthly reports like time billed are only published on the wiki. Lee uses the wiki to host his video training. The wiki replaces weird URLs and DVDs. With PBwiki, the video can display right in the wiki page.

It looks like the PBWiki has been a tremendous success for Lee Rosen and Rosen Law Firm. That is a lot of content and a lot communication happening inside the wiki.

It gets me excited for the up-coming launch of our wiki platform. I am acting like a nine-year old on the day before Christmas waiting for the launch.

Tom Davenport seems to have found some middle ground with Andy McAfee in their battle over Enterprise 2.0: Enterprise 2.0: The New, New Knowledge Management?

“But when Andy said the ultimate value of E2.0 initiatives consists of
greater responsiveness, better “knowledge capture and sharing,” and more
effective “collective intelligence,” there wasn’t much doubt. When he talked
about the need for a willingness to share and a helpful attitude, I
remembered all the times over the past 15 years I’d heard that about KM. . . . Sure, there are a few differences between classical KM and E2.0. The tools are largely different, for one.”

I touched on this in my Law Firm Knowledge Management 2.0 post and the ensuing series of Law Firm Knowledge Management 2.0 posts:

• Summary
• Wikis will be a great way to synthesize knowledge
• Blogs will be a great way to make announcements and summarize meetings
• Email needs to be incorporated
• Document management systems can host
• RSS is there to spread the word
• Search to find all of the good stuff