GUIDANCE NOTE ON THE OPERATIONAL RISK ASSESSMENT FRAMEWORK (ORAF)

Transcription

1 Public Disclosure Authorized Public Disclosure Authorized Public Disclosure Authorized Public Disclosure Authorized GUIDANCE NOTE ON THE OPERATIONAL RISK ASSESSMENT FRAMEWORK (ORAF) RISKS TO ACHIEVING RESULTS Operations Policy and Country Services July 1, 2011 This document: (i) is not World Bank policy; and (ii) is only intended to provide general guidance to World Bank staff in respect to the subject matter. The World Bank may revise the document from time to time. Such revisions will be made public. i

2 Table of Contents I. Purpose and Function of the Risk-Based Approach (RBA)... 1 II. Operational Risk Assessment Framework... 2 III. Risk Assessment Process... 3 IV. Disclosure... 9 V. Risk Assessment as a Dynamic process through Project Cycle... 9 VI. Roles, Responsibilities and Accountability VII. Client Discussions Annex 1 Operational Risk Assessment Framework (ORAF) ii

3 GUIDANCE NOTE ON THE OPERATIONAL RISK ASSESSMENT FRAMEWORK (ORAF) RISKS TO ACHIEVING RESULTS 1 I. Purpose and Function of the Risk-Based Approach (RBA) 1. Risk assessments are a key input to the Bank s decision whether or not to go forward with the preparation of a new IL operation, helping to determine and maintain an adequate balance between the expected results of an operation and its risks. At the project level, these assessments are a key tool to: (i) identify risks that can be mitigated adjusting the project s scope/design to improve the likelihood of achieving the expected results; (ii) define an action plan to manage the risks, establishing specific risk mitigation measures as well as capacity-building activities to address those risks; and (iii) determine the level of Bank implementation support for the project based on its risk profile. In addition, the risk based approach is designed to assist in deciding on the processing speed based on risk and in allocating resources to the areas that are burdened with the greatest risk. 2. The risk assessments exercise will have added benefits at the country, regional and Bank-wide portfolio levels. It will provide important lessons about risk mitigation and likely impact and assist with better linking of results to the portfolio s risks profile. It can be used for portfolio risk management by assessing trends in the risk profile of the portfolio and can help to ensure that resources are allocated where they are most needed. At the same time, it has the potential to strengthen the quality of analysis and decisionmaking by a variety of other actors in the Bank (CMUs, SMUs, Network anchors, those responsible for preparing and following-up on the IRMRs, IEG, etc.). 3. Risk assessment is a dynamic process starting with preparation and continuing through implementation. This assessment will help to continuously monitor the evolution of risks; to identify the emergence of new risks; to assess progress with, and impact of the implementation of risk management measures; and, as necessary, to devise appropriate adjustments to support the achievement of the project s results. 4. The risk-based approach applies to all investment lending operations including Additional Financing operations (AF) 2, and Emergency Recovery Operations (ERL) independent of the source of financing (IBRD/IDA loans, credits, grants, recipientexecuted trust funds that follow IL procedures, etc). 1 2 This note focuses primarily on the application of the ORAF to new IL operations. When applying the risk-based approach to an additional financing operation, teams need to have a global perspective in their assessment so as to consider both the risks to the original and additional loans. 1

