Share
Home > Product Management > Project Management with a Wiki

Project Management with a Wiki

A wiki can be a great tool for basic project management for product managers. While I typically recommend that product managers focus their time on product ideation and defintion, a certain amount of basic project management and coordination is often necessary to bring products to life. This is particularly necessary in a smaller company which may not have dedicated project management resources.

The value of a wiki is that it is an easily-editable webpage. It's a collaboration tool: multiple people working on a project can edit the page to share information and keep in sync. A colleague who is intersted in a particular topic can bookmark that webpage and return to it often for status updates. It's much more centralized and public than sending around an Excel file, which becomes out of date once you make a local edit to it.

How do you get a wiki up and running in your organization? You can get a free wiki in minutes through various online services such as PBwiki or Central Desktop. Or you can host your own via Twiki which should be fairly straightforward for your IT manager to implement for you.

In general, all my project management wiki pages have a similar format: each page is structured as a table with a list of tasks. The columns of the table are usually some subset of the following:
  1. Priority: I typically use a three-tier prioritization system based on my understanding of how important a particular task is:
    1. 1-High
    2. 2-Medium
    3. 3-Low
    Why the numbers in front? That way when I sort the table by that column, the items will sort numerically so that I can review the items in order of priority from most to least important.
  2. Task: A few keywords describing the action item
  3. Detail: Any specific information that's relevant to the task owner, if it's not immediately obvious from the previous column
  4. Dependencies: Where appropriate, any other tasks this task depends on
  5. Due Date: When should the task be complete? Note that sometimes it's not possible to enter a specific date due to dependencies. While a fixed date is always valuable, sometimes I have to put in fuzzy dates, like "anytime in the week after the release" or "before coding begins."
  6. Owner: Who is accountable for this task
  7. Status: Like with priority, there is no need to get extremely elaborate here. The three statuses I use are:
    1. 1-Not yet begun: Sometimes abbreviated as 1-NYB
    2. 2-In progress: Sometimes abbreviated as 2-IP
    3. 3-Done: My favorite status of all!
    Again, the numbers in front allow me to sort the table by Status so that all the outstanding projects bubble up to the top of the table.
I usually create the table from a simple template I have which is pre-formatted with wiki markup. (Wiki markup is very similar to HTML but even simpler. If you're familiar with HTML, you'll pick up wiki markup in minutes. The good thing is that, even if you're not extremely familiar with HTML, most wiki templates have the key markup items in the footer of each page, for reference.)

Of course, once the wiki page is created, it's important to keep it updated. Having a quick daily or weekly status meeting (depending on the project) to go through the wiki page is useful for making sure projects get done. You don't even need to create an agenda - the wiki page, with its list of action items, is your agenda!

Below is a list of some sample projects I've managed via my company's wiki:
  • PRDs by Release: For any upcoming release, we keep a table of all the PRDs or key enhancements that will be part of that release. For me as a product manager, it's the easiest way for me to answer anyone's question about when a feature will be developed or what's in the next release.
  • Release Tasks: For any upcoming release, we keep track of any specific tasks related to the release on the wiki. We assign each task to someone in Engineering, QA, Operations, or Product Management.
  • Feature-Specific Tasks: For some complicated features with many moving parts and dependencies, the wiki provides a way of keeping track of all the pieces and making sure nothing falls through the cracks.
  • Global Tasks: For some features that involve my colleagues in far-flung locations, whom I don't see in the office every day, the wiki is an easy way for us to keep in sync even when there's only an hour or two a day when we're both in the office at the same time.