I am sitting in on a webinar from PBwiki on using wikis for project management. Chris Yeh ran the presentation. (Of course it was focused on using the features of PBwiki for project management.)
One feature that I like about PBwiki is that it is easy to create a template. Just tag any wiki page as a "template." When you create a new wiki page, the splash page allows you to pick a template. Any page that you tagged as a "template" shows up on that list.
Chris showed us a Projects Tracker page with a summary of the few projects and their status. From this Tracker page, there are links to each individual project.
Each individual project page, started with an overview of the project, the objectives of the project, the team members, the timeline and the tasks and milestones.
Obviously using a wiki means the information is not in a structured format. So you cannot create dependencies and all the fancy stuff that something like Microsoft Project does. (Of course I have been trying to use Project for years but it is frustratingly hard to learn and use. I have found a wiki page to be so easy to use, that it is easy to get people trained [2 minutes] and using the wiki page.)
It sounds like PBwiki is looking for ways to structure some data to allow it to roll-up into other places in the wiki. (SharePoint 2007 has some interesting abilities to deal with this. I will post on this later.) In the wiki, you need to double enter information on the project page and on the master page. If you design which data goes where, you can minimize the double entry.
With a wiki, you give a common space for the project team to keep information and share information on the project. As items on the project are updated, the subscribers to the wikis get the notification of the change. (We have been using PBwiki to manage our knowledge management projects for almost year. A wiki is a great way to centralize information and publicize information at the same time.)
The webinar large ran through the features of PBwiki and lots of requests for functionality in the wiki. Since I have several active PBwikis and am familiar with many of the features so I got a little bored.
One challenge with a wiki is the lack of structured content. I have found that the more structured content you have, you more complicated you make the tool. My IT development manager and I always butt heads over whether to use a structured data or unstructured. Since I am an attorney, I am used to the unstructured content of document contents. He is from IT and is used to databases.
The key to using a wiki for project management is making sure everyone on the project team has an RSS feedreader. (Even better get an enterprise RSS feedreader and push out a subscription.) The wiki compresses the updating of information and the distribution of the updated information into one step. You edit the wiki page and the wiki page sends out a notification.
I have been using a wiki to run a client team for a few months. Each matter has a separate wiki page. On that page is a list of the needed diligence information and list of the closing documents and their status. I keep my notes on the page as does my junior associate and paralegal. I can go to the wiki page and see the current status. I would have gotten RSS notification of changes to the items. The old method was keeping the list of diligence information and closing documents in a word document in the document management system. The responsible person would edit the word document and then email it around to the working group. I would have to open the email and open the word document to see the changes. If the document was redlined to show changes, then I need to decipher the mess of edits to see the current status. If the document was not redlined, I would have to try to distinguish the changes.