7

RISK MANAGEMENT IN THE CONTEXT OF PROJECT MANAGEMENT

The purpose of risk management within the project domain is to support the optimal delivery of project results leading to the realization of benefits for which the project was undertaken. In addition, risk management helps to ensure that delivery of these results occurs within the identified project constraints.

Projects are aimed at creating a unique product, service, or result. Project risks are triggered by uncertainty in some of the operational activities and enterprise environmental factors. Project success is assessed and evaluated based upon the ability to deliver a tangible outcome. Therefore, risks that are managed at the project level are evaluated and considered according to their potential impact on the ability to deliver a tangible outcome. The evaluation and analysis of risks are focused at the tactical level, and every other consideration in terms of impact on expected value or benefit creation is escalated to the portfolio or program governance level.

Project teams need to have visibility into the strategic objectives that led to its authorization. This allows for effective, proactive project management and reporting of key opportunities and threats that could potentially impact the objectives.

7.1 PROJECT RISK MANAGEMENT LIFE CYCLE

The life cycle of risk management as described in Section 4 generally applies to project management. However, there are a number of additional considerations for the corresponding processes that need to be taken into account in this context.

7.1.1 PROJECT RISK IDENTIFICATION

Identification of risks at the project level is based on operational and contextual inputs. Operational inputs come from the activities of the project itself. Among these inputs are:

• Project scope statement. There are a number of risks related to the specifications and agreed methods of delivery for products, services, or other results that are expected to be delivered by the project.
• Project life cycle. Regardless of the life cycle selected, the life cycle itself introduces a number of risks.
• Work breakdown structure (WBS), activity list, or backlog. There are a number of risks directly connected to the decomposition of the project work and triggered by its execution.
• Estimates. Estimates are performed in terms of time, cost, effort, and resources. The target accuracy of an estimate is the level of risk tolerated for that estimate.
• Dependencies and sequence of work. Interdependencies and the resulting sequence of work are sources of risk. Special attention is paid to critical path and external dependencies created by the sharing of resources with other projects. If the critical path changes during the project life cycle, the criticality of the risks related to the elements on that critical path may also be dynamic.
• Procurement plans. Subcontracting parts of the project scope may be an action of risk transfer, but it may also trigger new risks.
• Change requests. Each time a change is implemented within a project, it may eliminate certain risks but also trigger new ones.
• Historical data. Based on past experience, it is important to identify systemic risks and automate their treatment.

Contextual risks result from the consideration of enterprise environmental factors and other strategic or organizational aspects shaping the environment of the project, such as:

• Stakeholder analysis. All key stakeholders can bring a number of opportunities to be exploited; however, when handled inadequately, they may introduce threats that need to be mitigated.
• Business case. The business case often implies a factor of profitability or positive return on investment that is exposed to a certain level of uncertainty or risk. The ability to achieve and sustain benefits after project completion is part of risk identification. Risks impacting the realization of benefits can be addressed during project execution.
• Program or portfolio governance-level success factors. These factors may vary over time and change the priority level of the project within the program or portfolio.
• Enterprise environmental factors. Factors such as the strategy of the organization, its structure, the dynamics of its business environment, and the variability of its regulatory environment are triggers of risks that directly impact the project.

7.1.2 QUALITATIVE AND QUANTITATIVE PROJECT RISK ANALYSES

The evaluation of risks at the project level is performed by taking into account the degree of impact on the project objectives and probability of occurrence. The purpose of these analyses is to evaluate whether or not the impact can be contained within the limits of the project budget and the boundary of accountability of the project manager. Risks that have an impact evaluated as containable within the limits of accountability of the project manager and team are dealt with in the project risk management plan and strategy. Every risk impact that exceeds the limits of accountability is escalated to the appropriate governance level.

When the impact of the risk is determined to be containable within the limit of the project budget and accountability of the project manager and team, it is addressed at the project level.

If the risk impacts the ability of the organization to obtain or sustain the expected benefits, then the risk and its treatment are escalated to the appropriate governance level.

7.1.3 PROJECT RISK RESPONSE STRATEGIES

In principle, all of the potential responses listed in Section 4.6 can be used when responding to risks at the project level.

The strategies developed to deal with risks at the project level consist of activities guided by the risk management plan, budgeted accordingly, and funded by the project's contingency reserve. Risk responses consist of additional activities or work packages to update the project's baselines or remove activities from these same baselines.

