The PRM process should provide a methodical, efficient and effective way of managing risks to the delivery of a project. The overall PRM process to be followed is similar to the seven stages described for enterprise risk management in Part II. Clearly the focus will be different and the potential sources of risk will relate to the project life cycle, the sponsor’s organisation and the wider context (such as the economy, legislation and taxation). For consistency the same process map adopted for enterprise risk management is repeated here in Figure 18.2.
Readers implementing PRM should also refer to ISO 31000:2009 for guidance. It should be noted that risk management is an iterative process (and not purely sequential), as indicated by the return arrows in the figure. For the risk management process to remain effective the risk identification and analysis stages should be revisited on a regular cycle as new risks will emerge, existing risks will be overtaken by events or their nature will change (in terms of their probabilities and impacts). Changes in these earlier stages will necessitate changes to the evaluation, treatment, and monitoring and review stages.
18.6.1 Establish the Context
This stage involves establishing the context or environment of a project, which has two dimensions,externalandinternal. The external context relates to the political, legal, regula- tory, market, technological and economic setting, whereas the internal context relates to, for
Risk Management Process
Establish the Context
A31 Risk
Identification
A32 Risk
Analysis
A33 Risk
Evaluation
A34 Risk
Treatment
A35 Monitoring and Review
A36 Comm’n &
Consultation A37
Figure 18.2 Risk management process
instance, the organisation’s strategic objectives, its structure, policies, processes, stakeholders, culture, reputation, capabilities (including capital and people) and concurrent projects.
A key aspect of understanding the external context is to establish the legislation that the project will have to adhere to. This may be very significant if the project is related to, say, the oil and gas industry. Depending on the scale of the project, it may involve satisfying ex- tensive environmental and health and safety legislation and sustainability goals, and obtaining approvals will be both expensive and time-consuming.
A key aspect of understanding the internal context is to establish if the business case for the project supports delivery of the organisation’s business strategy and in turn whether the project is aligned with the business case. The business case should provide a description of the business needs and the project’s contribution to the organisation’s business strategy. It should state why the business change is required now, the key benefits that will be derived and the critical success factors. The purpose of the business case is to obtain management commitment and approval for investment in business changes and the resultant project(s) based on a clear rationale for doing so. The business case must provide sufficient information to enable management to discern if the project is desirable, viable and achievable.
The business case will dictate the project objectives. The project team must not only be clear what the project objectives are but also what the prioritised objectives are. The prioritised objectives will be dictated by the sponsor’s risk appetite (whether they are risk seeking, risk neutral or risk averse) and the drivers for the project. If a product is being manufactured to reach a market before competitors enter that market, then speed will be of paramount importance. If the business case for a project is only viable if costs are kept below a particular ceiling limit, then cost will be of primary importance. The prioritised objectives will inform the procurement route, the choice of contract and the contract conditions. If speed of completion is the most important objective, then the contract selected will be very different than the one selected for a project where cost certainty is the most important objective.
Project “environments” do not remain static. Once a project has been approved and com- menced, progress should be checked against the business case at the gate reviews to ascertain whether the project is still viable and the planned benefits will be realised. If the costs have risen above the cost plan, the project has been delayed and/or the scope is no longer achiev- able, the benefits may have been eroded to the point where the project should be re-scoped or
344 Simple Tools and Techniques for Enterprise Risk Management
Table 18.1 Distinguishing between the cause, risk and impact
Risk Cause Risk Description Risk Impact
As a result of. . . There is a risk that. . . Which may result in. . . As a result of changes in
environmental legislation
There is a risk that
environmental conditions are more onerous than anticipated
Which may result in a requirement for additional field studies, an increase in professional fees and schedule delay
even abandoned. If the project’s environment is dynamic and influences on the project cause priorities to alter, the business case may need to be adapted to reflect the changes and ensure the project remains aligned to the business’s strategic direction.
18.6.2 Risk Identification
Risk identification is the process of determining which risks may affect the project and estab- lishing their characteristics. Identification is typically achieved through a facilitated workshop or meeting attended by the project personnel, accompanied, where appropriate, by one or more of the following: stakeholders, end users, the project sponsor, external subject-matter experts and risk specialists. Identification is typically supported by stimuli such as checklists, prompt lists, a risk breakdown structure, drawings or flow charts. It is important that risk descriptions are not a confused mixture of causes, risks and impacts. The common problem is for participants in the process to offer risks such as cost overrun or late completion. It is not possible to define response actions (mitigation measures) for these risks without knowing the actual risk event and the causes. To illustrate this problem using a new port project and the subject of approvals as an example, the cause may be “changes in environmental legislation”, the risk may be “environmental conditions are more onerous than anticipated” and the impact is “schedule delay”. Just stating schedule delay as the risk would not provide any guidance as to where in the project life cycle the problem is likely to occur or how it might be addressed.
A way to overcome this problem is to use a prefix to the cause, risk and impact as exemplified in Table 18.1.
Risks have different characteristics depending on their source, and as a result a project team’s ability to influence their occurrence spans from no influence at all through to an ability to control, as illustrated in Table 18.2. External threats emanate from outside the business.
Internal threats emanate from within the business.
18.6.3 Risk Analysis
Risk analysis involves the identification of the probability and impact (positive or negative) of the identified risks and opportunities. Analysis can be qualitative or quantitative depending on the requirements of the risk process and the information available. Qualitative assessments use labels such as high, medium or low, whereas quantitative assessments provide a percentage likelihood such as 50% (or a range such as 40–60%) and an impact in terms of time, cost and any other measures of project success. Analysis should consider whether the risks are interdependent or independent. In other words, is the occurrence of one risk dependent on the occurrence of another? May one project event give rise to two (or more) risks with different
Table 18.2 The sources of risk and a project team’s ability to influence their probability and impact External Uncontrollable
(no influence)
Internal Alterable (able to influence)
Internal Controllable (able to control) The project is unable to
control. . . The project is able to
influence. . . The project is able to control. . . Government policy
The economy Inflation Taxation
Bank interest rates Import duties
Sponsor decision making Project objectives
Choice of procurement route Project duration
Change management process Project team performance
Clarity of the objectives Project processes Project reporting
Application of software tools Discipline integration Team communication
probabilities where only one of the risks can occur? Is there a situation where a number of risks may occur concurrently but only the risk with the largest time impact will affect the schedule?
18.6.4 Risk Evaluation
Risk evaluation typically looks at the combined net effect of the identified risks and opportu- nities and is commonly accomplished with the aid of proprietary software that has an in-built simulation technique such as Monte Carlo or Latin hypercube. A prerequisite for carrying out evaluation is that a probability and impact have been defined for each risk and opportunity, as described in the risk assessment stage above. The output of the evaluation stage can be used to define the project contingencies for time and cost. Evaluation can be conducted before and after the definition of response actions, and so the risk outputs need to be described by such statements as “if no response action is undertaken the risk exposure will be in the range. . .”
or “as a result of the defined response actions and assuming that they will be 100% effective (or whatever percentage is appropriate) when implemented, the risk exposure will be in the range. . .”. Reporting an overly optimistic mitigation success rate early in a project (as has occurred on government projects) can lead to underfunding and interruption of a project’s progress.
18.6.5 Risk Treatment
Risk treatment is the action of responding to an identified risk. This is arguably the most important aspect of the overall process. If a risk is left untreated then arguably it has been accepted by the project. Should the risk materialise, the project will have to live with the consequences, whatever they are. There are a number of response options.
18.6.6 Risk Monitoring and Review
Monitoring and review is an ongoing process of implementing and examining the success or otherwise of the planned responses. It entails evaluating the perceived benefit of the response, its attendant costs and the likelihood of new risks being triggered by the response. If the decision is taken to implement the response, there needs to be clarity as to who will do so and when.
346 Simple Tools and Techniques for Enterprise Risk Management
18.6.7 Communication and Consultation
Communication and consultation take place at commencement and throughout the risk man- agement process. The activities of the communication and consultation process are the tasks undertaken to strive to ensure that the risk management process is effective. These activities consist of:
• communicating with the sponsor and stakeholders (as appropriate) to establish their risk management expectations;
• clarifying with the project sponsor the project objectives and the ranking/prioritisation of the objectives;
• clarifying the objectives for risk management on the project;
• establishing alignment between the overall business strategy, the project business model and the risk management objectives referred to above;
• having a dialogue with the project sponsor to establish the sponsor’s risk appetite;
• agreeing across the project disciplines the risk management terms and definitions – this cannot be completed in isolation from the project as risk interfaces with and crosses over into a number of disciplines;
• holding a seminar to debate how risk management will be integrated with the project management function to ensure risk management becomes part of day-to-day management activities;
• clarifying through dialogue the purpose, format, content and frequency of risk reports;
• debating how risk management will be integrated with procurement, cost planning, change management and any other discipline that will interface with risk management;
• making sure that those allocated risk management responsibilities within the risk manage- ment plan understand their duties;
• agreeing how contingencies will be defined either by adopting quantitative risk analysis results or cost plan percentages verified by risk results;
• presenting the risk management plan and explaining how it will be applied;
• engaging with project team members to ensure risk registers and responses are up to date and the team are proactively managing risk.