4 II. Operational Risk Assessment Framework 5. ORAF as a tool for the Risk-Based Approach. A central element of the RBA has been the Operational Risk Assessment Framework (ORAF) tool, which helps managers and all members of project and country teams look systematically, holistically, in an integrated manner and in real time, at risks to achieving project development objectives (PDOs). Teams are expected to use the framework to: (i) identify the most important risks and risk management measures during preparation and/or implementation; (ii) track progress with risk mitigation/risk management; (iii) update the framework over the life of the project and (iv) adjust project design as necessary to support the achievement of the project development objectives. Concurrently, using the risk assessment during implementation to regularly scan the full spectrum of possible risks helps teams move quickly to identify and address emerging issues, including unanticipated risks. 6. Central focus of the risk framework: the PDOs and the link to results. The central tenet of the ORAF is that the risks being assessed are the risks to achieving Project Development Objectives (PDO) as reflected by the results to be generated by the project. The initial risk analysis can only be completed after the team has established, during project preparation, the PDOs and selected PDO-level results indicators. In using the ORAF to identify, assess, and reassess risks and monitor risk management and mitigation measures during project preparation and implementation, the starting point is always the PDO and progress toward achieving the PDO, as indicated by systematic monitoring using the results indicators. 7. A nested and integrated risk framework. The ORAF is an integrated and nested risk framework that pulls together key risk areas that may affect the achievement of the PDO of an IL operation. Through the ORAF assessment process, teams are expected to: (i) identify and describe relevant risks to the project; (ii) rate those risks based on their relevance, and (iii) establish adequate risk management measures when required. 8. The four different levels of risks that are considered under the framework are presented in Figure 1 and they are: Stakeholder Risks (1.1): Project teams assess risks to the Bank s relations with borrowers, donors, and other key stakeholders, who might question or even oppose the project in a manner that could affect the achievement of its development objectives. Project teams need to be aware and mitigate where possible; Operating Environment Level Risks: Includes Country Risk (2.1) and Sector/multisector Risk 3 (2.2). These risks are related to the environment in which the project operates and not to the PDO. Project teams should be aware of these risks even though they cannot generally be mitigated by the project. Teams are expected to take the impact of those operating environment risks on the PDOs of the specific 3 Risks that institutions related to this project across the sector(s) involved, lack adequate ownership and commitment to a shared strategy; clarity of roles and responsibilities; effective coordination mechanisms and/or fraud and corruption controls, needed to achieve the project development objectives. 2

5 project into account in the relevant risk section (for example the Implementing Agency risk or Project risk section). Implementing Agency Level Risks: Includes Capacity Risk (3.1) and Governance Risk (3.2) (which includes a Fraud and Corruption Risk sub-category). These risks are related to the specific Agency/ies that implement the project. There is scope to influence the risk level over the course of the project through mitigation measures and project design. Given the sensitivity of rating fraud and corruption, Fraud and Corruption risks will be treated differently in terms of disclosure (see Section VI). Project Level Risks: Includes Design Risk (4.1), Social and Environmental Risk (4.2), Program and Donor Risk 4 (4.3) and Delivery Monitoring and Sustainability Risk (4.4) 5. These risks are directly related to the project, where there is the most scope for mitigating and controlling risk levels through project design and implementation. Other Risks: Project teams also have the option to identify one or two additional risks that may be specific to the operation if they are not captured in the existing list (4.5). III. Risk Assessment Process 9. The centrality of teamwork and dialogue. The quality of the risk assessment depends on the project team's ability to openly and frankly discuss risks that could affect the achievement of the PDOs. The comprehensive risk assessment embodied in the ORAF cannot be the product of just one person. It requires the knowledge and expertise of each project team member (including procurement, financial management, safeguard staff and the country lawyer), representatives from the Country Management Unit (CMU) for country level risks, and the relevant Sector Management Unit (SMU) for sector/multisector level risks, other colleagues including EXT, as well as knowledge already gained from early engagement with the client. The dialogue should ideally be face-to-face, via video or virtually if that is not possible, and is at least as important as the risk ratings themselves as it reinforces the integrated team approach to identification and management of risks. 10. Project assessments done during preparation feed into the project team s risk analysis and assessment. Teams discuss risk levels drawing on their specialized knowledge and relying in particular on assessments carried out during project preparation: procurement, FM, safeguards assessments, and as needed, economic/financial analysis, as well as governance assessments. 11. Views of the borrower and relevant partners. As a means at arriving at a common understanding of the key risks to the PDOs, the team dialogue also draw in the views of borrower and relevant partners. Teams discuss the risk assessment process and 4 5 Risk posed by critical dependencies of the project on other projects/activities or other development partners (donors, private sector, etc) in the same Program. Risk associated with the ability to deliver and monitor project implementation and sustain the efforts during and beyond project execution 3

