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.
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.
 | ||
| Graphics Credit:Andreas Plank |
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.
