One of the best tools for teamwork to come out of web 2.0 has been the venerable wiki. Few things speak more to staying in the flow of one’s work than just clicking Edit This Page where you see something that needs to be written or re-written. While a wiki can let project documentation grow organically as a project unfolds, it is like any tool and needs to be used the right way to get the most out of it.
If you’re thinking about adding a wiki to your team’s toolkit for the first time, keep a few points in mind to help them get up and running without tripping over the changes that the wiki way brings to project documentation.
The first thing to do is check in with your team as a culture shift may be needed to make a wiki work for your project. Explaining how wikis work is important, but so is making sure people know what the wiki is for and that they have permission to write and re-write as needed. Where documentation has previously been done in a different way (or not at all), there can be a hesitancy to participate without a clear green light to do so.
Prime the content. Seeding the wiki with some starter pages and some headings to suggest a structure for those pages can be a big help to people not used to looking at a fresh blank page and diving right in. Giving your team some hooks to start hanging their thoughts on will not only speed up the population of those starter pages, but will encourage new pages to be created with a consistent structure.
As the team gets under way in making the wiki part of their process, you can use the wiki itself as a point of review for how the change is working out. A great step is to add a page specifically for capturing feedback and ideas for making the wiki fit your project’s needs. Not only will you be able to capture important feedback in an open and collaborative way, the use of a review page itself helps build the value of the wiki as a source of shared truth not only for project details but for how you and your team work.
When the team is moving into a wiki, they’re likely moving out of another tool that has previously been used to organize some or all of the knowledge about a project. It’s human nature for people to fall back on old habits while trying to form new ones, so they’ll need a wiki champion who can diplomatically redirect content into the wiki. Email is most often the channel that the wiki-wary fall back on during this kind of transition, and the most dangerous for locking knowledge into a recipient list. It’s crucial in the adoption phase to insist that errant emails are channeled into the wiki before they can be acted on in order to get long term and effective buy in from team members.
We’ve been talking about using wikis internally on development projects so far, but there’s also a compelling use for them in the right kinds of user communities. If your customers are comfortable with web 2.0 technologies, adding a community wiki adequately seeded with starter content provides a way for them to help each other. They can round out documentation with their own insights, tips and tricks to showcase everything your product is capable of, honestly and from the real source of truth: customer happiness.
A final note on wikis addresses something that is often seen as a deficiency but can really be a strength. Nearly all wikis dispense with advanced page and text formatting, instead embracing a ‘just the facts’ approach to documentation. Removing the ability to spend time formatting content removes the feeling that the content needs more than basic formatting. Where people aren’t spending time on formatting they’re likely to spend it on just writing and moving on.
The best tools often don’t deliver their benefits in one giant step, but in the savings made across many small steps from day to day. Wikis are definitely in that category, and while getting team members to embrace a change can be hard, the results will almost certainly speak for themselves when it’s time to look back and weigh the benefits of the wiki way.
