Making Wikis Work - Success Factors

I have been using wikis at the firm for the past few months. Here are three case studies that I hope will shed some light on factors that help wikis work or help them to fail within the enterprise. Since we are still working on our deployment of Sharepoint 2007 and its wiki capability, I decided to host these three wikis with an external provider (PBwiki.com).

Client Team Site.

For one of my client teams, I had started a practices and procedures memo. Initially, I converted the practice and procedures memo into pages on the wiki site. Then I decided to create a wiki page for each transaction. The transaction page consisted of notes, a status chart for diligence items and a status chart for the loan documents. The idea was for the team to be aware of changes and updates to the client relationship and each transaction. I was tired of getting so many emails.

The client team site was imposed by me, as the team leader, by fiat. The wiki is how I want to distribute changes to the practices and keep up to date on the status of each transaction.

The team is coming along, but coming along slowly. Mostly because nobody else is interested in learning this new way of sharing and communicating information. This will be a success, eventually. Mainly because of my ability to impose my will on the team.

Practices and Procedures Memo.

I stumbled upon a practices and procedures memo for another client that I am supporting on the knowledge management front. The memo was a lengthy MS Word document that had lots of information and cross references back and forth throughout the memo. It thought it would be a great fit for a wiki. What sold the idea of using a wiki was a question from one of the team members: "How do I know when the procedures change or the memo is updated?" A wiki's RSS feed would do that.

There are links to key documents in our document management system (the links only work if you access the wiki from inside our firewall.) There are 32 pages in the wikis, so there is a lot of content. But the content was easy; we just pasted sections of the memo from MS Word into the wiki, adding the cross references and links to the document management system.

Edits to the wiki are few and far between. This is particularly problematic because the procedures memo was out of date when it was transformed into the wiki. This was a dark omen that I ignored. I hoped the wiki technology would remove whatever barrier existed that inhibited people from updating the procedures memo. A classic example of needing the business process and group motivation, more than the technology.


Project Team.

The third wiki was the site for our knowledge management department. Another member of the department and I thought it would be a good way to share information and updates. Too much information was being scattered about by emails.

As of today, we have 58 pages in the project team wiki site. There are several edits each day in the wiki pages. That alone indicates success.

We passed a key success milestone last week when we had our first discussion on governance of the wiki. Once you have enough content then people start focusing on how the wiki is organized and how particular pages are organized.

This site worked because two of us decided to use it as a medium to capture and share information with each other. Once we decided it worked for us, we asked the whole team to join and got the director to go along with this idea. The sales pitch was that wikis were coming into the firm as part of SharePoint 2007, so we better learn how the work and how they don't work.

One of the key factors was getting the agenda for the team's weekly meeting into the wiki and maintained in the wiki. This created better collaboration, because it was easy for team members to add items to the discussion.

Success Factors.

In looking at these three case studies, I see three critical factors.

First, there needs to be a reason to go to the wiki site. The information needs to be better organized, more functional and more findability than the existing methods of sharing the information.

Second, you need more than one person to be dedicated to using it as the communication/collaboration tool. Neither person need be top level management. The important factor is a group willing to share information. Management will come around.

The third critical factor is avoiding the empty wiki syndrome. The wiki has to have better information than any other location. An empty wiki is like an empty nightclub. If nobody else is there, you begin to think that maybe you should not be there either. There needs to be compelling reason to stay, look around and interact with other people.