Intro | Context | Processes | Planning | Tool Mgmt | Activities | Projects | Risks | Procurement | Metrics |
Risk Management is.... "the systematic process of identifying, analyzing, and responding to risk." It includes maximizing the probability and consequences of positive events and minimizing the probability and consequences of adverse events to objectives. Risk management for a managed configuration has these processes." |
Quoting from the PMBOK®, “these processes interact with each other and with the processes in the other knowledge areas. Each process generally occurs at least once in every” configuration management effort.
PMI in the PMBOK® says that “Risk is an uncertain event or condition that, if it occurs, has a cause and if it occurs, a consequence.” For example, a cause may be requiring the acquisition of a new tool or having limited personnel assigned to the configuration effort. The risk event is that the acquisition of the new tool may take longer than planned or the personnel may not be adequate for the task. If either of these uncertain events occur, there will be a consequence on the configuration cost, schedule, or quality. Risk conditions could include aspects of the configuration environment that may contribute to risk such as poor configuration management practices, or dependency on external participants that cannot be controlled.
Configuration risk includes both threats to the objectives of the configuration effort and opportunities to improve on those objectives. It has its origins in the uncertainty that is present in all configuration efforts. Known risks are those that have been identified and analyzed, and it may be possible to plan for them. Unknown risks, according to the PMBOK®, “cannot be managed”, although configuration managers may address them by applying a general contingency based on past experience with similar configuration management efforts.
The PMBOK® has great insight concerning risk and organizations that can be applied to configuration management efforts. It says, “organizations perceive risk as it relates to threats to …success. Risks that are threats to the [configuration management effort] may be accepted if they are in balance with the reward that may be gained by taking the risk. For example, adopting a fast-track schedule that may be overrun is a risk taken to achieve an earlier completion date. Risks that are opportunities may be pursued to benefit the [configuration effort’s] objectives.”
For a very complete discussion, we recommend the excellent discussion provided by the PMBOK it’s chapter 11. In the subsections below we have provided some guidelines for CM using the PMBOK as a guide.
It is suggested that things like the project charters, CM charters, QA charters, organizational policies, the defined roles and responsibilities, information on risk tolerances, a template for the risk management plan, a work breakdown structure all be at hand when doing risk management planning. The outputs from risk planning should be a risk management plan that describes the methodology, roles and responsibilities, budgeting, timing, scoring and interpretation of risks, risk thresholds, reporting formats and tracking of risks.
Anyone on the team can be a participant in risk identification from the management to the developer/manufacturing employee.
Risk identification is an iterative process. The first interaction, according to the PMBOK, "may be peformed by a part of the ...team or by the risk management team. The entire CM team and project management may make a second iteration. To achieve an unbiased analysis, persons who are not involved in the project may perform the final iteration."
"Often simple and effective risk responses can be developed and even implemented as soon as the risk is identified."
When we perform risk identification, some of the items which must be at our disposal include:
These things are used along with various tools and techniques to identify genuine risks and their triggers.
"Quantitative Risk Analysis" process aims to analyze numerically the probability of each risk and its consequence on project objectives, as well as the extent of overall risk to the" configuration management effort.
"Quantitative risk analysis generally follows qualitative risk analysis. It requires risk identification. The qualitative and quantitative risk analysis processes can be used separately or together."
Previous: CM Projects | Next: CM Procurement |