Supply and demand 2.0

A primary reason why I've started an external blog is to share and elicit insights about how organizations are using social software to improve the way they work. I do that by telling stories with morals.

I was talking the other day with the head of a Research department in a Fortune 100 company. His group had created a wiki which had gotten a little usage early on, but quickly turned into a dumping ground for a lot of traditional, published reports which were already being written. Somewhat useful, but not user-friendly, not collaborative, and not generating new insights or connections between people.

The wiki became a dumping ground because it was driven by supply. When the wiki was set up, researchers were told "Here's a wiki, put your research into it." That's what they did, but it didn't have the desired outcome.

The Web 2.0 orthodoxy might lead you to believe that a nebulous entity, "the Community", magically organizes content once it shows up in a wiki. But that rarely happens. Emergent structure happens only when individuals spend time doing the organizing. Most enterprise wikis, especially new ones like the Research wiki I described, lack the critical mass of participation required for that emergent organizing to take place.

The way out of the dumping ground problem is to position wikis as being demand-led rather than supply-led. The way to do that is to structure or "stub" a wiki in advance--before you invite others to join the wiki. Here's a simple four-step process:

1. Get a small group of core community members to whiteboard a high-level information architecture in the form of a few categories (not more than 4-8) and subcategories (not more than 1-2 levels deep)

2. Create a series of blank pages or "stubs" hyperlinked  to reflect the category structure

3. Assign each category to an individual member of the group to flesh out

4. Reconvene in 1-2 weeks to review what everyone has done, share learnings, and revise the category structure

Once those steps have been followed, you'll have a structured wiki which people will want to read. You'll have a core group of champions personally committed to the wiki's success. And you'll have a structure that encourages organized, thoughtful participation in line with the wiki's strategic business objectives.

Comments

['son]

Michael, this is a great idea. You know, I'm struggling with this at work, myself. I've been tasked to give a training/evangelization session on our corporate wiki. We have low participation on the wiki, and most of it is driven by a few crazies like me. What I find myself doing most often is organizing, not authoring. I almost have no time to author new content since I'm busy making other people's contributions readable. It's strange that I never thought to try the stub route. That has worked well on Wikipedia. Actually, my co-enthusiast at work has started to do this. He set up the sales department's wiki space. He created page template and some general page hierarchies.

I definitely think that putting effort into organizing a wiki page is useful. I still haven't decided if having a hierarchical page structure is a good idea. I think that more experience will help me form a better opinion of this.

Again, kudos for bringing forth this idea. Wikis are still very emergent in the business world. Tips like these will help us evangelists convince the non-believers.

[Michael Idinopulos]

Thanks for the comment. A little structure in a wiki is not a bad thing. My only caution is that you don't want to go overboard on structure. We've all been on overstructured websites where the real content was 5 or 6 clicks away, or where there are dozens of blank pages. Remember, the structure you impose is just scaffolding.