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?
- Aid effectiveness—Global Affairs Canada is recognized by the international community for its capacity to work effectively in high-risk environments. Using risk management, the department is more able to make informed decisions, which in turn reduces risk and helps ensure that development projects and programs achieve their expected results. In this way, IRM supports the value-for-money expectation that TBS sets.
- Good management—The Treasury Board Secretariat (TBS), through its Management Accountability Framework (MAF), the Office of the Auditor General of Canada and the Development Assistance Committee of the Organisation for Economic Co-operation and Development all highlight the importance of scanning for new risks; assessing risks on likelihood and impact; developing risk response strategies; and identifying accountabilities for managing, reporting and monitoring risks.
Integrated Risk Management:
- Contributes to a risk-aware culture;
- Provides a systematic approach to risk management;
- Proposes simpler, more effective risk management practices;
- Continually scans for new risks.
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 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)?|
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.
Immediate outcome: Increased capacity of the local population of the targeted region to manage subsistence agriculture.
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):
- Step 1: Identify and define risks
- Step 2: Determine effect of risk on outcomes
- Step 3: Identify risk responses
- Step 4: Assess level of risks
- Step 5: Monitor, update and report
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:
- There is a risk that our inability to attract, train, and retain the right people with the right skill set will have a negative impact on our programming effectiveness;
- There is a risk that our limited capacity to monitor, measure, and communicate results will affect the achievement of expected results;
- There is a risk that the unreliability of communication systems may slow down project activities.
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:
- There is a risk that inflation in the partner country will affect the cost of goods and services thus negatively impacting the budget and reducing the ability to achieve expected results;
- There is a risk that continued political insecurity and violence in the lead-up to elections will delay project results;
- There is a risk that cultural restrictions may preclude women and children from participating in project activities.
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:
- There is a risk that negatively perceived performance or events will affect the reputation of partners, and the confidence of stakeholders in partners’ ability to fulfill programming results;
- There is a risk that the limited implementation and results based monitoring capacity of all partners will affect the ability to achieve expected results;
- There is a risk that unanticipated strategic changes by donors or partners will affect the achievement of expected results.
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.
- Risk (1):
- There is a risk that our inability to attract, train, and retain the right people with the right skill set will have a negative impact on our programming effectiveness.
- Risk Responses (1):
- Create a recruitment plan.
- Define an action plan for employee retention (including human resources development and employee satisfaction/motivational tools).
- Continually train staff in a variety of areas to develop multiple skills in individuals.
- Risk (2):
- There is a risk that unanticipated strategic changes by donors or partners will affect the achievement of expected results.
- Risk Responses (2):
- Work with donors and partners to improve policy coherence and cooperation.
- Expand communications efforts to ensure that the various stakeholders are more fully engaged in the program and understand it better.
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).
Details of the Graphic: Likelihood criteria and Impact 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 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: