Risk management

Note

This web page only addresses risk management in international development projects at Global Affairs Canada. Get general information on risk management in the Government of Canada.

Global Affairs Canada is currently undergoing a review of all of its risk management tools with the objective of streamlining and harmonizing its risk management processes across all programming areas in foreign affairs, trade, and development. This initiative will increase the department’s effectiveness in managing and monitoring risk.

Global Affairs Canada uses the internationally recognized definition of risk as the effect of uncertainty on objectives. In this context, risk is expressed as the likelihood and the impact of an event occurring with the potential to affect the achievement of development outcomes.

What is integrated risk management (IRM)?

Integrated risk management is a continuous, proactive and systematic process to understand, manage, and communicate risk across the organization. The process requires making strategic decisions that contribute to the achievement of an organization’s overall corporate outcomes.

Why should IRM be used in international development?

Integrated Risk Management:

The Authorized Programming Process (APP) Risk Table

Implementing partners seeking funding for development projects need to fill-out a risk table as part of the APP application process.* The risk table provides key information for the identification and management of risks. It will be used for the initial assessment of the project, and should be updated throughout the life of the project to ensure risks are continually identified and addressed. 

Instructions on how to complete the risk table are presented below.

Risk table example
Risk
Number
Risk definition: What are the greatest risks to your initiative?Logic model: Copy the result statement that is most directly affected by the risk.Risk response: What will you do to respond to this risk (i.e. lower its potential impact and/or likelihood of occurrence)?
Example:

1
Example:

There is a risk that the implementation and monitoring capacity of the ABC civil society organization with whom we are partnering will affect our ability to achieve expected results in food security.

Likelihood: 2
Impact: 3
Example:

Immediate outcome: Increased capacity of the local population of the targeted region to manage subsistence agriculture.
Example:

  • An institutional assessment of ABC civil society organization will be conducted before implementation;
  • Implementing partner will provide training to develop and improve the implementation and monitoring capacity of ABC civil society organization;
  • Increased monitoring of outcome indicators will be conducted to assess progress achieved and address needs as they emerge;
  • Hire an external monitor.

The five-step risk management cycle

Global Affairs Canada follows a five-step risk management cycle for development projects based on the department’s Integrated Risk Management Policy, Treasury Board Secretariat guidance and international risk management standards (ISO 31000):

Graphic illustrating the paragraphs below

Important to note is that this cycle is repetitive. Once Step 5 is performed, the process returns to Step 1. Regular monitoring (Step 5) must be conducted which could potentially lead to revisions of risks, responses, and risk levels (Steps 1-4). See Step 5 below for more information.

Step 1: Identity and Define Risks

Based on a scan of your internal and external environment (i.e. project operations and programming context), identify the key risks that could affect the achievement of the expected outcomes. Your risks should take into consideration the integration of environment, gender equality, and governance themes where relevant.

APP Risk Table – Risk Definition column: Identify three to six key risks. Briefly describe each using a risk definition, indicating the risk event as well as the potential negative consequences. These should be the greatest risks in terms of likelihood and potential impact on the achievement of results.

An example of a risk definition: “There is a risk that the political situation/elections could affect implementation with potential loss of support for the project and its expected results.” In this example, the “political situation/elections” is the risk event, and the effect on the “implementation with potential loss of support for the project and its expected results” is the potential negative consequence.

Important to note is that “risks” describe uncertainties that could affect expected outcomes. “Risks” are not known issues. For example, if you know five people who work on your project are retiring next year, this is a known issue, not a risk. However, if it is not known whether you will have enough staff with the requisite skills to meet your expected results, this could be a capacity or human resources risk.

Only identify risks relevant to programming, not to the country or geographical area as a whole. For example, do not include events that could cause difficult circumstances to the people living in a particular area but would not affect programming.

How to describe risks

In development programming at Global Affairs Canada risks are classified into three categories: internal, external and overlapping. This approach is useful for thinking about and defining possible sources of risk, but it is not necessary to use these categories when filling out the APP risk table.

Internal risks: These are internal operational issues related to systems or processes over which there is significant direct control and accountability. Examples include: 