Whenever the project is part of a program or is managed as part of a portfolio, escalation of risks to a higher governance level is always one of the responses. Escalation increases the effectiveness or efficiency of dealing with specific risks that impact the program or portfolio or with risks that require funding in excess of the contingency reserves.

7.1.4 IMPLEMENTING PROJECT RISK RESPONSES

The implementation of risk responses within a project is performed according to the risk management plan, uses the corresponding budget from the reserves into the budget, and updates the project baselines accordingly. Together, these activities become part of the regular project scope and are subject to the application of project execution processes.

The implementation of a risk response plan is not initiated through a formal project change management procedure. A risk response is part of the project management plan and does not require a formal change control process because it has already been approved as part of the risk management plan.

7.1.5 MONITORING PROJECT RISK

Monitoring risks at the project level consists of:

• Checking the status of the risks that have already been identified,
• Verifying whether any known risk has not occurred or is not about to occur, and
• Monitoring the status of all actions implemented to respond to the detection or occurrence of a risk.

These activities typically lead to updates of plans, registers, and controlling documents. In addition, performance reports are regularly analyzed in order to identify any potential trends that could indicate new risks or the ineffectiveness of response strategies.

The risk responses implemented to anticipate and prevent the occurrence of threats or exploit and enhance the opportunities are conducted according to their quantitative parameters of time, cost, scope, and specifications. A qualitative assessment evaluates the effectiveness and efficiency of risk treatment for specific risks that have occurred.

7.2 INTEGRATION OF RISK MANAGEMENT INTO PROJECT MANAGEMENT PROCESS GROUPS

A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) [4] describes the Project Risk Management Knowledge Area. An analysis of the relationship between the processes in Project Risk Management and other Knowledge Areas is provided next. There are a number of general risk management practices that can be applied across the project life cycle. The following sections summarize these practices in a general way as they relate to the Process Groups and Knowledge Areas shown in Table 7-1.

7.2.1 INITIATING PROCESSES

Initiating processes are performed to define a new project or a new phase of an existing project by obtaining authorization to start the project or phase. An essential part of that work is related to understanding the high-level risks that might impact the realization of objectives specified in the business case. It is essential to address these risks prior to authorizing the project or phase.

During project initiation, the selection of the appropriate project life cycle is one of the first decisions supported by risk management. Each of the known project life cycles has an impact on all areas of project management by helping to enhance and exploit opportunities or introducing a number of threats.

Another important aspect of risk management during project initiation is the understanding of risks related to key stakeholders, their interests, and potential conflicts among them and with the project.

7.2.2 PLANNING PROCESSES

Planning processes establish the scope of the project, refine the objectives, and define the course of action required to attain the objectives that the project was undertaken to achieve.

The selection of the overall risk management approach is one of the key planning decisions. It involves the analysis of risks that could potentially impact the effectiveness of the risk management processes.

The key areas of planning that also include risk management practices are:

• Integrity of the planning processes and the resulting plans,
• Selection of the management approaches in all Knowledge Areas relevant to the project, and
• Estimation activities.

It is typical that processes in this Process Group lead to the identification of a high number of risks because these processes include analytical work necessary for planning. It is important to ensure that risk identification becomes a natural part of every process in this Process Group.

7.2.3 EXECUTING PROCESSES

Executing processes are performed to complete the work defined in the project management plan to satisfy the project requirements and achieve the objectives of the project. Successful risk management depends on the flow of knowledge within the project and the organizations involved in its execution.

Risk management practices are most effective when supported by a culture that embraces proactive behavior, open communication, organizational learning, and continuous improvement. This means that integration with team building and management, quality management, execution of stakeholder engagement strategies, and communication processes are essential.

7.2.4 MONITORING AND CONTROLLING PROCESSES

Monitoring and Controlling processes track, review, and regulate the progress and performance of the project, identify the areas in which changes to the plan are required, and initiate the corresponding changes.

Risk management supports efforts to ensure integrity and reliability of reporting. On the other hand, risk identification, risk analysis, and risk monitoring processes use the performance data and information as key inputs that help identify, analyze, and monitor risks.

7.2.5 CLOSING PROCESSES

Closing processes are performed to formally complete or close the project, phase, or contract. Where risk management is concerned, part of the closing practices involve securing knowledge that may be useful in future project phases, projects, or other activities of the organization. The remaining known risks that could impact the realization of benefits are handed over prior to project closure.