The Teal Book: Part E
The purpose of risk management is to ensure the objectives of a portfolio, programme or project are more likely to be achieved. It considers complexity, uncertainty, unexpected events and threats and opportunities from undertaking the work, using the solution, and from the external environment.
Risk is a natural part of project delivery. Portfolios, programmes and projects deliver change, and change can introduce uncertainty and complexity, that can threaten objectives. This includes:
Uncertainty can also open opportunities that could be missed if not considered in advance. This includes:
Risk management comprises the identification, assessment and response to a risk which either threatens the success of the work or represents an opportunity to be exploited. The aim of risk management is ensuring the objectives are likely to be achieved.
Risks can be managed within the current scope of a portfolio, programme or project or might require a change to keep the work viable. In some cases, the response to a risk can lead to a change in the delivery strategy or plan. If a threat is unacceptably high it can lead to the work being terminated.
Risk management is a continual activity that should be performed throughout the life of a portfolio, programme or project, and should be integrated with the wider organisational approach to risk management and to health, safety and security (see Chapter 7: Health, safety and security).
The Project delivery glossary defines risk as:
Risk is the effect of uncertainty on objectives.
It relates to an uncertain event which, if it occurs, has an impact on the achievement of an objective.
Risks can be positive or negative:
A risk combines the probability of an event happening, with the scale of its impact. This is often presented in a risk matrix.
A risk can be described using 3 characteristics:
Risk causes can be specific, such as a severe storm, or variable over time, such as inflation or commodity prices. If a risk relates to a variable, assumptions should be documented and the trigger point for action agreed.
Risk responses require action to be taken to manage the risk in line with the risk appetite. For threats, this can range from removing or mitigating the root cause, reducing the impact and/or reducing the likelihood of it happening. For an opportunity, similar actions can be taken to exploit the situation. Responses often combines a mix of approaches. A risk response can lead to changing the plan or putting in a risk control. For example, sprinkler systems are a ‘risk control’, used in buildings to limit fire damage and loss of life, with ongoing checking to ensure they work.
Risk, like time and cost (see Chapter 16: Planning) is a constraint within which the work should be completed within each manager’s defined risk tolerance. If this tolerance is exceeded, it triggers escalation, for example, reporting the situation to a more senior manager for a decision or action. Typically, there are tolerances for the overall portfolio, programme or project, for significant work packages or individual risks.
Monte Carlo analysis and probability-based modelling and estimation can be used to quantify aggregate risks, usually as part of developing a portfolio plan or business case (see theGreen Book (requires sign in) and Guidance on cost estimation (requires sign in)).
Some areas of risk, for example external events, can be beyond the power or capability of the portfolio director or senior responsible owner to control or influence. They should still be considered when planning and justifying the work.
People in a project delivery role need an awareness of risk management practices, including how to identify and monitor risks systematically, deciding how to respond to those risks and implementing the planned responses.
The portfolio director, in a portfolio, or the senior responsible owner, in a programme or project, has overall accountability for the effective management of risk through the life cycle. They are responsible for ensuring a robust risk management framework is in place, that it works effectively and enables a good understanding of the impact of risks on the objectives, portfolio plan (for a portfolio) or business case (for a programme or project) and on the overall viability of the work. When a portfolio plan or a business case is approved and work authorised, the portfolio director or senior responsible owner should ensure that this is done in full knowledge and understanding of the associated risks, and that these are then managed appropriately through the life cycle.
The portfolio manager or programme or project manager is responsible for designing and implementing the respective risk management framework and for ensuring that the portfolio director or senior responsible owner understands the overall risk profile. The framework should include arrangements for managing and where necessary escalating risks in line with agreed risk tolerances, and the portfolio, programme or project manager should ensure that these arrangements work effectively through the life cycle.
Depending on the scale and complexity of the work, there could be a dedicated risk manager or support office manager with the responsibility for managing risk on behalf of the portfolio, programme or project manager. If a dedicated risk manager is not necessary, the portfolio, programme or project manager, as appropriate, should undertake the role. For large work packages, the work package manager normally undertakes the role for their own work package but can be supported by a risk manager or support office manager.
In general, any person with a legitimate interest may raise a risk and is known as the identifier. In practice a risk normally originates from the sponsoring body or the delivery team itself, including suppliers. Risks can be identified in advance, for example in planning workshops, or during the course of the work when a person recognises the threat or opportunity.
Each risk should have a risk owner, who is a named individual responsible for planning, implementing and monitoring the response. The risk owner can be supported by people helping plan, implement or monitor the response. A risk owner needs to be someone who can manage a given risk either due to their position, authority, or technical or other experience. For risk management to be effective, care should be taken to avoid allocating a large number of risks to a single owner. As the nature and magnitude of risks can change when more information becomes available, the ownership of a risk may be reassigned to a more appropriate person, with a suitable handover and supporting information.
More detail on the risk and issue technical competency and how this relates to each project delivery role can be found in the Project delivery capability framework.
Risk management should not be limited to cost and time. It should cover all aspects of the plan (see Chapter 16: Planning), such as:
The delivery strategy and plan need to be designed to consider risks throughout the development, creation, use and disposal of a solution, such as the approach to procurement and the techniques and methods used to design and build or develop the solution. For example, iterative approaches or piloting are often used if requirements are not sufficiently understood initially.
Risk is an integral part of planning where the aim is not only to produce an achievable plan but one which can be delivered at an acceptable level of risk.
Contingency for the realisation of threats and their impact on time should be placed in the plan (see Chapter 16: Planning) so that slippage is unlikely to have a disproportionate impact on the delivery of outcomes and the achievement of objectives. Techniques that can help decide on where to put contingency (also called buffers) include:
Contingency for the cost of risks occurring should be considered in a risk budget, a contingent part of a portfolio’s, programme’s or project’s overall budget (see Chapter 29: Finance). It is allocated to fund responses to threats and opportunities. The risk budget should be set and managed to reflect the context, scale and complexity of the work. To develop a risk budget:
Simulation can also be used to determine those activities prone to overspends and the amount of contingency to be held.
Different options carry different levels of risk. It is important to evaluate and balance risks against the social costs and social benefits for each option.
Investment decisions need to be taken in phases to take account of changes in the risk profile. This is why programmes are undertaken in tranches and projects in stages.
Risk is also fundamental to how portfolios are constituted, prioritised and rebalanced in line with overall risk levels and risk appetite.
Information on assessing options is included in the Government Functional Standard on Analysis and its supporting documentation, such as the Aqua Book (requires sign in).
Openness and collaboration are important aspects of effective risk management. Visibility of current, emerging and closed risks can prompt the identification of related risks, and collaboration among the team members can lead to new perspectives on risks and creative responses. Risk information should always be open and accessible to the core team, but care should be taken when sharing it more widely, both for safety and security reasons (to avoid potential vulnerabilities being exploited by malicious actors, for example) but also to ensure any risk information shared is presented in context and communicated appropriately. (See Chapter 26: Stakeholder engagement).
When managing risk, the context in which the work is undertaken and the solution operated needs to be understood. This helps aspects such as:
The starting point for most people, when developing their risk management framework, is identifying the sponsoring body’s or organisation’s risk appetite and risk management policies and procedures. The Orange Book (requires sign in) outlines the principles of good risk management across government departments and their arm’s length bodies. Typically:
Risk appetite is the level of risk that an organisation, or part of it, is willing to accept in pursuit of strategic objectives.
The sponsoring body, portfolio director or senior responsible owner and associated boards need to understand the risk appetite at the outset. This influences the design of the risk management framework.
Government Major Projects Portfolio and Risk potential assessments
Programmes and projects joining the Government Major Projects Portfolio, must have a Risk potential assessment and validated by HM Treasury, National Infrastructure and Service Transformation Authority and where appropriate central function teams. The completion of the assessment supports the understanding of the strategic risk potential.
Risks should be managed using an agreed and documented management framework which describes how risk management is to be done in the respective portfolio, programme or project.This information can be recorded in a single document or as a separate document that focusses only on risk. Different terms are used to for these plans, including risk strategy, risk management strategy, risk plan and risk management plan.
When developing the framework, the risk appetite of the sponsoring organisation and the risk profile of the work itself should be considered, taking account of potential scale, complexity and other factors which can drive risk, such as sensitive policy or new technology. This should be used to agree the tolerances set.
The risk management framework should be developed when a portfolio, programme or project is initially set up and should be maintained or enhanced as work proceeds through its various life cycle phases to ensure it remains effective. It should be part of the overall governance and management framework (see Chapter 4: Governance and management) and include:
The important products include the risk matrix (see 20.6.2.3 on defining the risk matrix), risk response categories (see 20.6.2.4 on deciding the risk response categories) and risk register (see 20.6.2.5 on preparing the risk register).
The risk management framework should be appropriate to the context and nature of the work and can change as work proceeds to reflect the type of solution proposed, its complexity and external influences. For example, the framework might require specialist approaches such as sensitivity analysis, simulation and scenario modelling (such as Monte Carlo analysis).
The risk management framework should include how time and cost contingency is managed and how their tolerances are set at different management levels, for example at a portfolio, programme, project or work package.
A risk matrix is a useful tool for understanding how risks compare. It shows the relative position of each risk in terms of the likelihood of the risk occurring and the impact on objectives if it does occur.
Figure 20.1 is a simplified example of a risk matrix showing threats plotted on it. The size of each plotted risk can represent factors such as the cost of treating the risk or impact on benefits. Risk ratings in each segment should be chosen to enable comparison when tabulated in a risk register. An equivalent risk matrix can be made for opportunities.
Different parts of the work can have different risk matrices, showing different perspectives. For example, what is perceived as a high risk by a work package manager, although valid, might not appear so at a programme board level.
The impact dimension of the risk matrix may be qualitative or quantitative, for example to help understand cost, benefit or time risks and their potential cumulative effect on the work. The likelihood dimension can use a score or percentage probability.
Scales do not need to be linear. on-linear scales reduce the tendency to plot risks at a middle point.
The risk matrix needs to be tailored to suit the work. For example, what is considered ‘critical’ in the context of a nuclear power solution might be different to what is considered critical when changing business processes in a government organisation.
The most commonly used risk response options are described in Table 20.1.
| Response | Risk type | Description |
| Avoid | Threat | Avoiding the threat by removing or preventing the risk, often done by removing or working around the cause(s) of the risk |
| Treat | Threat | Treating the risk by:
|
| Transfer | Threat | Transferring the threat by relocating the impact of the threat or the entirety of the threat to another project or party |
| Accept | Threat | Tolerating the threat by accepting the impact of the threat if it materialises |
| Share | Threat or opportunity | Sharing the threat or opportunity by transferring part of the impact to one or more projects or parties |
| Exploit | Opportunity | Exploiting the opportunity by implementing actions to remove uncertainty and ensuring the opportunity happens |
| Enhance | Opportunity | Enhancing the opportunity by implementing control actions to increase the probability or impact of an opportunity |
| Reject | Opportunity | Accepting the probability and impact of the opportunity with a deliberate decision to take no further actions to enhance or exploit the opportunity |
As part of the risk management framework, it is important to capture and maintain information on identified risks at both an aggregate and individual level. This is done through a risk register and includes details such as:
Proprietary or organisational tools usually prescribe similar data to provide consistency and collation of risks.
Risk management comprises a set of behaviours and activities undertaken throughout the life of a portfolio, programme or project. The activities are iterative and involve:
This applies to individual risks and as an aggregated risk profile.
Good and frequent communication among the team members also supports effective risk management. Working collaboratively tends to surface more risks than working in isolation and promotes more creative and cost-effective responses.
The approach to risk management should be defined including any processes, methods, tools and techniques to be used. This forms part of the overall governance and management framework for the work (see Chapter 4: Governance and management).
See 20.6.2.2 for detail on developing the risk management framework. The framework should be maintained to address relevant feedback from its use.
This activity looks at risks in aggregate to gain an overall view of the risks being faced and their impact on the objectives. This could result in consolidating or splitting risks if necessary, or the reassignment of owners. The activity can also include the provision of support to risk owners, if needed.
Looking at the risks in aggregate supports:
If it becomes a possibility that work may no longer be viable, the work should be considered for an immediate review, significant revision and possible termination. See Resetting major programmes for guidance on steps to take when a significant revision is needed for large programmes and projects.
Aggregate risk should be reported on the risk register and managed through the steps in 20.6.3.4 on identifying a risk to 20.6.3.8 on closing the risk.
Throughout the life cycle of a portfolio, programme or project, risks need to be reported on regularly so that the portfolio director or senior responsible owner and their respective boards have an up-to-date understanding of the aggregate risk and significant individual risks which need their attention. Risk managers and owners need to understand the tolerances set for them and either report or escalate risks to the appropriate person or body if that tolerance has, or is likely to be, exceeded. Reporting needs to be kept under review to ensure that people are receiving the information they need when they need it.
The context and nature of the work may change throughout the life cycle. Therefore, the risk management framework should be under continuous review to ensure it remains effective.
A risk can be identified using various structured and unstructured techniques.
Reviewing lessons from similar portfolios, programmes and projects helps identify the nature of threats and opportunities that have affected comparable work. As well as lessons captured by the organisation, the National Infrastructure and Service Transformation Authority and National Audit Office who regularly produce reports and case studies from across government.
When planning, critically assess what could go wrong at each phase and the impact that might have. Focus on known areas of risk, such as systems integration, and data migration, as well as risks specific to the work being undertaken.
For each output that makes up the overall solution, assess what could malfunction in operation, including health and safety aspects, and what impact that could have.
Brainstorming and facilitated workshop techniques can bring together the views of stakeholders and the wider team. A facilitated risk workshop is particularly useful at the beginning of a programme and project and at the beginning of each phase. They can also be used periodically throughout the life cycle.
Breakdown structures can also enable teams to examine the environment in a structured way and identify sources of risk. PESTLE, which prompts consideration of political, economic, social, technological, legal and environmental factors, is commonly used alongside product breakdown structure and the project delivery life cycle.
Sensitivity analysis can be used to identify the variables which have significant impact on outcomes and benefits. Whilst, structured scenario planning and simulation can be used to explore different plausible futures, test plans and assumptions, and show the impact on time, cost, benefits and overall risk exposure.
Use risk checklist prompts to help identify sources of risk, such as:
Assumptions also need to be considered. Assumptions are made when an unknown event or measure is taken as true or certain to happen for the purposes of planning, but without full supporting evidence. Significant assumptions should be treated as risks. Assumptions are structured in a slightly different way:
When a risk is identified, the risk manager should verify it as a risk and assign a risk owner.
Each risk should be described at an appropriate level of detail (for example, work package or project level) where it can be assigned to, monitored, and managed by a single owner.
The risk owner should validate the information the identifier provided about the risk and then investigate it further. A range of approaches (qualitative and quantitative) should be considered for assessing a risk. When assessing an individual risk, the risk owner and relevant stakeholders should seek to understand aspects such as:
This information should be recorded and updated in the risk register (see 20.6.2.5 on preparing the risk register).
When deciding how to respond to a risk, it is important that the response is proportionate and represents value for money, balancing the cost of the response against the probability and impact of the risk occurring and the resulting likely loss or benefit. Responses to a risk, if approved, need to be built into the plan for the work, and might require contingency provision in the budget or buffers for time. See 20.6.2.4 for examples of risk response categories.
Responses do not always fully eliminate the impact or probability of a risk, and there is often some residual risk.
The Project delivery glossary defines residual risk as:
The risk remaining after the risk response has been applied.
Each response should be recorded in the risk register and assessed to understand the residual risk and whether the reduction is acceptable or if more action is needed to bring it within tolerance. The impact of a risk response on other risks in the register also needs to be understood as sometimes responding to one risk can affect other risks.
The impact of a risk response on the definition of the plan, solution design and management documentation needs to be considered. If any changes are required to these, this could require a formal change request to be initiated (see Chapter 22: Change control).
Once a risk response and set of actions have been approved, these need to be implemented. The risk owner should assign actions to one or more named individuals, known as the action owner(s) to undertake this work.
A risk should be monitored to verify the effectiveness of the risk responses and risk controls. The risk status should be reported to those who need to know as part of formal risk reporting and escalated sooner to the relevant manager if urgent action is needed. Preventative or corrective action is needed if a risk response or risk control is not having the desired effect: this could also require the plan to be updated (see Chapter 16: Planning). A significant change to the plan would require a change request to be initiated (see Chapter 22: Change control).
As a result of monitoring, risk responses might need to be changed. This could be because the initial response had insufficient effect or because the risk itself has evolved. For example, an initial response to reduce the impact of a threat might bring the risk within tolerance and so the response is to accept it.
If a risk happens then it becomes an issue and needs to be managed as such (see Chapter 21: Issue management). The relationship between risk management, issue management and change control is shown in Figure 21.1.
The risk register is a primary source of management information used in reporting (see Chapter 18: Reporting) and should be updated on an ongoing basis, so it reflects the current understanding of the prevailing threat or opportunity.
A risk should be closed if it has been avoided successfully, its proximity has passed or a risk control is no longer needed. It should also be closed if the risk has happened and is being managed as an issue (see Chapter 21: Issue management). Risks should be closed through an agreed procedure such as from an appropriate manager in the team.
A closed risk should be kept on the risk register, identifying when and why it was closed and by whom, as this information is important for maintaining traceability (see Chapter 23: Traceability management) and when conducting lessons learned reviews (see Chapter 38: Learning from experience) . A risk may be reopened if it re-emerges.
Once the work has been completed and risk management is no longer needed, the risk management framework should be merged into the management framework for the solution or closed, transferring open risks to an ongoing risk owner if necessary, and retaining information and data in accordance with the sponsoring organisation’s information retention policy (see Chapter 24: Information and data management).
Page permissions updated for public launch.
First published for closed beta consultation.