6 solicit borrower and partner views and share the general outcome of the assessment with them, in the context of formulating risk management measures. 12. Country Risks are assessed by CMUs. CMU s are responsible for the country risk assessments and for updating this assessment at least once a year or whenever changes to the country environment require it. This assessment will be uniformly applied to all projects in the country portfolio. In the future, CMU s will be expected to upload this information in the portal. Teams should not alter any of the information provided in this section by the CMUs. If there are country issues that have a direct impact on the project, those should be dealt with elsewhere (in the project risks section or where appropriate). 13. SMUs take the lead in assessing Sector/multi-sector risks. The relevant SMUs are responsible for providing the risk assessment for this risk. Generally, the project team does not design mitigation measures for sector risks unless there are specific sector issues that have a direct impact on the project. Identifying, Describing and Rating Risks 14. ORAF Guiding Questions: A tool to identify and describe risks relevant to the project and its PDO. The ORAF Guiding Questions is a reference document to facilitate the team s discussions as they identify and describe risks relevant to their operation and to ensure a comprehensive risk overview. The document should be used to stimulate thinking, discussion, or even provoke a deeper analysis of less known risk dimensions, if necessary. Some questions may not be pertinent for a given operation and as such, teams are not expected to consider all the questions. Although some questions might seem repetitive, teams need to be aware that these are addressing the same issue at different levels (i.e Fraud and Corruption at the country level vs Fraud and Corruption at the Implementing Agency level). The risk dimensions under each of the risk categories in the guiding questions are there to help. Teams should not provide ratings for the risk dimensions described in each of the risk categories. 15. Each risk category needs to be considered. When carrying out their assessment, teams should take into account that: (i) while all 10 risks categories need to be rated; (ii) not necessarily all risks affect the PDO or are relevant to the project. Normally those risks will be rated Low. Teams don t need to spend much effort in describing or entering risk mitigation measures for risks that are rated Low, a simple phrase will suffice. 16. Rating risks following a linear rating scale. Teams will provide an overall linear rating of Low (L), Moderate (M), Substantial (S) or High (H) for each risk. To the best of the team s ability, the risk factors are assessed against two dimensions: the probability (likelihood) that the risk will occur and the impact of the risk on the Project Development Objective or Objectives (PDOs). A rating of Low corresponds to a risk factor with a low likelihood of occurring and low impact if it does occur. A rating of High corresponds to high likelihood and high impact on the PDOs. Teams should use 4

7 their judgment to determine when a risk should be rated Moderate or Substantial, taking into account that likelihood and impact run along a continuum and impact is the driver of this decision. 17. To the extent possible, the project team should anchor identification of key risks and their ratings on the basis of recent project, country and sector team knowledge and experience, drawing on previous projects6 and on successful performance of agencies or project designs, relevant recent ESW and the compilation of country knowledge 7. If, for example, there is little knowledge of or experience with an implementing agency in the project team, sector team or country team, the team would likely indicate that time has to be invested in learning more about the agency and therefore the risk level at the time of assessment is higher than for a known agency. 18. Risks are rated before mitigation. When rating risk, teams should not take into account risk mitigation envisaged in the future. The risk rating should be applied to the situation at the time of the assessment thus taking into account only controls, policies or approaches that are currently in place and functioning. Establishing Adequate Risk Management Measures 19. After completing the initial risk assessment (having identified and rated risks), project teams identify (in consultation with the borrower and relevant partners) the key risk management measures planned to be undertaken during the (a) preparation and (b) implementation periods of the operation. A necessary condition to the success of such measures is to ensure that the borrower is committed to their execution and has the necessary capacity to do so. 20. Selectivity in mitigation measures. The focus in risk management is on those risks thathave the potential to derail project implementation and could affect achievement of the key results and that have real potential for mitigation. Some measures may go beyond mitigation to also include capacity building and system enhancements to reduce the risks not only for the duration of the operation but also to prepare the borrower for better dealing with such risks following the conclusion of the operation. The agreed upon actions may feed into the project particularly under any capacity building components foreseen. 21. As a rule of thumb: (i) not all risks need to be mitigated; some may only need to be monitored if they cannot be addressed through the project; (ii) if the risk rating for a certain risk is considered low, no mitigation measure needs to be entered; a simple phrase indicating Not relevant will suffice; (iii) whenever possible, teams should manage risks through the project design; (iv) on average, no more than three measures per risk are expected. 6 7 Including ISRs, ICRs, QAG and IEG findings, INT investigation findings, DIRs, and Inspection Panel cases Relevant documents include CASs, the country CPIA, CPARs, CFAAs, and analytical work on Governance and Anticorruption (GAC). 5

