¶¶ÒùÊÓƵ

Language selection

Search

Risk management in international development projects

Note

This web page only addresses risk management in international development projects at ¶¶ÒùÊÓƵ. Get general information on .

¶¶ÒùÊÓƵ 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.

¶¶ÒùÊÓƵ 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:

Theory of Change and Risk Management

Every project is based on a theory of change: the assumptions, risks and contributing factors that explain how activities will lead to the expected ultimate outcome. Instead of the explanation of the results themselves, the content should focus on the linkages and assumptions, including key risks and response strategies designed to mitigate those risks.

Be sure to note at every level of your theory of change how your gender equality analysis is reflected. Also note where key findings of your human rights analysis and environmental analysis informed expected results and/ or the assumptions behind them.

The five-step risk management cycle

¶¶ÒùÊÓƵ 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.

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 ¶¶ÒùÊÓƵ risks are classified into three categories: internal, external and overlapping. This approach is useful for thinking about and defining possible sources of risk.

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

In drafting the immediate, intermediate and ultimate outcome statements, ask yourself the question, “which outcomes could potentially be affected by the noted risk?”

If the entire project is affected by the risk, reflect it as part of the ultimate outcome. However, if you can specify lower-level outcomes, it would help to target response measures.

Step 3: Identify Risk Responses

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

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. 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, the risk analysis must be reviewed regularly. The frequency of these reviews should be in line with agreements made with ¶¶ÒùÊÓƵ and its partners. As well, risk analysis 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 consequences/ responses 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 analysis 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 the risk analysis, it is important to keep tabs on situations that could become risks to the initiative and bring forth this information in a timely manner.

Partners should report on risk as part of their regular project reporting in line with the reporting requirements outlined in their agreement with ¶¶ÒùÊÓƵ. For further guidance, see the

Report a problem on this page
Please select all that apply:

Thank you for your help!

You will not receive a reply. For enquiries, please .

Date modified: