Oppportunity Management

During my recent talk on Risk Management Best practices, I focused on applying standard risk model, which requires identifying the event  and its impact explicitly along  with their respective drivers(causes). Separate identification of drivers enables  preparation of prevention   and contingency plans. A participant asked me a question of how to manage opportunities,  events which  reduce the time, budget for a baselined project. As per PMBOK,  opportunities are managed the same way as risks. A detailed risk and opportunity management process applicable for a city council is a good read to understand the application of this concept. In IT/engineering projects, Opportunity Management  is not so common. In this blog post, I explore the Opportunity Management and share few thoughts that I hope are practical and useful in practice.

Usually projects are taken up to address an opportunity such as addressing a underserved customer need, acquiring new skills, establishing a platform/IP that can be leveraged for a long time. This means that entire project is actually an opportunity management at the level of organization's portfolio.

Estimates for complex projects involve great deal of uncertainty. These are generally optimistic given the excitement around new project and general human optimism, despite the use of robust processes. Once the project is approved, the focus is on delivering  the project as per expectations while managing  threats.  Given a good system engineering approach, work is planned and executed to deliver as per expectations. Multiple options with respect to schedule/cost are explored as part of Project Management before baselining. This process  implicitly manages the opportunities to reduce the schedule/budget.

Due to change in customer scope or technology advances,  it is possible that certain options which were not explored during the project proposal/planning phase may become desirable for long duration projects.  At the same time, such options will not be without their share of risks. As an example consider that an enterprise mobile  application was planned initially for  one category of mobile Operating system, During the course of development,  the push for Bring Your Own Device (BYOD) made the need for supporting multiple mobiles became a pressing need. Then the opportunity of utilizing  a mobile OS neutral platform, which allows seamless targeting of mobile app to  other mobile operating systems become attractive.  In such a  case, it is advisable to pursue such  opportunities if the cost/time benefit after considering the risks associated with it  is beneficial.  If not, then it  would be more useful is to route such ideas behind opportunities through innovation pipeline of the organisation/group.    Once the idea passes through the innovation pipeline, the technology developed could be utilised in  future projects.

So in summary, my view is that opportunity management is implicitly practiced at the project level. It is more practical do it explicitly at the portfolio/organisation level. Share your perspective?
 

Benefits of Risk Breakdown Structure for Portfolio management

One new concept in PMBOK 5th edition is called Risk Breakdown Structure(RBS). This is a powerful concept to improve the risk management practice in the organization. Let's explore this in more detail in this post.

Graphics Credit:Andreas Plank 

During the postmortem or retrospective, lessons learnt from the project are captured including the experience with the risks. Usually this document in the form of a word document or Excel register is stored in the repository. If an organization has an efficient search engine for the repository, these documents may become useful for future projects. Though the tacit knowledge of the team is captured in the document, it is still not effectively used, because it is not in structured form.

The creation of Work Breakdown Structure(WBS) is critical for Scope definition and subsequent project tasks. As WBS is a hierarchical depiction of deliverables at various levels of granularity, it is useful for planning and reporting to various stakeholders. RBS arose from the need to organize the huge list of risks identified in a project. As its name indicates, it is also hierarchical organization of risks in various categories. If we look at a software project,(As per Dorofee A.J et.a's 1996 book "Continuous Risk Management Guidebook" quoted in Dr. David Hillson's article "User Risk Breakdown Structure to understand your risks", 2002) the sample organization at the first level could be product engineering, Development environment, project constraints. At the second level product engineering could be broken down to life cycle phases, Development environment could be broken down to development process, management process, work environment. Similarly the project constraints could be split into team, contract, and interfacing stakeholders.

RBS can be used instead of traditional risk check list for risk identification. Or after the risks are identified by other methods, these can be organized into this structure. Once this is done, insights such as dominant categories of risks can be gained. Additional risk identification sessions can be undertaken based on RBS to make the exercise comprehensive. Similarly the hierarchical nature of categories allows appropriate focus at the various organization levels. If all projects follow this, portfolio risk management becomes easier, as the risks can be aggregated in relevant organization wide categories and handled. At the closing of the project, populating the risks lessons learnt as per the RBS in a database makes this knowledge much more useful for future projects.

Did you use RBS? Are there any better methods? Share your thoughts.