8 22. Timeframe within which key risks require mitigation. Teams will have to consider the timeframe within which the critical mitigation measures should be implemented. Some key risks may be high early in implementation and will need to be addressed through specific mitigation measures during preparation; others will be more important at later stages of implementation and will be tackled at an appropriate time during implementation. Project teams indicate when each risk is expected to be mitigated: during preparation or implementation. 23. If a risk is likely to be mitigated during preparation, teams need enough time and resources to do that. On the other hand, if the mitigation of risks is during implementation, teams need to allocate the effort and resources during that period. It is this basic principle that is behind the differentiated processing of operations by risk. The team uses its conclusions on the timing of mitigation in considering the overall risk of the operations as well as the processing path and the level and timing of implementation support. 24. Managing risks through project design. Teams should strive to mitigate risks through the project design so as to eliminate to the extent possible unnecessary sources of risk during implementation. In some cases, mitigation measures will take place during preparation and that will change the overall implementation risk. Risks and mitigation measures are automatically reflected in the project s first ISR to allow project teams to track risks, change them, if needed, and monitor the implementation of said measures. If a risk management measure is not working, the team may consult with the client and agree to adjust the measure or even adjust the project (project restructuring). Overall Risk and Determining the Processing Track 25. Use judgment in doing the overall risk assessment. There is no formula for arriving at the overall project risk rating. The overall ratings are not an average or weighted average of the ratings for individual risk categories. They are based on judgment and experience. For example, it is possible that one particular category assessed as a high risk makes the overall project high risk in the eyes of the project team. In other cases, several categories assessed as moderate or high might be judged as not seriously endangering the achievement of the PDOs and not taking the operation out of the moderate or even low risk category. A good example is an operation in a high risk country that may be low risk because of a simple and straightforward design implemented by a well-performing agency. Based on its judgment, the project team will propose an overall Preparation Risk Rating and an overall Implementation Risk Rating to be discussed during the concept review meeting. 26. Two processing tracks. One outcome of the risk-based approach is to differentiate processes and documentation for preparation of IL operations based on risk. Two processing paths have been defined: (i) Track 1 (express lane), with fewer clearances (at concept stage obtain agreement to proceed with preparation/appraisal; no formal decision meeting; no control point until completion of appraisal) and simpler documentation (simpler PAD with fewer annexes); or (ii) Track 2 (regular lane) with 6

