Glen B. Alleman’s Case for Opportunity Management Glen B. Alleman made a great comment and provided a link to an article that refutes the need for Opportunity Management (OM). I’ve read the article and believe it describes a different version of OM than what I propose. I am still forming my thoughts on this. 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 The authors cite 4 sources of opportunity from OM proponents:

  • Risk is eliminated
  • Inverse of risk
  • Interaction in managing risks yourself
  • Pure opportunities
  • My model of OM does not accept the descriptions of sources 1, 2, or 3. Those sources are not valid sources of opportunities that should be addressed by OM. I agree with the authors that a well-run process for risk management and other key project processes is sufficient. My proposal for OM focuses on the identification and proper management of #4, Pure Opportunities. Pure Opportunities According to the article, “The search for processes, technology or skilled personnel to improve program performances is the norm.” Who? This applies implicitly to the project manager, I believe. I agree. I agree. As I mentioned in my earlier post, gold plating occurs when a project team member discovers opportunities and executes on them without any evaluation of the actual ROI or any changes to the baseline. My experience is that gold plating doesn’t happen …. more often than not. Because they don’t want to be seen as a disruptor of the team’s schedule or costs, they forget about it. This has happened to me many times in software development projects. The authors have asked for data to demonstrate the need for OM. Based on the paragraph above, there is no way that I can generate it in the OM I propose. We don’t know what else we don’t. This can only be quantified once OM is in place. I agree

    • “It takes a leap of faith to believe an OM practice could be implemented more effectively in a program with poor program management, RM and/or systems engineering practices.”
    • “A recurring problem for far to many programs is a lust for new program “silver bullets” rather than a focus on implementing current processes, technology, and meeting the requirements.”
    • “Opportunities are not without risk.” All scope, even those derived from opportunities that have been modified by the baseline and passed the CCB, is subject to risk management. Period.

    I disagree

    • OM requires an integrated project team (IPT), which is why an OM integrated team (OM) is required.
    • This staff would be assigned to perform OM duties (except writing the OM Plan).
    • To handle OM, a new board or group will be needed.
    • Requirements creep should be controlled by “ensuring that opportunities to change the scope or expectations of the project are presented to higher management.” All changes must be approved by the change control board (CCB), which is already in place for the project.

    Let me ask others who support OM. These authors accurately represented your understanding of OM and/or its implementation. Are we really talking about two separate things in our ideas of OM?