7 Effective Wiki Uses and the Companies That Benefit From Them

In Chapter 2 of Wikipatterns, I outline the key ways that a collaboration platform inside your organization differs from open platforms on the web, and review ways to use a wiki, including project management, product development, knowledge base, event planning, intranet, meeting management, blogging, and external collaboration. No matter how you plan to use the tool, though, the most important factor in success is employee buy-in. In CIO magazine, Thomas Wailgum writes:

CIOs really need to listen to their business users and peers, especially when it comes to knowledge-worker productivity issues… they shouldn’t just try to force a generic solution (“Here’s your BlackBerry,” or “Take this laptop”) out to business users before sitting down and listening to them. In many cases, a user won’t know what the solution is, but by being able to explain the problem to IT, a joint, appropriate solution can be discovered. That thinking will ultimately enable more productivity for the user and offer a greater chance of ROI for the technology.

When organizations decide to centrally support new productivity and collaboration tools, they increasingly find that they already have local instances of these tools scattered throughout groups, teams, and departments. The tools were brought into organizations under the radar by people that saw the value in using them, and began a grassroots movement to spread awareness and use among peers. This is not the usual way to bring a tool into an organization, because it often leaves IT out of the process until the use of the tool is already underway, but it’s happening this way because people are choosing what works best for them, and resisting the idea that they have to use the one tool that’s prescribed as a “one size fits all” solution.

Chris Anderson wrote about this phenomenon in The black wire and the white wire. He describes the two network cables on his desk – one installed by central IT and the other a standard DSL connection with no firewall, and no ports blocked for things like Skype and Second Life:

These two cables are a handy metaphor for the two worlds of corporate computing: end users and the IT department. The chasm between them has never been greater, in part because the tools available on the wide open web have never been better.

This is what creates the conflict between users and IT – and it’s not all IT’s fault either. Historically, IT’s job is to “keep the lights on” – make a set of core technology tools available to people and support them – which was fine ten, even five, years ago, but just doesn’t work the same today. The quality of tools on the web is increasing far faster than most “boxed” enterprise software, and those web tools are free or low cost, and available immediately, as opposed to going through a much more involved procedure to get access to tools on the inside, or convince IT to make them available.

Hence my two cables–in a sense, my computing ego and id. Scratch most companies and their employees and you’ll find the same. So why not build IT infrastructure that reflects the reality that one size doesn’t fit all? To encourage experimentation at the edge while protecting operations in the core, two networks work better than one.

This is the philosophy organizations need to embrace going forward – one size doesn’t fit all, and a better way is to maintain – in the black cable sense – those tools that are highly specialized or tied to legal/government regulation. This frees both IT and employees to try – in the white cable sense – a variety of tools to find what works best for them and what they’re intrinsically motivated to use.

Organizations that embrace this approach include major enterprises like IBM and SAP, and smaller firms like Red Ant. IBM DeveloperWorks Wikis cover topics like: J2EE Systems Management, Lotus Quickr Best Practices, and WebSphere Instructor Wiki. On the SAP Developer Network Wiki the, “main criteria for choosing to put content in the wiki is its volatility and dynamics, extendability and/or collaborative character. Ask yourself the question, if you want others to be able to change, extend, regroup, add, etc. your contribution.” That’s an excellent question to ask, especially for content that’s going on a public wiki. Red Ant, a Sydney, Australia based web design and development firm, uses a wiki as the main collaboration hub for employees and customers. I asked Ben Still, managing director, how they use wikis:

Say, for instance, we’ve created a design and need to show it to our client. First, a designer makes a page, attaches an image, and they’re done with their part. But then I might look at it and realize that it needs a bit more explanation, or a link to a wireframe diagram to give context. One of our developers might have also mocked up how a menu works, and so they stick in a link to that. Our client might email the link around, and then add some comments on the page. This kind of collaborative workflow is one of our strengths, and it is really important for us to be able to add these various types of content easily.