9 additional information required for the PAD and annexes and the need for an appraisal decision meeting to confirm that the preparation is on course and risk are being properly addressed. Projects with a low or moderate overall preparation risk for which the best part of the risks can only be mitigated during implementation, would not likely benefit from having an extra control point or require long preparation period, and the fast processing following Track 1 may be appropriate. Projects with a high or substantial overall preparation risk for which the majority of risks can be mitigated during preparation, would likely benefit from following a regular preparation process and require an additional control point (Track 2) and may require a longer preparation period. Whereas in general, projects with substantial or high overall preparation risk tend to be processed following Track 2 and projects with low or moderate overall preparation risk following Track 1, fast processing may also be appropriate for projects with high overall preparation risk that cannot reasonably be expected to be mitigated during preparation such as projects in fragile states. In those cases, the decision may be made to process fast and allocate the scarce resources to implementation support, rather than preparation. The timing of the associated risk management measures is an important influence in deciding on the processing track. It is understood that there are other considerations beyond the risk ratings and timing of mitigation that could affect the decision on the processing track. The decision on whether a project will be prepared following Track 1 or Track 2 will be determined at concept stage. 27. Decision on the Overall Project Risk and processing track. At the concept review meeting, the Chair makes two decisions, which are recorded in the decision note. The first is a decision on the overall Preparation and Implementation Risk Ratings for the operation based on the project team ratings (see section VI). The concept review meeting Chair also makes a second, related but independent decision: whether a project can be prepared following Track 1 (express) or Track 2 (regular). 28. Corporate (enhanced) reviews. The risk assessment will also provide information to Regional Management for determination of whether a Track 2 project should undergo a corporate-level review (please refer to the Bank s Guidelines and Procedures for Corporate Review of Operations and Country Strategies) 8. Recording the Work: Risk Assessment Template and the Project Portal 29. ORAF and the new Portal. The new portal (Portal 2.0) includes a Roadmap that allows project teams to easily follow the different processing steps throughout a project s cycle (Concept/ Appraisal/ Negotiations/ Approval/ Implementation Support/ Completion) providing the required corporate templates (web form or MS Word) for any specified action. As such, The ORAF template is now available as a web form at all stages of the project cycle. Team will initially enter all information at concept stage and then update the same as they move through the project preparation (Appraisal, Negotiation, Board). After project Approval the system will automatically transfer the 8 RYSTRATEGIES.pdf. 7

10 cleared ORAF version to the first Implementation Status and Results Report (ISR). While the system will not impose limits on the number of characters that can be uploaded, teams are encouraged to be succinct in their write-ups to keep the total ORAF length reasonable (if possible to a maximum of 4 pages when printed), focusing their attention on key risks and mitigations measures. 30. Full and Disclosed versions of ORAF. The ORAF contains deliberative information that should not be disclosed when sending the package to the client for Negotiations or when sending the package to the Board for approval (see IV for details) therefore two print versions (full and disclosable) are available to staff. For internal processing up to appraisal completion package, staff will always include the full ORAF in their PCN or PAD. Starting with the negotiation package the portal will automatically give the disclosable version of the ORAF for the team to insert in the PAD, while the full version of the ORAF will appear in the supporting documentation section for information (refer to Annex 1 for the disclosed and undisclosed versions as well as the detailed help content in the Portal). In any case, and as with other official documents teams should use judgment when writing information that will available to the public particularly when dealing with sensitive issues. 31. The printed version of the undisclosed full ORAF template has sixteen rows, of which the first twelve describe, rate and introduce risk management measures for each risk category: Risk Description. Project teams succinctly summarize the risk in a form they find suitable for wider distribution. Teams may extract information from issues already described in the main body of the PCN/PAD (or make cross references to relevant paragraphs) to limit the length and avoid duplicative efforts. Teams should restrain from repeating the definition of the risk dimension in the guiding questions. Teams can identify more than one issue for a specific risk dimension, if needed. Risk Rating. Only one rating per risk category should be introduced: L, M, S or H. Proposed Risk Management Measures. These measures do not affect the risk ratings as risks are rated before mitigation. These should be carefully and selectively chosen so as to have on average no more than three measures per risk category. For each measure the system will require: (i) a Responsible party (Client/Bank/Partner), (ii) the Stage during which the mitigation measure will take place (Preparation/Implementation); (iii) the Due date of the action (if applicable); and (iv) Status (Not yet due/in progress/delayed/completed/dropped). This information will help teams monitor the implementation of the mitigation measures and take corrective measures if some of them are not working or cannot be implemented. 32. The next row is an optional one where teams can provide any additional information or flag any sensitive issues to management. This row is part of the internal deliberative process, hence will not be disclosed. 8

