Project Risk Management：项目风险管理.doc

Project Risk ManagementRisk management is the systematic process of identifying, analyzing and responding to potential project risk. It includes maximizing the probability and impact of positive events and minimizing the probability and consequences of events adverse to project objectives. Figure 11.1 provides an overview of the following major processes. 11.1 Risk Management Planningdeciding how to approach and plan the risk management activities for a project.11.2 Risk Identificationdetermining which risks might affect the project and documenting their characteristics.11.3 Qualitative Risk Analysisperforming a qualitative analysis of risks and conditions to prioritize their effects on project objectives.11.4 Quantitative Risk Analysismeasuring the probability and impact of risks and estimating their implications for project objectives. 11.5 Risk Response Planningdeveloping procedures and techniques to enhance opportunities and to reduce threats to the projects objectives.11.6 Risk Monitoring and Controlmonitoring residual risks, identifying new risks, executing risk reduction plans and evaluating their effectiveness through the project life cycle.Note to insert chart with processes with inputs, tools & techniques, outputs like pg 112 of the PMBOK Guide, 1996These processes interact with each other and with the processes in the other knowledge areas. Each process generally occurs at least once in every project. Although processes are presented here as discrete elements with well-defined interfaces, in practice they may overlap and interact in ways not detailed here. Process interactions are discussed in detail in Chapter 3.Project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on a project objective. A risk has a cause and, if it occurs, an impact. For example, the cause may be requiring a permit or having limited personnel assigned to the project. The risk event is that the permit may take longer than planned or the personnel may not be adequate for the task. If either of these uncertain events occurs, there will be an impact on the project cost, schedule or quality. Risk conditions include practices or aspects of the project environment that may make contribute to project risk such as a lack of project scheduling personnel or inability to make decisions in a timely fashion.Project risk includes both threats to the projects objectives and opportunities to improve on those objectives. It has its origins in the uncertainty that is present in all projects. Risks may be known unknowns; risks that are identified, assessed and quantified and for which plans can be made. Risks may be unknown unknowns; risks that are not yet identified or are impossible to predict. Although specific risks or conditions are not identified, project managers know from past experience that a general level of risk can be expected. Risk should be related to reward. Risks accepted should be in balance with the reward that may be gained by taking the risk. For example, a fast-track schedule is a risk taken to achieve the benefit of a shortened schedule.To be successful, the organization must be committed to addressing risk management seriously throughout the project. One measure of the organizational commitment is its dedication to gathering high-quality and honest data on project risks and their characteristics.11.1 Risk Management PlanningRisk management planning is the process of deciding how to approach and plan the risk management activities for a project. It is important to plan for the risk management processes that follow to ensure that the level, type, and visibility of risk management are commensurate with both the risk and importance of the project to the organization. 11.1.1 Inputs to Risk Management Planning.1 Project charter. The project charter is discussed in section 5.1.3.1. It includes the business needs and project description at a level appropriate to the needs of the project.2 Organizations risk management policies. Some organizations may have predefined methods for qualitative and quantitative risk analysis.3 Defined roles and responsibilities. Predefined roles, responsibilities and authority levels for decision-making will influence planning.4 Stakeholder risk tolerances. Different organizations and different individuals have different tolerances for risk. These may be expressed in policy statements or revealed in actions.5 Template for the organizations risk management plan. A pro-forma standard that the organization has developed for risk management generally. That standard must be adapted to each project by the project manager or the risk management team. It should be improved based on experience from each project.7 Work breakdown structure. The WBS is described in section 5.3.3.1.11.1.2 Tools and Techniques for Risk Management Planning.1 Planning meetings. These are designed to adapt the risk management plan template to the current project. Attendees include the project manager, the project team leaders, anyone in the organization with responsibility to manage the risk planning and execution activities, key stakeholders and others as needed.11.1.3 Outputs from Risk Management Planning.1 Risk management plan. The risk management plan documents how risk identification, assessment, quantification, response planning, monitoring and control will be structured and performed during the project life cycle. The risk management plan does not address responses to individual risks this is accomplished in the risk response plan that is discussed in section 11.5.3. The risk management plan may include: .Methodology. defines theapproaches, tools and data sources that may be used to perform risk management on this project. Roles and responsibilities. Defines the lead, support and risk management team membership for each type of action in the risk management plan. Risk management teams organized outside of the project office may be able to perform more independent, unbiased risk analyses of projects than those from the sponsoring project team. Timing. Defines how often the risk management process will be performed through the project life cycle. Results should be developed early enough to affect decisions. The decisions should be revisited periodically during project execution. Scoring and interpretation. The scoring and interpretation methods appropriate for the type and timing of the qualitative and quantitative risk analysis being performed. Methods and scoring must be determined in advance to ensure consistency. Thresholds. The threshold criteria for risks that will be acted upon, by whom and in what manner. The project customer or originator may have a different risk threshold from the providing organization. The acceptable threshold forms the target against which the project team will measure the effectiveness of the risk response plan execution. Reporting formats. Describes the content and format of the risk response plan described in Section 11.5.3. Defines how the results of the risk management processes will be documented, analyzed and communicated to the project team, internal and external stakeholders, sponsors and others. Tracking. Documents how all facets of risk activities will be recorded for the benefit of the current project, future needs and lessons learned. Documents if and how risk processes will be audited.11.2 Risk IdentificationRisk identification involves determining what risks might affect the project and documenting their characteristics. Participants in risk identification should include as many of the following as possible: project team, risk management team, subject matter experts from other parts of the company, customers, end users, other project managers, stakeholders, and outside experts. Risk identification is an iterative process. The first iteration may be performed by a part of the project team, or by the risk management team. The entire project team and primary stakeholders may make a second iteration. To achieve an unbiased analysis, persons who are not involved in the project may perform the final iteration.11.2.1.Inputs to Risk Identification .1 Risk management plan. This plan is described in 11.1.3.2 Project planning outputs. Risk identification requires an understanding of the projects mission, scope, and objectives of the owner, sponsor or stakeholders. Outputs of other processes should be reviewed to identify possible risks. These may include: Project charter. Work breakdown structure. Product description. Project schedule logic. Cost and duration estimates. Resource plan. Procurement plan. Assumptions list. Constraints list.3 Risk categories. Risk categories help to organize and identify possible risks that may affect the project for better or worse. Categories should be well defined and reflect common sources of risk for the industry or application area. Commonly used categories include: Technical, quality or performance riskssuch as reliance on unproven or complex technology or a requirement to achieve unrealistic performance goals, changes to the technology used or to industry standards. Project-management riskssuch as poor allocation of time and resources, inadequate quality of the project plan, poor use of project management disciplines, unrealistic or incomplete estimates, problems with suppliers and subcontractors, poor communication techniques and inability to make project decisions. Organization riskssuch as cost, time and scope objectives that are internally inconsistent, lack of prioritization of projects, inadequacy or interruption of funding, funding interruptions and resource conflicts with other projects in the organization. External riskssuch as shifting legal or regulatory environment, changes in marketplace trends, labor issues, sponsor or owner issues, country risk and weather, and physical risks for which plans can be developed. Some extreme events such as earthquakes, floods, and civil unrestare generally considered disaster recovery scenarios rather than project risks.4 Historical information. Information on prior projects may be available from the following sources: Project filesone or more of the organizations involved in the project may maintain records of previous project results that can be used to identify risks. These may be final project reports or risk response plans. They may include lessons learned that describe problems and their resolutions. Project team knowledge may be unorganized but available through the experience of the project stakeholders or others in the organization. Published informationcommercial databases, academic studies, benchmarking and other published studies may be available for many application areas.11.2.2.Tools and Techniques for Risk Identification .1 Documentation reviews. Performing a structured review of project plans and assumptions, prior project files and other information is generally the initial step taken by project teams.2 Information gathering techniques. Brainstorming, the Delphi technique and interviewing are used in risk identification. Brainstorming. Brainstorming is probably the most frequently used risk identification technique. The goal is to obtain a comprehensive list of risks that can be addressed later in the qualitative and quantitative risk analysis processes. Using brainstorming, a meeting is organized with a multidisciplinary set of experts. Under the leadership of a facilitator, these people generate ideas about project risk. The brainstorming meeting proceeds without interruption, without expressing judgment or criticism of others ideas and without regard to individuals status in the organization. Sources of risk are identified in broad scope and posted for all to examine during the meeting. Risks are then categorized by type of risk and their definitions are sharpened. Brainstorming can be more effective if participants prepare in advance, the facilitator develops some risks in advance, and the meeting is structured by project segment and risk category. Delphi technique. The Delphi technique is a way to reach a consensus of experts on a subject such as proejct risk. Project risk experts are identified but participate anonymously. They do not meet face-to-face. A facilitator uses a questionnaire to solicit ideas about the important project risks. The responses are submitted and put into risk categories by the facilitator. These risks are then circulated to the experts for further comment. Consensus on the main project risks may be reached in a few rounds of this process. The Delphi technique helps reduce bias in the and keeps any person from having undue influence on the outcome. Interviewing. Risks can be identified by interviews of experienced project managers or subject matter experts. The person responsible for risk identification identifies the appropriate individuals, briefs them on the project, provides information such as the work breakdown structure and the list of assumptions. The interviewees identify risks on the project based on their experience, project information and other sources they find useful. Strengths, weaknesses, opportunities and threats (SWOT) analysis. Ensures examination of the project from each of the SWOT perspectives to increase the breadth of the risks considered. .4 Assumptions analysis. Every project is conceived and developed based on a set of hypotheses, scenarios or assumptions. Assumptions analysis is a technique that explores the assumptions accuracy. It identifies risks to the project from inaccuracy, inconsistency or incompleteness of assumptions.5 Diagramming techniques. Diagramming techniques may include: Cause-and-effect diagrams (also known as Ishikawa or fishbone diagrams)-useful for identifying causes of risks (described in section 8.1.2.3). System or process flowchartsshow how various elements of a system interrelate and the mechanism of causation (described in section 8.1.2.3). Influence diagramsa graphical representation of a problem showing causal influences, time ordering of events and other relationships among variables and outcomes.11.2.3Outputs from Risk Identification.1 Identified risks . Risks are discrete occurrences or conditions that may affect the project for better or worse. .2 Triggers. Triggers, sometimes called risk symptoms or warning signs, are indications that a risk has occurred or is about to occur. For example, failure to meet intermediate milestones may be an early warning signal of an impending schedule delay.3 Inputs to other processes. Risk identification may identify a need for further action in another area. For example, the work breakdown structure may not have sufficie