Project Knowledge Management Solutions via Wiki
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.
Oct 31st, 2008 at 2:05 pm
Sharepoint has Wiki libraries and Wiki sites. It allows versioning and comparison between edits.
If the wiki is configured as a site or subsite, you can assign a primary and secondary owner. Sharepoint can be configured to prompt the owner(s) to confirm the site’s viability every , but that period is set for ALL the sites, it’s not on a site or subsite basis.
I’ve been motivated to install and check out CKS:EWE (Community Sharepoint Kit: Enhanced Wiki Edition) for months now but some thing or another keeps coming up that prevents it…I have high hopes for it however.
http://www.codeplex.com/CKS/Release/ProjectReleases.aspx?ReleaseId=8087
Oct 16th, 2008 at 10:17 pm
WIKI is an excellent PM tool - more than that actually.
If implemented correctly, it can spur massive momentum in the development organization, as well as the overall organization.
Further, it can improve morale and serve as a catalyst to charging professionals careers - much like blogs are doing on the Internet. In alot of ways, the same phenomenon.
The openness of a WIKI is like the openness and success of open source software. Through collaboration, open source went from being ridiculed or pshawed to serious business cases and profitable companies over the years. Through collaboration, no one that is collaborating will want it to fail.
In fact - the best selling (and best working!) WIKI on the market - Atlassian Confluence WIKI is also a successful business COMPLETELY built on the premise of collaboration (their doc and their plugins). Their own product and websites are the best case example of how to WIKI correctly. Lead the contributors through a configured structure (that can evolve), entice collaboration, and moderate as needed - but not heavy handed. (http://www.atlassian.com)
With WIKI’s internally, when embraced - people start taking more care in their work, care in presentation, care to express things easier, and simpler, and clearer. Designs are flushed sooner, up front - and design specs that are often skipped, start becoming reality - and in a collaborative way. Checks and balances happen on the WIKI, not on the 11th hour when trying to do a final build.
BUT - it’s all in the implementation.
I have seen way more bad WIKI implementations than good ones - and the only good ones happen because of a moderator - not heavy handed, but someone also serves as a champion for the cause.
Someone who cares. Someone who rallies. Someone who promotes it internally.
Often WIKI and issue tracking systems or other support systems are deployed by IT - and left to the masses - with no real over see-er on the process, or lack of process (as the case happens with WIKIs - and then all of a sudden, there is simply a mess to deal with).
Someone that has a vested interest in the cause is often the best candidate for this, like a technical writer or a PM. If more people eagerly contribute, all the better and smoother their job becomes as well - and the writer is not left in the back room to flail with little to no input because everyone is too busy to care about their key objective too.
Regardless though - whoever is moderator - the key in effective WIKIing is NOT obsessive control at the Admin level. Obsessive control stiffles the flow, for sure!
Seen this too. And without the flow - well what’s the difference. Might as well just go back to sharing emails.
Open and engaged flow to create a team environment is core.
Just my thoughts …
I see NO cons in WIKIs, except languishing ones without a nurturer.
Sep 19th, 2008 at 6:38 pm
Personally, I’ve used SharePoint before, but not as a Wiki. Does it have the functionality I describe here?
Sep 18th, 2008 at 10:33 pm
Josh,
Have you used SharePoint for this role?