11 33. The project team records its overall Preparation and Implementation risk ratings and provides any comments on main project risks. 34. Teams will need to record the decision on the Track in the Concept Decision Note which is generated in the Portal. 35. Summary table in PCN and PAD. A very short summary of the ORAF has been included in the PCN and in the PAD templates, to give a quick overview of the main risks to the project. Whenever the ratings are updated in the ORAF template, teams need to remember to update the risk summary table in the main text of the PCN/PAD. IV. Disclosure 36. Once the authorization to negotiate has been cleared, the project team will send the negotiation package to the client (with the disclosable ORAF version generated by the system) to invite them to negotiate the project. The following deliberative information will not be displayed in this disclosed version of the ORAF template, including (i) the operating environment risk; (ii) the fraud and corruption risk description and ratings; (iii) the non- disclosable information for management attention row; and (iii) the project team risk ratings. 37. While project teams should describe, rate and propose risk management measures for the Fraud and Corruption risk sub-category only risk management measures will be disclosed. Given the sensitivity of rating fraud and corruption risks, the disclosed version of the ORAF would only present the risk management measures needed to address any fraud and corruption risks that have been identified. Said mitigation measures will be presented as an integral part of the mitigation measures under the Governance risk category. For this reason, when describing the Governance risks teams will need to make some reference to the fraud and corruption risks, enough to support the fraud and corruption mitigation measures. V. Risk Assessment as a Dynamic process through Project Cycle 38. While the discussion so far has focused on the initial risk assessment, the ORAF should be a live document that teams update as they carry out project preparation and throughout implementation. In fact, teams may come across important risks during preparation that were not identified at concept stage. Project teams in consultation with the SM and CD, may decide to alert Regional Management, and if needed, change tracks. The opposite may be true as well. Project teams may discover that some risks are not likely to materialize and hence change from Track 2 to Track 1 if appropriate. Updating the risk assessment during preparation. As preparation proceeds, the task team updates the risk assessment, taking into account new information and the outcome of risk management measures planned for the preparation period. As the 9

12 appraisal stage is reached, the risk management measures identified for preparation should have been mostly completed. At that time, it is also important to have an implementation support plan for the operation that takes the risk profile into account. Updating the risk assessment during implementation. Risk management measures planned for implementation will be recorded and transferred to the ORAF template in the Implementation Status and Results (ISR) Report for monitoring at least annually. During implementation, project teams (in consultation with the borrower and partners) carry out a comprehensive risk scan using the ORAF at least annually and report the outcome in the ISR. As part of that process, teams monitor the implementation of risk management measures and report whether the planned measures were implemented and to what extent they were effective and whether any new risks arose that need to be mitigated or monitored. Teams upgrade risk ratings when evolutions under the project or progress on implementation of risk management measures justify doing so. When a risk management measure is not working, the team consults with and supports the borrower in adjusting the measure or replacing it. During implementation, the risk assessment is used to: (a) decide, in consultation with the borrower, on potential adjustments to the project, restructuring or closing if needed; and (b) adjust the scope and budget for Bank implementation support. VI. Roles, Responsibilities and Accountability 39. This section draws mainly on the sections above. It is important however, that staff at all levels is clear on the responsibilities and accountabilities for project risk analysis and its use in making project-related decisions. Project team: is responsible for (a) the initial assessments for project stakeholders, implementing agency, and project risks; (b) the overall ratings; (c) entering the decision on project processing track in the system; (d) updating the risk assessments between PCN and PAD, and particularly before the decision meeting for projects following preparation Track 2 (regular); (e) ensuring that after authorization to negotiate has been cleared the negotiations package and the Board packages contains the disclosed ORAF template; (f) updating as needed the risk assessment at least annually as part of the ISR; and (g) for operations being prepared following Track 1 (express), report to the SM and CD if any new risks materialize that would likely change the processing track. Country Management Unit (CMU) and the Country Director (CD): CMU s are responsible for the country risk assessments and for updating this assessment. The CD is responsible for ensuring that the country risk rating is provided in a timely manner, early enough to avoid delaying project preparation. While CMU provide information regarding how the risks at this level will be mitigated in the overall portfolio, this will be a reference for the country team but will not be monitored by the project team. The CD ensures that someone from the country team (e.g., country officer, lead economist, etc.) involved in setting the country rating takes 10

