The Empty Wiki Problem
For the last year or so, I’ve been telling everyone I meet about the Empty Wiki Problem. But getting the story into this post has been a real challenge. If you can see what I’m driving at, and can think of a way to improve the story, please, let me know!
The Empty Wiki Problem
So you finally won the Enterprise 2.0 argument. You did your homework. You created beautiful ROI charts. You convinced the powers-that-be to move forward with a collaboration solution. You’ve purchased the hardware and the software. You had consultants analyze your business and configure the system. You brought in technical experts to migrate data. You hired a team of trainers demonstrate the new tools. You launched an internal marketing campaign. The solution went live with great anticipation and much fanfare.
But there’s one guy over in the corner, shaking his head. He’s the cynic. He says, y’know, we saw this with the content management system we rolled out last time. And the portal we set up before that. And the intranet we tried before that. You can detect the hint of a smirk on the cynic’s face as he tells you that it won’t work this time either.
And once the excitement and buzz start to wear off, your tiny inner voice starts asking whether the cynic might be right. But after all this time, effort, and expense to implement a state-of-the-art Enterprise 2.0 solution, isn’t the project a success? Aren’t we done yet?
No. Your business is never done. And that’s when you start to realize that you’ve still got a problem.
Almost as soon as the consultants pack up their laptops and the dust settles, the content in your new, shiny E2.0 solution starts to get stale. People get caught up in their inboxes again and forget to post things to the server. Meeting agendas, dutifully posted in the first few weeks after launch, never get paired with the meeting minutes, lost in the shuffle of getting things done. The first half of an email thread gets cataloged, but somehow, the second half — the part with the final decision — never makes it in to the repository. The searches on the portal become less relevant. As the results become less useful, people stop visiting. People stop remembering to update and post new material. Slowly but surely, everyone starts relying on the ol’ standbys to get things done.
And the cynic nods as if to say, I told you so.
What went wrong?
The short answer is that the new system wasn’t adopted.
But what caused people to reject the solution? And why were so many other collaboration and information sharing tools similarly rejected?
I don’t believe it’s our hypothetical organization’s fault. It’s not that the culture is biased against sharing. As Jack Vinson reminded us in a recent blog post, we shouldn’t confuse a refusal to use a KM Tool with a refusal to share knowledge. Most people love to talk. It’s hard to get them to stop talking. And the whole point of an organization is to get people together to work on a shared goal. The purpose of business is to harness collaborative effort.
So let’s not blame the victim here; organizations don’t reject these solutions because the organizations themselves are fundamentally flawed. There must be something fundamental, something subtle in the way that these people interacted — or failed to interact — with these tools that was the problem.
Value out, value in
I think most solutions don’t cross the threshold of sustainability for one reason: The value that individuals get out of them doesn’t outweigh the effort to put things into them.
If too many folks decide it’s too much trouble to upload stuff to the server, the solution will fail. If enough people decide that filling out metadata profile forms is a waste of time, the solution will fail. If too many employees decide that the reports or search results don’t meet their needs, they won’t maintain the system, and the solution will fail.
The adoption pattern of these systems is a classic tipping point problem. Each user draws their own conclusions about the usefulness of the system. Getting user adoption is a matter of reaching critical mass. If you can get critical mass, the usage of the system will explode. If you don’t get critical mass, nothing happens. The solution will languish and fade. With collaborative software, you typically see either runaway successes or dismal failures.
So if we want to defeat the Empty Wiki Problem, we can either decrease the individual effort needed to maintain the system, increase the value that each user gets from the system, or — ideally — do both things at the same time.
Related Posts
- One System to Rule Them All
- The Second Biggest Mistake of Enterprise 2.0
- Individuals in Groups
- The Slowest Way to Fail
- Graph-based Books
Interesting points, I had this exact same argument with one of our trainers the other day. If its too much effort to for me to place my email in my content management system, I just won’t.
His response was that the end user was not trained properly and if they were they would have no issue putting in the extra (let’s say 10 seconds) in filling out a record entry form.
I countered this with, well I don’t want to spend 15 to 20 seconds each time I save an email and I’ve been trained.
He then insisted that I have to, and that’s just how it is and I needed to stop being difficult.
…. so there is a solution for the empty wiki problem.. Stop being difficult and just do it.
Oh, and look there’s that cynic over in the corner smiling away..
nice post… I’ve meant to do one like this as well, but about neglected and abandoned blogs.
I call them “blorphans.”
@Phil – Dean and I call that the “Eat Your Vegetables!” argument. Just because it is good for you doesn’t mean you will do it… It gets a bit sad when that’s the only argument you have. All Stick, and no Carrot..
Mmmm… Carrots….
[...] from Infovark wrote a very real and truthful story about “the empty wiki problem“. I can really related to everything he said. In a nut shell, Dean discussed a failed Wiki [...]