Paul made a comment regarding the role of risk management for the previous post. The topic of risk management has many points of view:
- PMBOK(r) Chapter 11
- DoD PMBOK(r) Chapter 11
- DoD Risk Management
- David Hillson's approach described in his several books, Effective Opportunity Management for Projects, being a recent one
- Edmund Conrow's approach described in Effective Risk Management, AIAA Press
- SEI Continuous Risk Management
- INSEADS paradigm of four views of managing in the presence of risk
- NASA's Risk Management paradigm
- US Department of Energy's risk management paradigm
- MOASIC (Mission-Oriented Success Analysis and Improvement Criteria)
- Tools like Active Risk Manager and Ares's risk tool as well a Mitre's risk tools and paradigm
I've applied, used, or been involved in the application of each of these paradigms. Personally I'd not recommend PMBOK, instead read DoD PMBOK as a start. Depending in the domain and context any one of these - other than PMBOK(r) Chapter 11 - could be applied.
But, and this is a very big but, risk management is not in the same league of an individual process area or a practice. It is separate and at the same time all encompassing. Those doing this best are working in the space flight business. There the role of Safety and Mission Assurance (S&MA) guides he risk processes. This includes:
- Identification and management of the risks and their handling.
- The Program Planning and Controls staff "owns" the role of programmatic risks and integrates these risks in the Integrated Master Schedule
- The Systems Engineering staff "owns" the role for technical risk in terms of impacts on the system
- The Technical staff "owns" the role of mitigating or retiring - retiring being preferred - for their individual disciplines. The SE's for the system as a whole.
Here's a very simple view of the interconnections of cost, schedule, and technical perfomance with the risk activities between the three.
In the absence of a 3 day workshop and a specific context and domain, this picture shocul be considered "notional."
While risk is considered along with cost, schedule (not time), and Technical Performance, it is also an over arching process. A Systems process. But this diagram speaks to the artifacts of the risk management practice - cost, schedule, and technical performance margins. In the NASA approach and other DoD views, risks are defined as possibilities and need mitigations or retirement plans that impact cost, schedule, and technical performance.
But this narrow band channel of a blog limits discussion around this important topic. Suffice it to say the PMBOK approach is not the starting point. Instead I'd recommend the SEI Continuous Risk Management book. But that is just a process maturity assessment outcome guide - with descriptions of what a good risk management process looks like. Conrow's work is the seminal approach for domains I work in. There are a multitude of dimensions to risk management, so a single paradigm will rarely cover what is needed in practice.
There may be other works in other domains.
