10
Risk
This chapter covers:
•uncertainty as a common aspect of project management
•threats and opportunities, and appropriate responses
•PRINCE2’s requirements for the risk theme
•roles and responsibilities
•guidance for effective risk management
•PRINCE2 procedure for managing risk
10 Risk
Key message
The purpose of the risk theme is to identify, assess and control uncertainty and, as a result, improve the ability of the project to succeed.
All projects encounter uncertainty when trying to achieve their objectives. This uncertainty may arise from events inside or outside the organization. For example, there may be uncertainty about the ability of the organization to agree the scope of the project within certain timescales or the availability of critical resources. There might also be uncertainty about the final scope and shape of legislation with which a project is required to ensure compliance.
Definition: Risk
An uncertain event or set of events that, should it occur, will have an effect on the achievement of objectives. A risk is measured by a combination of the probability of a perceived threat or opportunity occurring, and the magnitude of its impact on objectives.
Risks can have either a negative or positive impact on objectives if they occur. PRINCE2 uses the terms:
•Threat For uncertain events that would have a negative impact on objectives.
•Opportunity For uncertain events that would have a positive impact on objectives.
These can impact the project’s objectives of delivering an agreed scope and benefits to an agreed time, cost and quality.
Given that all projects involve some degree of risk-taking, it follows that projects need to manage risk, and they need to do so in a way that supports effective decision-making. This provides a disciplined environment for proactive decision-making.
Definition: Risk management
The systematic application of principles, approaches and processes to the tasks of identifying and assessing risks, planning and implementing risk responses and communicating risk management activities with stakeholders.
For risk management to be effective:
•risks that might affect the project achieving its objectives need to be identified, captured and described
•each risk needs to be assessed to understand its probability, impact and timing (proximity) so that it can be prioritized. The overall risk exposure needs to be kept under review, together with the impact of risk on the overall business justification for the project
•responses to each risk need to be planned, and assigned to people to action and to own
•risk responses need to be implemented, monitored and controlled.
Throughout the process, information about risks must be communicated within the project and to stakeholders.
Effective risk management provides confidence that the project is able to meet its objectives and that the business justification continues to be valid. It supports decision-making by ensuring that the project team understand not only individual risks but also the overall risk exposure that exists at a particular time.
Definition: Risk exposure
The extent of risk borne by the organization at the time.
10.2 PRINCE2’s requirements for the risk theme
To be following PRINCE2, a project must, as a minimum:
•define its risk management approach, which must minimally cover:
•how risks are identified and assessed, how risk management responses are planned and implemented and how the management of risk is communicated throughout the project lifecycle
•assessing whether identified risks might have a material impact on the business justification of the project (PRINCE2’s continued business justification principle)
•the roles and responsibilities for risk management (PRINCE2’s defined roles and responsibilities principle)
•maintain some form of risk register to record identified risks and decisions relating to their analysis, management and review
•ensure that project risks are identified, assessed, managed and reviewed throughout the project lifecycle
•use lessons to inform risk identification and management (PRINCE2’s learn from experience principle).
PRINCE2 requires that two products are produced and maintained:
•Risk management approach Describes how risk will be managed on the project. This includes the specific processes, procedures, techniques, standards and responsibilities to be applied.
•Risk register Provides a record of identified risks relating to the project, including their status and history. It is used to capture and maintain information on all the identified threats and opportunities relating to the project.
Both of these products should be created during the initiating a project process. The risk management approach should be reviewed and possibly updated at the end of each management stage. The risk management approach will define how and when the risk register is reviewed and updated.
Appendix A (sections A.24 and A.25) provides product descriptions and suggested content for these products.
PRINCE2 recommends an approach to risk management based on Management of Risk: Guidance for Practitioners (Office of Government Commerce, 2010).
Key message
PRINCE2 does not prescribe a particular or detailed approach to risk management. Any approach that meets the requirements described can be said to be following PRINCE2.
10.2.1 Risk responsibilities in PRINCE2
Responsibilities for managing risk in PRINCE2 are set out in Table 10.1. As described in Chapter 7, if roles are combined then all the responsibilities in this table must still be undertaken.
Table 10.1 Responsibilities relevant to the risk theme
Role |
Responsibilities |
Corporate, programme management or the customer |
Provide the corporate, programme management or customer risk management policy and risk management process guide (or similar documents). |
Executive |
Ensure that the risk management approach is appropriate. Ensure that risks associated with the business case are identified, assessed and controlled. Escalate risks to corporate, programme management or the customer as necessary. |
Senior user |
Ensure that risks to the users are identified, assessed and controlled (such as the impact on benefits, operational use and maintenance). |
Senior supplier |
Ensure that risks relating to the supplier aspects are identified, assessed and controlled (such as the creation of the project product). |
Project manager |
Create the risk management approach. Create and maintain the risk register. Ensure that project risks are being identified, assessed and controlled throughout the project lifecycle. |
Team manager |
Participate in the identification, assessment and control of risks. |
Project assurance |
Review risk management practices to ensure that they are performed in line with the project’s risk management approach. |
Project support |
Assist the project manager in maintaining the project’s risk register. |
10.3 Guidance for effective risk management
10.3.1 Align with organizational and other policies and processes
A project may need to align its risk management approach with organizational, programme or portfolio policies, standards or processes. This might include:
•aligning with any centrally defined risk management policies, standards and approaches
•using any centrally defined risk management techniques
•adopting any centrally deployed tools
•aligning with any centrally defined risk management roles or competency frameworks.
Organizations will often require that a consistent, mandated process is used across different projects, typically to ensure they can assess the overall risk exposure of the organization across projects. This will also be the case when organizations are seeking to develop their project management maturity using a maturity model such as P3M3 (see section 21.1.1.3).
10.3.2 Recommended risk management procedure
PRINCE2 recommends, but does not mandate, a risk management procedure based on Management of Risk: Guidance for Practitioners (Office of Government Commerce, 2010).
Figure 10.1 shows the elements of the risk management procedure described in section 10.4.
The procedure consists of five steps, the first four of which are sequential:
•identify: context and risks
•assess: estimate and evaluate
•plan
•implement.
‘Communicate’, the fifth step, operates in parallel as the outputs of any of the other steps may need to be communicated to stakeholders at any point in the process.
All the steps are repeatable. When additional information becomes available, it is often necessary to repeat earlier steps based on the new information.
10.3.3 Understand the project board’s attitude to risk
A key decision that needs to be recorded within the risk management approach is the project board’s attitude towards risk-taking. This will determine the amount of risk that is acceptable and will, in turn, help set risk tolerances.
Example of risk tolerance
A large electrical retailer would not tolerate any disruption to its core retail or warehouse systems during the peak trading period extending from November through to January. During this period, it does not allow changes to these systems unless they are needed to keep the company running.
A project would need to escalate to the project board any risk that might impact these systems during this period.
10.3.4 Project size, scale and complexity, and risk impact
Ensure that the risk management approach is appropriate not only to the project’s size, scale and complexity but also to the project’s likely risk impact. It is important that the risk management approach for a project supports effective decision-making on the project and does not create an undue burden or bureaucracy. In general, smaller, simpler projects will need correspondingly simpler risk management arrangements.
For example, on a less complex project the project manager would typically directly undertake most risk management activities. However, on more complex projects these activities might be delegated to a dedicated risk manager or risk management team. Similarly, a risk register might be held in a simple list on a whiteboard, in a spreadsheet or in a dedicated IT system. What is important is that the risk management approach is appropriate.
In determining the appropriateness of the risk management approach it is critical to consider not just the project’s cost, size, scale and complexity but also the potential scale of risk impact from the project. It is possible for projects to create impacts that far outweigh their apparent size, scale and complexity. For example, a small, simple project to replace core IT network infrastructure has the ability to stop an organization working if it goes wrong.
10.3.5 Project delivery approach
It is important that the approach to managing risk works with and supports the project’s chosen delivery approach. For example, a risk management approach that includes monthly risk review meetings is unlikely to effectively support an agile project delivery approach where deliveries may be happening every 2 weeks.
PRINCE2 does not mandate a particular format for risk management products, nor does it mandate specific timings for risk management activities. What is important is that they are appropriate for the format and pace of the project. A risk register may be written on a whiteboard and reviewed as part of a daily stand-up meeting (see section 17.5.4.2) as part of an agile delivery approach. In this context it is just as valid as risks stored in a dedicated IT system that is reviewed at a monthly meeting.
It is also important to recognize that the project’s delivery approach might work to mitigate or reinforce specific risks. For example, an agile way of working inherently ensures that customers do not inappropriately constrain and over-specify requirements at the beginning of a project, which can be a risk in a more traditional ‘waterfall’ approach. Similarly, even though agile is characterized by a high level of engagement with customers directly involved in the project, it can lead to uncontrolled changes to the agreed baseline if not managed correctly. More traditional approaches tend to reinforce the impression of ‘controlled change’, but at a risk of appearing unresponsive. What is important is that the risk management approach recognizes these inherent differences.
10.3.6 Commercial considerations
In a commercial context there may be a need for more than one risk register as some project risks could be unique to only one party, with good reasons for them not to be visible to the other party. Where a joint risk register is used, care should be taken to establish whose risk it really is, and the risk owner appointed accordingly. For example, on a fixed-price contract any cost overruns will impact the supplier’s business case, but timescale overruns will typically impact the customer’s business case.
10.3.7 Establishing a risk budget
It might be appropriate to identify and ring-fence an explicit risk budget within the project’s budget. This is a sum of money to fund specific management responses to the project’s threats and opportunities (e.g. to cover the costs of any contingent plans should a risk materialize).
The risk budget is based on the aggregate cost of all the project’s planned risk responses. For simpler projects it will usually be enough to add up the cost of all risk responses. However, for more complex projects care needs to be taken that the aggregation of the factored costs is not skewed by a small number of large risks. This is where analytical techniques, such as Monte Carlo simulation (see section 10.4.2.2) and associated software tools, can help.
As the project progresses, some of the risks previously identified will occur and others will not. New risks may be identified during the life of the project whose response costs will not have been included within the risk budget. This means that it is prudent to include a provision for unknown risks (yet to be identified) in the risk budget.
Key message
As the risk budget is part of the project budget, there may be a tendency to treat it as just another sum of money that the project manager can spend. This culture should be discouraged in favour of the risk management approach defining the mechanisms for control of, and access to, this budget.
10.4 Technique: recommended risk management procedure
In the absence of any other approach, PRINCE2 recommends the following risk management procedure, which is based on Management of Risk: Guidance for Practitioners (Office of Government Commerce, 2010); see also section 10.3.2 and Figure 10.1.
This step obtains information about the project in order to understand the specific objectives that are at risk and to formulate an appropriate risk management approach. The following will have an influence on the project’s risk management approach:
•customer’s quality expectations
•number of organizations involved and the relationships between them
•the needs of the stakeholders involved with the project
•the importance, complexity and scale of the project
•the delivery approach being used
•what assumptions have been made
•the organization’s own environment (e.g. legislative or governance requirements)
•corporate policies, standards, processes and procedures
•whether the project is part of a programme or corporate portfolio.
This information will be derived from the project mandate, the project brief and the project product description.
Appendix A, section A.24, provides the typical contents of a risk management approach.
Risks can, and should, be identified at any time during the management and delivery of the project. Any member of the project, corporate or programme management, the customer, or other stakeholder may raise an issue or risk. PRINCE2 recommends that risks are captured in the risk register as soon as they are identified.
An important aspect of identifying risks is being able to provide a clear and unambiguous expression of each one. A useful way of expressing risk is to consider the following aspects of each risk:
•Risk cause This should describe the source of the risk (i.e. the event or situation that gives rise to the risk). These are often referred to as risk drivers. They are not risks in themselves, but the potential trigger points for risk. These may be either internal or external to the project.
•Risk event This should describe the area of uncertainty in terms of the threat or the opportunity.
•Risk effect This should describe the impact(s) that the risk would have on the project objectives should the risk materialize.
The cause, event and effect relationship could also be expressed in a sentence, for example:
•Threat There is a threat that insufficient staffing capacity (risk cause) could lead to the business being unable to provide enough staff to complete user training in the planned timescales (risk event), resulting in the project taking longer than planned (risk effect).
•Opportunity If allowable under data regulations, the company could include a discount code in the email (risk event) when it renews customer details every year (risk cause), generating income to offset the cost of the regulatory requirement (risk effect).
There are various techniques that can be used to identify risks, including review lessons, risk checklists, risk prompt lists, brainstorming and risk breakdown structures.
Figure 10.2 shows a risk breakdown structure relating to financial risk. Such a structure will help to identify the appropriate risk owners to develop responses.
Examples of risk identification techniques
Review lessons
Risks are driven by uncertainty, so one of the most effective ways to reduce uncertainty is to review similar previous projects to see what threats and opportunities affected them.
Risk checklists
These are in-house lists of risks that have either been identified or have occurred on previous similar projects. Risk checklists are useful aids to ensure that risks identified on previous projects are not overlooked.
Risk prompt lists
These are publicly available lists that categorize risks into types or areas and are normally relevant to a wide range of projects. Risk prompt lists are useful aids to help stimulate thinking about sources of risk in the widest context.
Brainstorming
This enables group thinking, which can be more productive than individual thinking. However, it is important to avoid criticism during the brainstorm as this can stop people contributing. In addition to identifying risks, brainstorming can also be used to understand the stakeholders’ views of the risks identified.
Risk breakdown structure
This is a hierarchical decomposition of the potential sources of risk. Each descending level represents an increasingly detailed definition of sources of risk to the project. The structure acts as a prompt and an aid to support the project management team in thinking through the potential sources of risk to the objectives. There are numerous ways to break down risk and it may be useful to do more than one list.
For example, a risk breakdown structure could be broken down by PESTLE (political, economic, social, technological, legal/legislative, environmental), product breakdown structure, management stage, delivery step, benefits/objectives, etc.
The next step is to assess the probability of each risk and its impact. PRINCE2 recommends assessing:
•the probability of the threats and opportunities in terms of how likely they are to occur
•the impact of each risk in terms of the project objectives (e.g. if the objectives are measured in time and cost, the impact should also be measured in units of time and cost)
•the impact of the risk on the stage plan, project plan and business case
•how quickly the risk is likely to materialize if no action were taken (i.e. its ‘risk proximity’)
•how the impact of the threats and opportunities may change over the life of the project
•whether the project team is best placed to manage the risk or whether the risk needs to be escalated to the project board, any overarching programme or to a corporate body.
There are a number of techniques that can be used for risk estimations. These include probability impact grids, the expected value technique, probability trees and Pareto analysis.
Examples of risk estimation techniques
Probability impact grid
This grid contains ranking values that may be used to rank threats and opportunities qualitatively. The probability scales are measures of probability derived from percentages, and the impact scales are selected to reflect the level of impact on project objectives. The values within the grid cells are the combination of a particular probability and impact, and are determined by multiplying the probability by the impact.
A probability impact grid can be used to provide an assessment of the severity of a risk and enable risks to be ranked so that management time and effort can be prioritized. For example, the project board may set its risk tolerance at any risk with a value greater than 0.18, and it may require a proactive response for any risk with a value greater than 0.045, as depicted by the dark and medium shadings shown in Figure 10.3.
Expected value
This technique quantifies risk by combining the cost of the risk impact with the probability of the risk occurring. Expected value is useful when a tangible measure of risk is required to enable risks to be prioritized. For example, if the cost of a risk was £160 000 and its likelihood of occurrence was estimated at 25 per cent, then the expected value would be £40 000.
Probability trees
These are graphical representations of possible events resulting from given circumstances. A probability tree can be used to predict an outcome in a qualitative way when historical data is used to populate the likelihood of each circumstance happening. Probability trees assist in communicating to project participants or decision makers the likelihood of the different possible outcomes to a set of circumstances.
Pareto analysis
This technique ranks or orders risks after they have been assessed to determine the order in which they should be addressed. Pareto analysis can be used to focus management effort on those risks that have the potential to have the greatest impact on the project objectives.
A useful way of summarizing the set of risks and their estimations is to plot them onto a summary risk profile, an example of which is shown in Figure 10.4. This profile represents a situation at a specific point in time (i.e. a snapshot of the risk environment). The numbered markers in the matrix represent unique risk identifiers used in the risk register on which this is based. The risks above and to the right of the dashed risk tolerance line represent those that the organization will not tolerate except under special circumstances. In the depicted case, the project manager would refer risks 1, 3 and 4 to the project board.
Tip
If using a three-by-three or five-by-five probability impact grid results in too many risks clustering around medium probability and medium impact, consider using a four-by-four grid to force high/low risk assessments.
The summary risk profile can also be used to show trends. For example, risk 6 may have previously been recorded as ‘low probability, high impact’, indicating that its likelihood of occurring is increasing.
The combined effect of the individual risks needs to be understood to determine if the overall ‘risk exposure’ of the project remains within the risk appetite determined by the organization and as interpreted and applied by the project board. If the risk exposure is greater than the organization’s risk appetite, then control actions will need to be planned in response.
In line with PRINCE2’s continued business justification principle, the justification of the project should be evaluated in the context of the risk exposure. There is no such thing as a risk-free project and understanding how risk exposure compares with the risk tolerance informs how much effort is put into risk responses. The risk tolerance will be set by the project board based on the organization’s overall risk appetite. Risk exposure can, and should, be assessed both before and after any planned risk responses.
Definition: Risk appetite
An organization’s unique attitude towards risk-taking that in turn dictates the amount of risk that it considers acceptable.
Definition: Risk tolerance
The threshold levels of risk exposure that, with appropriate approvals, can be exceeded, but which when exceeded will trigger some form of response (e.g. reporting the situation to senior management for action).
Tip
Remember that risk appetite, risk exposure and risk tolerance are related to each other, but are not the same.
There are two main risk evaluation techniques: risk models (such as Monte Carlo simulation) and expected monetary value.
Examples of risk evaluation techniques
Risk models
Risk models, such as Monte Carlo simulation, enable ‘what if’ scenarios to be run using random numbers to determine whether each risk within a given range occurs. The simulations are repeatedly run to predict the ‘average’ level of risk to the project’s timescale or cost. The scenarios can also be used to model extreme cases (e.g. if nearly all the risks occur).
Expected monetary value
This technique takes the expected values of a number of risks and sums them to arrive at an overall value. It provides a quick and easy assessment of a group of risks to understand their combined effect. Threats are represented as a negative impact and opportunities as a positive impact. An example is shown in Table 10.2.
Response options |
Use |
Avoid a threat Exploit an opportunity |
This option is about making the uncertain situation certain by removing the risk. This can often be achieved by removing the cause of a threat, or by implementing the cause of an opportunity. This option may be adopted for no extra cost by changing the way the work is planned. More often though, costs will be incurred in order to remove all residual risk for threats and opportunities. Where costs are incurred these must be justified (i.e. the cost of response is warranted to make the situation certain). |
Reduce a threat Enhance an opportunity |
This option involves definite action now to change the probability and/or the impact of the risk. The term ‘mitigate’ is relevant when discussing reduction of a threat (i.e. making the threat less likely to occur and/or reducing the impact if it did). Enhancing an opportunity is the reverse process (i.e. making the opportunity more likely to occur and/or increasing the impact if it did). Again, because this option commits the organization to costs for reduction/enhancement now, response costs must be justified in terms of the change to residual risk. |
Transfer the risk (threat or opportunity) |
Transfer is an option that aims to pass part of the risk to a third party. Insurance is the classic form of transfer, where the insurer picks up the risk cost, but where the insured retains the impact on other objectives (e.g. time delay). Transfer can apply to opportunities, where a third party gains a cost benefit but the primary risk taker gains another benefit, but this is not a commonly used option whereas transfer of threats is commonly used. Once again, the cost of transference must be justified in terms of the change to residual risk; is the premium to be paid worth it? It is important to note that some elements of risk cannot be transferred, although an organization may choose to delegate the management of the risks to a third party. |
Share the risk (threat or opportunity) |
Share is an option that is different in nature from the transfer response. It seeks multiple parties, typically within a supply chain, to share the risk on a pain/gain share basis. Rarely can risks be entirely shared in this way (for example, the primary risk taker will always need to protect its brand and reputation), but this can be a successful way of encouraging collaboration on risk management activities, particularly in programmes and projects. |
Accept the risk (threat or opportunity) |
The accept option means that the organization ‘takes the chance’ that the risk will occur, with its full impact if it did. There is no change to residual risk with the accept option, but neither are any costs incurred now to manage the risk, or to prepare to manage the risk in future. An example would be the risk to profitability as a result of currency fluctuations. An organization may decide to take the chance and not engage in any hedging or other provision to protect margins from wide variation in rates. This option would not be appropriate if the risk exposure exceeded the risk tolerance threshold for the organizational activity in question. Note that in a case such as currency fluctuations where the impact could be positive or negative, this is actually two risks, because a risk is the relationship between the uncertain event and the impact of that event. There is a risk leading to loss (threat) and a risk leading to gain (opportunity). Framing the uncertainty as two risks allows for different responses to each part. |
Prepare contingent plans (threat or opportunity) |
This option involves preparing plans now, but not taking action now. Most usually associated with the accept option, preparing contingent plans in this instance is saying: ‘We will accept the risk for now, but we’ll make a plan for what we’ll do if the situation changes.’ This option applies equally to other responses and is often referred to as a ‘fallback’ plan (i.e. what we will do if the original response does not work). Fallback plans apply to all other strategies, even avoiding a threat and exploiting an opportunity, because the plan to avoid/exploit may not be successful despite good intentions. This option is important because it incorporates future managerial flexibility for a committed cost that is smaller than investing in more proactive strategies. This does not mean that investing now to respond to a risk is wrong, but such investments do need to be cost-justified as previously mentioned. |
The plan step involves identifying and evaluating the appropriate risk response to remove or reduce threats, and to maximize opportunities. Typical risk responses are summarized in Table 10.3. If the risk falls within the tolerances set for the project, the project manager decides on the appropriate response; otherwise the decision is escalated to the project board (see Figure 10.4 for an example of risks exceeding set tolerances).
If a threat is reduced rather than removed, the remaining risk is called the ‘residual’ risk. If the residual risk is significant then it may be appropriate to select more than one risk response.
In some cases, implementing a risk response will reduce or remove other related risks. It is also possible that the responses to risks, after they have been implemented, will change some aspect of the project. This in turn may lead to secondary risks (i.e. risks that occur as a result of invoking a risk response). It is essential that these are identified, assessed and controlled in the same way as the initially identified risk.
Tip
Review lessons from previous similar projects when planning risk responses. This will help in identifying the range of responses available and in evaluating how effective they are likely to be.
Key message
It is important that the risk response is proportional to the risk and that it offers value for money.
It is important that risk responses balance the cost of implementing the response against the probability and impact of allowing the risk to occur. One way of assessing this is to compare the cost of the risk response with the difference in the expected monetary value of the risk before and after the risk response. If the cost of the risk response is lower than the reduction in the expected monetary value then it is worth undertaking the risk response. However, it is always worth bearing in mind the overall effect of all risk response activities on the project team in terms of moving their focus away from delivering the project on to risk response actions.
Any chosen response needs to be built into the appropriate level of plan. For more significant risks it may be appropriate to put in place not only early-warning indicators to identify whether the risk is likely to materialize, but also plans for managing the risk should it occur.
Consideration should also be given to the effect the possible responses could have on:
•the project plan, management stage plan and work packages
•the business case
•corporate, programme management or the customer.
The risk response needs to identify the most appropriate body to manage a risk (or issue). This may not be the project team, especially if:
•the project team do not have within their scope of influence the ability to implement an appropriate risk response
•realization of risk will materially impact the project’s business justification
•the project is part of an overarching programme and it would be more appropriate for the risk to be managed at programme level (e.g. if a specific project identifies a risk that is common across projects within the programme)
•implementation of a risk response will cause the project to exceed agreed tolerances, either within a particular management stage or overall
•reporting of the risk to a corporate body is required by the corporate risk policies or procedures. This might typically occur in a regulated organization where certain risks might either be reportable by the organization, or where realization of the risk might cause a breach of a regulatory condition.
Escalation would first be to the project board. Depending on the risk tolerance, escalation might also be to the overarching programme, corporate body or customer.
Escalating risks is good practice and should not be seen as failure. The earlier that risks are escalated, the more time is available to implement any corrective actions. The types of response are explained further in Table 10.3.
Tip
Do not forget that an opportunity can be rejected. Not all opportunities may be taken up as there could be circumstances such as timing or cost which would have a negative impact on the project goals.
Planned risk responses need to be actioned, their effectiveness monitored and corrective action taken where responses do not match expectations.
It is critical to ensure that the owner and actionee are identified and agreed for each risk:
•Risk owner A named individual who is responsible for the management, monitoring and control of all aspects of a particular risk assigned to them, including the implementation of the selected responses to address the threats or to maximize the opportunities.
•Risk actionee A nominated owner of an action to address a risk. Some actions may not be within the remit of the risk owner to control explicitly; in that situation there should be a nominated owner of the action to address the risk. He or she will need to keep the risk owner apprised of the situation.
In many cases, the risk owner and risk actionee are likely to be the same person. The risk owner should be the person most capable of managing the risk. Allocating too many risks to any one individual should be avoided.
Examples of a risk owner and risk actionee
Risk owner
There is a threat that a key supplier may fail, which might impact a project’s ability to deliver on time to a customer. The commercial director has been appointed as the risk owner.
Risk actionee
A number of risk responses have been identified and selected. One of the risk responses (prepare contingent plans) is to identify possible alternative suppliers who have the capacity to undertake the affected work packages at short notice, and to obtain some quotes from them. The procurement manager is the risk actionee for this particular risk response.
Communication should be undertaken continually. The ‘communicate’ step ensures that information related to the threats and opportunities faced by the project is communicated both within the project and externally to stakeholders. Risks are communicated as part of the following management products:
•highlight reports
•end stage reports
•end project report
•exception reports.
Care should be taken in using these reports to communicate risks with external stakeholders and reference should be made to the communication management approach for the most appropriate method.
There are numerous other communication methods (e.g. bulletins, notice boards, dashboards, information radiators, discussion threads, briefings) that could be considered alongside the PRINCE2 management products.
A number of aspects of communication should be recognized and addressed if risk management is to be effective:
•A project’s exposure to risk is never static: effective communication is key to the identification of new risks or changes in existing risks. This depends on the maintenance of a good communications network, including relevant contacts and sources of information, to facilitate the identification of changes that may affect the project’s overall risk exposure.
•Effective risk management is dependent on participation, which is dependent on effective communication.