External risks: These are contextual risk factors over which there is little or no control, and which could hinder the achievement of results. These factors could be political or social (e.g. civil strife, elections, gender inequality, security situations, economy), associated with a natural disaster (e.g. earthquake, floods) or related to partner(s) that may be unable to meet the expected results. Examples include:

Overlapping risks: These exhibit both internal and external qualities over which there is limited control (e.g. reputation, budgets, funding or strategic direction). Examples include:

Step 2: Determine Effect of Risk on Outcomes

Review the immediate, intermediate and ultimate outcome statements in your Logic Model (LM). Ask yourself the question, “which outcomes could potentially be affected by the noted risk?”

APP Risk Table – Logic Model column: Copy-and-paste the results statement that is most directly affected by each risk (you can simply enter the Logic Model statement number and level to save space, if you wish). If the entire project is affected by the risk, enter the ultimate outcome. However, if you can specify lower-level outcomes in the LM, it would help to target response measures.

Step 3: Identify Risk Responses

APP Risk Table – Risk Response column: Provide a brief summary of the risk response approaches to be used to manage or prevent the risk event. Ensure that the risk responses are financially and technically feasible, and well-designed to reduce the impact and/or likelihood of the identified risks. The responses should also be realistic in terms of timely implementation in reaction to needs and they should be action-oriented, and comprehensive.

Examples:

Step 4: Assess Level of Risks

APP Risk Table – Risk Definition column: For each risk, establish the residual risk level. Residual risk is the level of risk after risk responses have been taken into account. State the level of likelihood that the risk will occur and its potential impact using the four-point scale described below. Include this information in the Risk Definition column. For example, “Likelihood: 2; Impact: 3.” Typically, levels for likelihood and impact will be determined separately for each risk using a method that promotes unbiased results (e.g. through a voting session, or an online survey).

Graphic described below
Details of the Graphic: Likelihood criteria and Impact criteria

Likelihood criteria

Likelihood that the risk event will occur in the next year:

  • 1: Very unlikely (0% - 20%)
  • 2: Unlikely (20% - 50%)
  • 3: Likely (50% - 80%)
  • 4: Very likely (80% - 100%)

Impact criteria

Impact on programming if risk event occurs:

  • 1: Very limited impact on development programming operations and outcomes. Consequences can be managed under normal operating conditions.
  • 2: Limited impact on development programming operations and outcomes. Consequences can be managed with limited additional resources and/or managerial effort.
  • 3: Moderate impact on development programming operations and outcomes. Consequences can be managed with moderate additional resources and/or managerial effort.
  • 4: High - Significant impact on development programming operations and outcomes. Senior management required to make major adjustments to plans and/or resources allocations.

Step 5: Monitor, Update and Report

As time passes, the project’s operational context will likely change as will the risks to the achievement of expected results. Risks may disappear or shift, and new risks may arise, which will necessitate adjusting risk definitions and the corresponding risk responses.

As such, risk tables must be reviewed regularly. The frequency of these reviews should be in line with agreements made with Global Affairs Canada and its partners. As well, risk tables should be reviewed frequently (e.g. quarterly) in instances where there are a number of significant risks. Risks should always be reassessed and the corresponding risk tables updated if the country context changes abruptly (e.g. a coup d’état) or if the programming environment (e.g. programming priorities) changes.

Reviews do not necessarily require that the entire risk table be re-done from scratch, but a scan of the various elements (country and operational context, expected results, risks and responses, risk levels) should be conducted to ensure this information is current and fitting. Risk responses should also be tracked for effectiveness, and adjusted when necessary.

Monitoring risks involves identifying whether the likelihood of each risk occurring, or its potential impact, is increasing or decreasing. If a risk trend proves to be unstable, adjust the risk response(s) accordingly.

Aside from updating risk tables, it is important to keep tabs on situations that could become risks to the initiative and bring forth this information in a timely manner.

* APP Risk Tables are found within the associated APP application forms. You can find a separate copy of a fillable Risk Table here, complete with instructions: APP Risk Table and instructions

Date Modified: