project management wiki solutions

Today on InfoWorld, Ephraim Schwartz wrote about some of the pros and cons associated with using a wiki for project management. Knowledge management can be a challenge, especially on a project. I find it helpful to find many solutions in potential changes to systems. Historically, wiki implementations have relied too much on trusting human beings to dot their i’s and cross their t’s. Instead, let’s try to set up the system in such a way that the default state is exactly what we want. This reminds me of a comment I left on the Inquries into Alignment blog last week. “Manage the water, with the fish in mind.” – you’ll have to read the blog post for that to make sense!

I find the issue with outdated content a particularly pernicious one, so let me try to address some potential solutions. It seems to me that Wiki software packages need some basic functionality to overcome this.

First,

each new item needs a primary and secondary content owner on the project, with access via LDAP. IT should not be organizing content, the content owners should be responsible for that. Perhaps the project manager, business analyst, or team lead can take on one of these roles. With this in place, it is critical for an administrator to have the ability to re-assign all wiki ownership if an employee vacates a position for any reason. This would also be useful for phasing a project into operations. When that happens, all of the content owners may need to change to someone in operations.

Second,

the wiki items need to have a required field that captures revision frequency. It should be a multiple-choice question with only a few possible answers, although frequency options may vary from industry to industry. Default options might be 1 month, 3 months, and 6 months. This functionality would kick off an email to the content owners at the designated frequency, and if they do not validate the content within 2 weeks, it is taken offline and put into a hidden archive state. It can be re-activated later if necessary from the archive, but content owners who are not keeping on top of their knowledge management duties can be flagged by IT as people who may not be trusted to be content owners in the future. The archive could retain content indefinitely, or it could be purged after a specified period of time….say a year maybe.

With this simple functionality in place, we have a systemmic way to keep content relevant in a wiki. For that matter, this doesn’t have to be limited to a wiki. Any content management system, for project management or otherwise, could potentially employ the same functionality.

{ 8 comments }