knowledge management

Effective Opportunity Management for Projects

by Josh

opportunity_mgmtGlen Alleman left a comment recommending several resources for me, one of which is the book “Effective Opportunity Management for Projects“.  I am reading it now and would like to share some of my initial insights thus far.

I’ve found the authors agree with me that standard risk management approaches mostly pay lip service to opportunity management without really addressing it.  In correlation (not necessarily causation) with that, most project managers and teams focus on threats as the primary target of risk management.

I’ve also revised my view of needing a seperate knowledge area for opportunity management.  Through the various articles, websites, and books I’ve reviewed thus far I believe it should be handled within risk management; but risk management approaches and project managers need to do more than just pay opportunity management the lip service they do today.

A citation from the book which states my view nicely:

“….both can be handled by the same process, although some modifications may be required to the standard risk management approach to enable it to deal effectively with opportunities.”

Another important insight is that opportunities are not merely the mirror-image of threats.  A chance that a threat will not occur is NOT an opportunity.

“Distinctive opportunities exist in their own right, presenting the chance to enhance project objectives, deliver early, cost less, increase customer satisfaction, improve competitiveness, enhance company reputation, etc.”

Thanks for tagging along with me on my journey through better understanding opportunity management.  More to come!

Opportunity Management

  1. The Need for a New Knowledge Area
  2. The Case for Opportunity Management
  3. Effective Opportunity Management for Projects
Previous in series

{ 3 comments }

Project Knowledge Management Solutions via Wiki

by Josh

project management 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.

{ 8 comments }