Glen B. Alleman left a great comment with a link to an article refuting the need for Opportunity Management (OM). I have reviewed the article and feel it is describing a version of OM that is not what I am proposing. I’m still formulating my thoughts on this, so please excuse me if it sounds like random babble!!!! 🙂
Article Reference from Glen:
“Opportunity Management – Be Careful What You Ask For,” by Edmund H. Conrow and Robert N. Charette, Defense AT&L, March-April 2008, pp 16-19
http://www.dau.mil/pubs/dam/2008_03_04/conr_ma08.pdf
The authors cite 4 sources of opportunity from OM proponents:
- Absence of risk
- Inverse of risks
- Interaction of managing risks themselves
- Pure opportunities
The descriptions provided of sources 1, 2, and 3 do not fit my model of OM. Those are not valid sources of opportunities to be dealt with by OM as far as I’m concerned. I agree with the authors that a well-run risk management process along with other key project processes are sufficient.
My proposal of OM focuses on encouraging the identification and proper handling of #4, Pure Opportunities.
Pure Opportunities
The authors state in the article that “the search for processes, technology, or skilled personnel to improve program performance is the norm.” By whom? I believe the authors implicitly are saying this applies to the project manager. I agree.
I think the pure opportunities being missed are the ones the project manager, sponsor, and customer never know about, and some the project manager knows about but never elevates because it would create a requirement for more funding if approved. As I said in the earlier post, gold plating is a result of opportunities that a project team member discovered and executed on without any evaluation of the actual ROI and without any change to the baseline. In my experience, there are many more times when gold plating doesn’t occur….simply nothing occurs. The team member forgets about it because they fear rocking the boat with an opportunity that will increase costs or schedule. I have seen this many times in software development projects.
As for the authors’ call for data demonstrating the need for OM, based on the paragraph above there is no possibility of generating it in the OM I propose. We don’t know what we don’t know. Only after OM is in place would you be able to quantify this.
I agree
- “It takes a major leap of faith to believe that in a program in which poor program management, RM, and/or systems engineering practices exist that an OM practice would be implemented significantly more effectively.”
- “a recurring problem for far too many programs is a lust after new program “silver bullets” instead of a focus on implementing current processes and technology that adequately meet the requirements.”
- “opportunities are not risk-free.” – all scope, including that which is derived from opportunities that have gone through the CCB and modified the baseline, is subject to risk management. Period.
I disagree
- That an OM integrated project team (IPT) is necessary for OM
- That specific staff would be allocated to perform OM duties (except to write the OM Plan)
- That a new board or group would be required to handle OM
- That requirements creep should be controlled “by ensuring that opportunities that might change project program expectations or scope for the better be presented to higher management.” All changes should go through the already-established change control board (CCB) for the project.
Let me ask this of others out there who are advocates of OM. Did these authors fairly represent your understanding and/or implementation of what OM is all about? Are our ideas of OM really talking about separate things?