Using wikis to capture project information

August 26th, 2009  |  Published in project-management  |  2 Comments

A few months ago I read 97 Things Every Project Manager Should Know and one point that really stood out for me was Adrian Wible’s recommendation to use a wiki for maintaining project information.  There are a number of positive aspects of using a wiki, but Wible doesn’t even allude to the many downsides:  page sprawl, the difficulty in finding information, and keeping it all up to date, which I feel outweigh the positive benefits.

At VMware we’ve had wikis for engineering teams to post project information for a number of years now but it’s become more of a dumping ground than a useful reference.  In the last few years our use of the wiki has exploded, but engineers are busy so they tend to “fire and forget”: content gets posted but no one bothers to go back and update it.  And because wikis set the bar extremely low, people just throw in content without thinking about findability or how to properly take advantage of hypermedia.

The result is that it’s extremely difficult to find the page or content you’re looking for.  Our Google Search Appliance doesn’t even help because there aren’t enough quality links for the PageRank algorithm to produce useful results (that’s my guess anyway).  So instead of finding a page with details on how our virtual machine monitor works, you’re more likely to get a page full of daily status log entries.

Perhaps the best solution is to do what Wikipedia does: establish standards for content, linking, and organizing the information (it also helps to have a volunteer army of curators/librarians to maintain it).  Of course, this is easier said than done.  Companies like VMware make money by shipping products, not pruning wiki pages, so it’s difficult to sell the idea of having all employees act as part-time curators unless you can quantify the ROI. Sadly, I don’t have an answer for that (yet).  Some inexpensive alternatives that come to mind are to hire a librarian to prune and organize or to have the company’s Intranet team help establish the best practices — assuming they’re good with information architecture and not just throwing up Web pages).

While all of these options focus on primarily Web content, the overall problem of capturing organizational knowledge is much larger.  Hopefully more on this soon…

Tags: , ,


  1. Adrian Wible says:

    February 10th, 2010 at 6:11 pm (#)

    Hey Kyle. Yes, you’re right – wiki’s can become stale, unwieldy, disorganized, and worse – untrustworthy.

    As this article in the book was focused on PM things, the wiki idea was to provide a more shared responsibility to update relevant content, rather than requiring the PM to collect and distribute any/all information.

    As a PM, I have taken responsibility on my projects for managing wiki organization so that it’s useful. So the PM is the curator… the team members are the contributors. It requires some work on the PM’s part – particularly in the early going, as wiki organization can morph drastically with the initial content. Once it’s organized though, and understood, folks get the hang of where to put particular content.

    It’s like moving into a new house and organizing your garage. If you don’t provide some structure of where things go at the beginning, then you’re out of luck. But the effort at the beginning to establish order can make for a garage that requires only cursory maintenance over time. (Put up a peg-board !)

    I don’t think it requires a librarian. Certainly, if you have significant documentation requirements that require a tech-writer, this sort of thing is right up their alley and can potentially be tacked on.

    Thanks for the thought-provoking post.

  2. kyle says:

    February 10th, 2010 at 7:05 pm (#)

    And thank you for the comment, Adrian. Having the PM take on that responsibility is a nice idea.

    In VMware’s case, there are few to no project managers in the company (at least in R&D). It tends to be yet another hat for engineering managers to wear when they have a spare minute, so a responsibility like curating the wiki is treated as extremely low priority (read: it never gets done).

    The idea behind the librarian was to establish at least one person for multiple teams to rely on for helping them organize and keep their information up to date. I agree that it could be overkill for many organizations where others are able to dedicate adequate time to the task.