13 part in the project team assessment of other risk categories and the overall project rating. The risk approach and assessment is also an important tool for CDs as they integrate operational risks in budgeting work programs. Sector Management Unit (SMU) and Sector Manager (SM): the SMU is responsible for the sector/multi-sector risk assessments 9. SMs are accountable for staffing and budgeting operational teams during preparation and implementation, ensuring that the team has experience and expertise that is commensurate with the needs surfacing from the risk analysis of the project. SMs also review and sign off on annual risk assessment updates in the context of ISRs (the ISR guidelines will provide more details on that process). SMs use these risks assessments in setting implementation support budgets for project teams. Financial Management (FM), Procurement and Environmental and Social Development Sector Managers: working with SMs, FM, Procurement and Environmental and Social Development SMs ensure the timely assignment of appropriate staff to the project team, and the availability of those staff to participate actively in project team risk deliberations, ensuring that concept review meetings are not delayed. Financial Management, Procurement, and Social and Environment staff: the FM, procurement, and safeguard members of the project team are responsible to come prepared to participate in the team deliberations and contribute their knowledge and expertise to the overall team assessment to be included in the PCN. Teams should discuss risk levels drawing on their specialized knowledge and come up with a common view. Regional Chief Counsel and Country Lawyer: it is the responsibility of the Regional Chief Counsel to ensure the participation of the country lawyer in the team discussions on the ORAF, notably the discussions leading to the PCN risk ratings. This is especially crucial for operations that are put on Track 1 (express), so that the lawyer is familiar early on with the project and, therefore, well prepared for the simpler Track 1 preparation process. Role of the Concept Review Meeting Chair. Participants in the concept review meeting discuss the results framework, the key indicators and the related risk assessment. The chair of the concept review meeting (typically the CD) is responsible for determining: (i) the overall risk ratings of the project (preparation and implementation) and (ii) the processing path (Track 1 or Track 2).. Following the concept review meeting, the final risk rating and processing track are included in the PCN decision note minutes. Role of Decision Meeting Chair for track 2 operations. For projects that are not put onto Track 1 at the concept stage, the project team updates the risk assessment 9 The responsible SM may assign to a specific person, for example, the country sector coordinator, sector leader or cluster leader the responsibility of providing the write-up for the sector/multi-sector risk section in a timely manner 11

14 and ratings for the appraisal stage decision meeting (with the relevant inputs from the CMU for country risk and the SMU for sector/multi-sector risk). The chair of the Decision meeting (typically the CD) is responsible for determining the overall risk ratings of the project.. Following the meeting, the final risk rating is included in the decision note. VII. Client Discussions 40. Although the rating of risks to the achievement of the development objectives is the responsibility of the Bank as part of due diligence, the risks should be discussed with clients early on in terms of constraints to achieving development objectives. Working out the key risk management measures with the client would help alleviate those constraints. Clients need to know early on that the disclosed version of the PAD will include risk descriptions with risk ratings and an overall project risk rating. They should understand that the Bank uses the risk ratings to make decisions as to how best to support clients and is not making value judgments or ranking countries. Specifically, during project identification and through preparation and implementation, the project team discusses with its counterparts constraints that could impair the implementation of the proposed project and the achievement of the intended results. Following the identification of these constraints, the project team agrees with the client on key risk management measures to help alleviate them. This process will vary according to the country context and the relationships with the client. The other important dimension to convey is the systematic nature of the risk framework and how it will help the client country and the Bank better to address design, implementation and portfolio issues. At the operating environment level where risk ratings are not disclosed, the constraints and risks would be discussed by Country Directors, in the broader context of their dialogue with the client on their development strategies and country program. 12

