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?
- Aid effectiveness—¶¶ÒùÊÓƵ is recognized by the international community for its capacity to work effectively in high-risk environments. Using risk management, the department is able to make more 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 Treasury Board Secretariat 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 Organization 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.
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):
- 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.
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:
- 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
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:
- 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
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).
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
- Date modified: