How to Use A Wiki For Requirements Gathering

A Wiki Is More Than Just A Dictionary

One of the great tools that came out of the agile software development movement of the 1990s was the wiki. There's no need to go into a long explanation of what a wiki is; by now–thanks to Wikipedia–everyone knows what it is and how it works. What surprises me though, is how rare I find them on data projects. When I first started using wikis to help companies organize requirements, it made a dramatic difference in the quality of the solution and its fidelity with what the users ultimately needed and wanted. If you're smart, you'll follow my lead. Here's how it's done.

How to Collect a Great Set of Requirements With a Wiki

The hardest part of making a wiki work is getting end users to use it. Although most people are familiar with reading wikis, a lot less people who are familiar with authoring on a wiki. Learning to contribute to a wiki is a quick, simple, and painless process; however, if your users don't get a "push," they won't do it. So, the first thing you should do is give them a hands-on experience of the basics: creating bold text, creating bulleted lists, creating links, and creating their own basic pages. This is best done as a group exercise that can be a lot of fun. After you get your wiki setup the way you want it, bring all the end users together for a quick tour, and walk them through a few exercises including the creation of their own wiki profile page. Then it’s off to getting the real work done.

Encourage free discussion on your wiki pages, but reserve sections that should only be touched by you. Think about the requirements gathering process as: collect, discuss, organize/summarize, and publish (with approval). Collecting and discussing should be free form and open to anyone. You want as much collective thought going into this part of the process as possible. The collection and discussion part of the wiki should be organized in conversation threads, avoiding changes and deletes.

At the top of a conversation should be where you organize and summarize the discussion. Establish a best practice where you're the only one that can edit this section, with only minor exceptions. Then, you should have a completely separate section of the wiki where the requirements are approved and published. Although approvals can be recorded here, you are the only one that's allowed to create or modify the text that goes here. This prevents rogue end users from doctoring published requirements.

Finally, be proactive in encouraging behavior to use the wiki. Don't stop at the hands on exercise. Gracefully force end users to use the wiki. It's not that hard. It just takes some getting used to. Business analysts eager to make it work will sometimes document requirements in the wiki for their end users. If you do this, you're ignoring the bulk of the value in using a wiki over just a Word document.

An effective technique is to use email to bring their attention to the wiki until the end users build habits for checking the wiki on a regular basis. Even when you have good engagement on your wiki, it's still a good idea to use email–and even instant messaging–to direct people to the wiki for contributions.

Conclusion

When the wiki was introduced in the 1990s, I thought everyone would jump on board. What a great idea to have a simple platform where end users could self-publish their feedback and ideas. Well, the self-publishing idea really took hold with the social media frenzy, but for some reason self-publishing never made its way into the corporate world where collaborating on requirements is such a valuable capability. The wiki is a great tool for building great collaboration capability and I urge you to consider it for your next project. And here's a side benefit for you: if users are writing their own requirements–or at least starting the process–that's one less thing for you to do!