Risk Monitoring and Control is the process of keeping track of the identified risks, monitoring residual risks and identifying new risks, ensuring the execution of risk plans, and evaluating the plans' effectiveness in reducing risk.
The inputs to Risk Monitoring and Control are as follows:
- Risk management plan (RMP): The RMP is the subsidiary part of the integrated project plan. It documents procedures for managing risk throughout the project. It details identification and quantification of risk, responsibilities for managing risks, how contingency plans will be implemented, and how reserves will be allocated.
- Risk response plan: This plan documents the procedures for managing risk events. It addresses risk identification, owners and responsibilities, results from qualification and quantification processes, agreed responses for each risk, the level of residual risk to remain after the strategy is implemented, budgets and times for responses, and contingency plans.
- Project communication: Work results and other project records provide information about project performance and risks. Reports to monitor and control risks commonly include issues logs, action item lists, and jeopardy warnings (also called escalation notices).
- Additional risk identification and analysis: As project performance is measured and reported, unidentified potential risks may surface.
- Scope changes: They require new risk analysis and response plans.
These are the five tools and techniques to Risk Monitoring and Control:
- Project risk response audits: Throughout the life cycle of the project, risk auditors examine and document the effectiveness of your risk response in avoiding, transferring, or mitigating risk occurrence, as well as the effectiveness of the risk owner.
- Periodic project risk reviews: Such reviews should be regularly scheduled to monitor the progress and any changes to the project.
- Earned value analysis: EVA is used for monitoring overall project performance against a baseline plan. If a project deviates significantly from the baseline, update your risk identification and analysis. See Appendix A for EVA formulas, charts, and examples.
- Technical performance measurement: This compares technical accomplishments during execution to the plan's schedule of technical achievement. For example, omitting a milestone introduces scope risks.
- Additional risk response planning: If an unanticipated risk emerges, or if its impact on objectives is greater than expected, the planned response may not be adequate. You may require additional response planning to control risk. This provides a feedback loop.
These are the six outputs to Risk Monitoring and Control:
- Corrective action: This encompasses anything that brings your expected performance back in line with the project plan. At this stage, it involves carrying out either your contingency plan or workaround.
- Workaround plans: These are unplanned responses to emerging risks that were not previously identified or accepted.
- Project change requests: Implementing a contingency plan or workaround frequently requires changing the risk responses described in the project plan. Know the process flow and feedback loop.
- Updates to risk response plan: Document the risks that occur. Risks that don't occur should also be noted and closed out in the risk response plan. It's important to keep this up-to-date, and it becomes a permanent addition to project records, eventually feeding into lessons learned.
- Risk database: This is a repository for collection, maintenance, and analysis of data. It's used in risk management processes. Maintaining this database is very important for your project records.
- Updates to risk identification checklists: Becausethese updates help in the risk management of future projects, the checklists are vital tools.
Mastering risk controls
The key to understanding risks is to identify what constitutes the triggering event. You analyze, qualify, and quantify risks to minimize threats and maximize opportunities. Closely monitor risks throughout the project. Revisit your risk list periodically. Are the risks still valid? Perhaps a particular risk is no longer important. Or, you may uncover additional risks from new events or change requests. You must update the risk plans as you proceed. If you document your actions, stating why you made certain choices, and describe the results, you'll provide a good record for understanding upcoming risks, risks in future phases, and any risks that might affect the next project.
Handling change requests
Almost all controlling processes have change requests, so memorize the definition of this term and know the patterns. In exam questions, change requests may be described by using slight variations in terms. A change request fits a general pattern — as an input of control processes. The two exceptions where it's an output are Performance Reporting and Project Plan Execution. These are feedback loops in the process flow. The Quality process omits this feedback pattern; improvements are implemented immediately.
Anyone on the team can make a change request: a customer, a sponsor, or any stakeholder. You'll get change requests because a new technology has become available, government regulation forces it, or customers want new features that change the product's scope.
All proposed modifications are handled via change requests, which must be tracked. You manage them according to your change control system and configuration management procedures. These are both tools and techniques in Integrated Change Control, the global-level process that governs changes to both your project and the product.
You'll often have the authority to approve the decision yourself. If you do, it's important to document the change. Those requests increase scope or alter schedule, costs, or quality baselines. In these cases, you have to invoke your change control system. If your organization has a formal change control board (CCB) procedure for this process, call a meeting of the CCB, get its formal approval, document the results, and communicate the results to the team.
Change requests are the most important factor in controlling scope creep, the way most projects get out of hand and exceed their available resources. As a rule, the larger the number of change requests, the less planning that went into the initial project planning stages.
dummies
Source:http://www.dummies.com/how-to/content/pmp-certification-controlling-risk.html
No comments:
Post a Comment