15 Annex 1 Operational Risk Assessment Framework (ORAF) {COUNTRY}: {Project Name} Stage: PCN (Full Version) 1. Project Stakeholder Risks Rating Description : 2. Operating Environment Risks (Note for information: this section is not disclosed at negotiation and Board presentation stages) 2.1. Country (Note for information: this section is not disclosed at negotiation and Board presentation stages) Rating: Description : 2.2. Sector/multi-sector (Note for information: this section is not disclosed at negotiation and Board presentation stages) Rating: Description : 3. Implementing Agency Risks (including fiduciary) 3.1. Capacity Rating: 13

16 Description : 3.2. Governance Rating: Description : Fraud & Corruption (sub-category of Governance risk) Rating: (Note for information: this section is not disclosed at negotiation and Board presentation stages, except the risk Management measures which will be merged with those on 3.2 Governance) Description : 4. Project Risks 4.1. Design Rating: Description : 14

17 4.2. Social & Environmental Rating: Description : 4.3. Program & Donor Rating: Description : 4.4. Delivery Monitoring & Sustainability Rating: Description : 4.5. Other Rating: Description : 15

18 4.6. Other Rating: Description : Non-disclosable Information for Management Attention (Optional) (Note for information: this section is not disclosed at negotiation and Board presentation stages) Comments: 5. Project Team Proposed Rating Before Review 5.1. Preparation Risk Rating: (Note for information: this section is not disclosed at negotiation and Board presentation stages) Comments: (Note for information: this section is not disclosed at negotiation and Board presentation stages) 6. Overall Risk Following Review 6.1. Preparation Risk Rating: (Note for information: this section is not disclosed at negotiation and Board presentation stages) Comments: (Note for information: this section is not disclosed at negotiation and Board presentation stages) 5.2 Implementation Risk Rating: (Note for information: this section is not disclosed at negotiation and Board presentation stages) Comments: (Note for information: this section is not disclosed at negotiation and Board presentation stages) 6.2 Implementation Risk Rating: Comments: Note : Include on average no more than 3 Risk Management Measures per Risk Category 16

19 Operational Risk Assessment Framework (ORAF) {COUNTRY}: {Project Name} Stage: Board (Disclosed Version) Project Stakeholder Risks Rating Description : Implementing Agency Risks (including fiduciary) Capacity Rating: Description : Governance Rating: Description : 17

20 Project Risks Design Rating: Description : Social & Environmental Rating: Description : Program & Donor Rating: Description : Delivery Monitoring & Sustainability Rating: Description : 18

21 Other Rating: Description : Other Rating: Description : Overall Risk Following Review Implementation Risk Rating: Comments: Note : Include on average no more than 3 Risk Management Measures per Risk Category 19

22 Risk-Based Approach: Application at Project Level 1. Understand it Operational Risk Assessment Framework (ORAF): It stresses thinking about risks to the Project Development Objective(s) Nested model with 4 levels in which teams examine 10 risk categories and have an optional risk category to use if needed 4. Time it Teams also need to decide if mitigation of risks is best during preparation or implementation; this is important to focus efforts on where they are most needed 5. Track it Taking the risk rating and timing for mitigation into account, decide on the project s overall risk rating at preparation and implementation and the project processing track: Track 1 (Express Lane) Track 2 (Standard) 2. Assess it To provide a risk rating for each category, we use a two dimensional scale looking at likelihood and impact of risks Teams are also given standard definitions and a set of guiding questions to assist thinking about the types of issues in each category 3. Mitigate it Look at the risks and think about the ones you need to be aware of and the ones that can be mitigate through the project Be realistic and propose no more than 4 mitigation measures per category 20 Do not forget it during implementation!