Republic of Mozambique Aid Data Management Assessment April 2017 Public Sector and Governance AFRICA Document of the World Bank Aid Data Management Assessment - Mozambique Standard Disclaimer: This volume is a product of the staff of the International Bank for Reconstruction and Development/ The World Bank. The findings, interpretations, and conclusions expressed in this paper do not necessarily reflect the views of the Executive Directors of The World Bank or the governments they represent. The World Bank does not guarantee the accuracy of the data included in this work. The boundaries, colors, denominations, and other information shown on any map in this work do not imply any judgment on the part of The World Bank concerning the legal status of any territory or the endorsement or acceptance of such boundaries. Copyright Statement: The material in this publication is copyrighted. Copying and/or transmitting portions or all of this work without permission may be a violation of applicable law. The International Bank for Reconstruction and Development/ The World Bank encourages dissemination of its work and will normally grant permission to reproduce portions of the work promptly. For permission to photocopy or reprint any part of this work, please send a request with complete information to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, USA, telephone 978-750-8400, fax 978-750- 4470, http://www.copyright.com/. All other queries on rights and licenses, including subsidiary rights, should be addressed to the Office of the Publisher, The World Bank, 1818 H Street NW, Washington, DC 20433, USA, fax 202-522-2422, e-mail pubrights@worldbank.org. Aid Data Management Assessment - Mozambique Acknowledgements This assessment was prepared by a team led by Dionísio Nombora and Daniel Nogueira- Budny (GGODR, co-TTLs). The team included Furqan Saleem, Khuram Farooq, Matt Geddes, Lily Bunker, and Chambal Chambalson (GGODR). Overall guidance was provided by Guenter Heidenhof and Chiara Bronchi (Practice Manager, GGO13) and Mark Lundell (Country Director, AFCS2). The team would like to express its gratitude to Carolin Geginat, Iolanda Fortes, Shireen Mahdi, Carolina Renteria, Stephen Davenport, Johannes Kiess, Massimo Mastruzzi, Tiago Peixoto, Kirk Schmidt, Sally Torbert, Arturo Navarro, João Morgado, Ibrahim El Ghandou, Emerson Siquice, and Claudio Mendonça for their expertise and support. Preparation of this report greatly benefited from the support of UNDP’s Maputo office, specifically, Luca Monge Roffarello, Manuel Felipe, and Masaki Mifune. The team would like to thank the Government of Mozambique for its support with the assessment. In particular, the team would like to acknowledge the leadership of the Directorate of Cooperation (DC) on aid data management in Mozambique. This report would not have been possible without the support and concerted efforts from the Director of Cooperation, Isabel Sumar, as well as her staff—in particular, Cândido Jeque and Lauzeta Cossa. The team would also like to acknowledge the assistance and support received from the National Director of Economic and Financial Studies (DEEF), Vasco Correia Nhabinde; Deputy Director of Planning and Budgeting (DNPO), Cristina Matusse; Deputy National Director of Treasury (DNT), Ester dos Santos; and Deputy National Director of Monitoring and Evaluation (DNMA), Xavier Chavana; as well as Deputy General Director of the National Institute of Information and Communication Technology (INTIC), Augusto Nunes; Deputy General Director of the Center for the Development of Financial Information Systems (CEDSIF), Jacinto Muchine; and Ministry of Foreign Affairs and International Cooperation (MINEC) Officer Januário Sumbana. Aid Data Management Assessment - Mozambique Abbreviations and Acronyms AfDB African Development Bank AIMS Aid Information Management System AMP Aid Management Platform BTC Belgian Technical Cooperation CEDSIF Center for the Development of Financial Information Systems CNS Contas Nacionais de Saúde (National Health Accounts) CoA Chart of Accounts CS-DRMS Commonwealth Secretariat Debt Recording and Management System CSO Civil Society Organization CSV Comma Separated Values CUT Conta Única do Tesouro (Single Treasury Account) DC Directorate of Cooperation DEEF National Directorate of Economic and Financial Studies DFID U.K. Development for International Development DG Development Gateway DIC Directorate of Investment and Cooperation DNMA National Directorate of Monitoring and Evaluation DNPO National Directorate of Planning and Budgeting DNT National Directorate of the Treasury DOGSI Department of Information System Organization and Management DP Development Partner e-SISTAFE State Electronic System of Financial Administration (e-Sistema de Administração Financeira do Estado) EU European Union FAO Food and Agriculture Organization of the United Nations GBS General Budget Support GoM Government of Mozambique IATI International Aid Transparency Initiative IFE Inquérito de Fundos Externos (Survey of External Funds) IFMIS Integrated Financial Management Information System IHP+ International Health Partnership INTIC National Institute of Information and Communication Technology MARF Monitoria e Analise de Recursos Financeiros (Monitoring and Analysis of Financial Resources) MCTESTP Ministry of Science and Technology MDAs Ministries, Departments, and Agencies MDG Millennium Development Goal MEF Ministry of Economy and Finance MEGAS Medição de Gastos em SIDA (Spending in AIDS Measure) MINEC Ministry of Foreign Affairs and International Cooperation MoU Memorandum of Understanding MPD Ministry of Planning and Development MTEF Medium-Term Expenditure Framework M&E Monitoring and Evaluation NGO Nongovernmental Organization ODA Official Development Assistance ODAmoz Mozambique AIMS OECD Organization for Economic Co-operation and Development i Aid Data Management Assessment - Mozambique OECD DAC OECD Development Assistance Committee OECD DAC CRS OECD DAC Creditor Reporting System PAAS Platform As A Service PAF Performance Assessment Framework PAP Program Aid Partner PIM Public Investment Management SDG Sustainable Development Goal SWG Sector Working Group UN United Nations UNDP United Nations Development Program UNICEF United Nations Children's Fund UNRCO UN Resident Coordinator’s Office WHO World Health Organization ii Aid Data Management Assessment - Mozambique Preface ODAmoz, Mozambique’s online platform to collect aid data from development partners (DPs) operated by Mozambique’s Directorate of Cooperation (DC) in the Ministry of Economy and Finance (MEF), went offline between April and December 2015. The shutdown interrupted aid data flows and highlighted an urgent need to assess the current ODAmoz system and weigh alternative options. In February 2016, the Government of Mozambique (GoM), through DC, requested World Bank support to conduct a functional and technical assessment of the ODAmoz platform and processes as part of the World Bank’s broader non-lending technical assistance to the sector. The assessment was conducted in close collaboration with several key DP stakeholders, particularly the United Nations Development Programme (UNDP). This report summarizes the results of that assessment, which focused on the system’s ability to capture, manage, publish, and use aid data, and proposes several options for the future. It aims to inform in- depth support from the World Bank and other DPs to the GoM in the field of aid data management, in close coordination with ongoing and planned technical assistance around public finance management. iii Aid Data Management Assessment - Mozambique Table of Contents Abbreviations and Acronyms .................................................................................................................. i Preface ................................................................................................................................................... iii Abstract ................................................................................................................................................... 1 1. Aid Data Management in Mozambique .......................................................................................... 2 1.1. Functional and Technical Assessment of ODAmoz ............................................................... 2 1.2. History and Present Objective of ODAmoz ............................................................................ 3 1.3. Aid Data Demand, Supply, and Use ....................................................................................... 5 2. Existing Issues ................................................................................................................................ 9 2.1. Data Collection Issues........................................................................................................... 11 2.2. Institutional and Coordination Issues .................................................................................... 13 2.3. Technical and IT Issues......................................................................................................... 15 3. Recommendations ......................................................................................................................... 19 3.1. Solutions to Data Workflow and Collection ......................................................................... 22 3.2. Solutions to Institutional and Coordination Issues................................................................ 23 3.3. Solutions to Technical and IT Issues .................................................................................... 25 Status Quo: Embrace Multiple Parallel Systems (Shut Down ODAmoz) ....................................... 28 Option 1: Consolidate Systems and Incorporate ODAmoz-Specific Features................................. 29 Option 2: Reinstate ODAmoz as the Sole Aid Data Collection System, with Improved Hosting, Some Technical Help, and/or Minor Changes .................................................................................. 30 Option 3: Redesign Mozambique’s AIMS, Preferably Housed within CEDSIF ............................. 34 4. Next Steps ..................................................................................................................................... 36 Tables, Figures, and Boxes Box 1: Demand for Aid Data ................................................................................................. 6 Figure 1: Flowchart of Aid Data Management Status Quo .................................................. 10 Figure 2: Flowchart of Improved Data Management ........................................................... 21 Table 1: Likely Core Data Fields ......................................................................................... 22 Table 2: Advantages vs. Disadvantages of ODAmoz Options ............................................ 27 Table 3: Status Quo - Embrace Multiple Parallel Systems (Shut Down ODAmoz) ............ 28 Table 4: Option 1 - Consolidate Systems and Incorporate ODAmoz-Specific Features ..... 29 Table 5: Option 2 - Reinstate ODAmoz as the Sole Aid Data Collection System, with Improved Hosting, Some Technical Help, and/or Minor Changes ...................................... 31 Table 6: Option 3 - Redesign Mozambique’s AIMS, Preferably Housed within CEDSIF.. 35 iv Aid Data Management Assessment - Mozambique Abstract This report is the output of a functional and technical assessment of aid data management in Mozambique. The objectives of the report are to analyze why aid data management is suboptimal in Mozambique, weigh the pros and cons of potential alternatives, and propose policy changes that would allow the Government of Mozambique (GoM) to better capture, manage, publish, and use aid data for improved development results. Demand for aid data in Mozambique is high; however, the supply—and therefore use—of this data, is low. The primary challenge is that the current Aid Information Management System (AIMS) does not use national budget classification categories, complicating the integration of aid data with budget data. Secondary critical challenges include unnecessary complexity (there are currently more than 50 fields), lack of flexibility (no updates to reflect annual changes to the country’s Chart of Accounts), and inability to accommodate multidonor projects and pooled funds (leading to double counting). Communication lines between the GoM and development partners (DPs) are also limited, thus excluding the principal source of feedback on usability. These challenges have led to a negative cycle whereby more data is being lost or being captured but not shared. The report recommends several institutional changes, including allocating sufficient staff for directing and managing ODAmoz, improving communication by building on existing aid coordination mechanisms and collaborating better with line ministries, and restarting engagement with DPs. Most critically, the report also recommends that the GoM redesigns ODAmoz such that aid data is recorded in a format that can easily be used in the national planning and budgeting process; this would entail the new platform being housed within the Center for the Development of Financial Information Systems (CEDSIF) of the Ministry of Economy and Finance (MEF) and closely linked to the State Electronic System of Financial Administration (e-SISTAFE), Mozambique’s Integrated Financial Management Information System (IFMIS). 1 Aid Data Management Assessment - Mozambique 1. Aid Data Management in Mozambique 1.1. Functional and Technical Assessment of ODAmoz 1. This report is the output of a functional and technical assessment on ways to improve aid data management in Mozambique, requested by the Government of Mozambique (GoM) in February 2016. This request is part of wider support provided since 2015 from the World Bank’s Governance Global Practice, in conjunction with its Open Government Global Solutions Group, around improving the GoM’s ability to capture, manage, and publish aid data. The focus of this assessment is ODAmoz, Mozambique’s Aid Management Information System (AIMS),1 which is managed by the Directorate of Cooperation (DC) of the Ministry of Economy and Finance (MEF). The assessment took place between April and June 2016 and included desk-based research on Mozambique’s aid data management and ODAmoz, background research on relevant examples from other countries, followed by individual and small group interviews in Maputo with the GoM and development partner (DP) stakeholders at the technical and political levels.2 2. Tracking data on aid contributions from DPs is in the interest of government because it can enable more effective domestic resource allocation in the national planning and budgeting processes. An AIMS that is integrated into existing government systems for expenditure reporting and project management can strengthen national institutions and ensure the efficient use of national development resources. Government planning and budget officers can review off-budget data, in addition to data captured in the budgeting and treasury systems, allowing for greater efficiencies in domestic and foreign development resource spending. 3. Aligning and integrating data on aid contributions from DPs is also important as a critical first step to improving aid effectiveness. Monitoring aid flows through a country’s AIMS is important for three more key reasons:  It encourages improved aid cooperation, avoiding duplication of DP efforts and ensuring equitable support across sectors and regions. 
 1 Aid information management system (AIMS) is the term used for a number of similar project management and coordination systems for on- and off-budget aid data. Development Gateway (DG), one of the foremost players in aid data management, develops and maintains Aid Management Platforms (AMPs); Synergy, a competing firm, develops Development Assistance Databases (DADs). Mozambique’s ODAmoz was created by a small firm, ODAdata, which has since been incorporated into DG; DG is now responsible for the two existing ODAdata platforms—in Mozambique and Nicaragua—and was the firm responsible for developing the current version (2.0) of ODAmoz, which was launched in 2011. 2 The team met with stakeholders from the following DPs: African Development Bank (AfDB); U.K. Department for International Development (DFID); European Union; Korea Eximbank; United Nations Development Programme (UNDP); UN Resident Coordinator’s Office (UNRCO); United Nations Children’s Fund (UNICEF); World Health Organization (WHO); and the embassies of Brazil, Canada, Finland, Germany, Italy, Japan, Portugal, Switzerland, and Sweden. It met with stakeholders from the following MEF units: DC, National Directorate of Planning and Budgeting (DNPO), National Directorate of Economic and Financial Studies (DEEF), National Directorate of the Treasury (DNT), National Directorate of Monitoring and Evaluation (DNMA), Department of Information System Organization and Management (DOGSI), and Center for the Development of Financial Information Systems (CEDSIF). Finally, it met with stakeholders from the Ministry of Foreign Affairs and International Cooperation (MINEC) and the National Institute of Information and Communication Technology (INTIC). 2 Aid Data Management Assessment - Mozambique  It allows for monitoring and evaluating the implementation of national development strategies and international development agendas,3 harmonizing DP projects with key policy priorities.  It facilitates greater transparency and accountability between the Government and DPs, including increased oversight by civil society actors. 4. The objectives of the report are to analyze why aid data management is suboptimal in Mozambique, weigh the pros and cons of potential alternatives, and propose policy changes. This analysis covers the entire system of aid data management, including how to better capture, manage, publish, and use aid data for improved development results. Mozambique continues to receive substantial support from development partners, and aid data management is critical for increasing the efficiency of national planning, budgeting, and alignment of aid support with domestic development resources. 5. The findings and recommendations of this report are the result of a collaborative effort with the MEF and DPs—particularly the United Nations Development Programme (UNDP). The report has since gone through a series of iterative edits to ensure that all stakeholder views are reflected. In particular, a workshop held on May 10, 2016, discussed preliminary results, solicited additional information in a group setting, and built a shared understanding and consensus among all relevant stakeholders. 6. This report is structured around the demand for, supply of, and use of aid data in Mozambique. The rest of this chapter reviews basic facts on the current situation, including an overview of the original objectives of ODAmoz and why it went offline in 2015. The next three chapters are thematically structured to identify challenges and suggest necessary improvements, given the realistic constraints of the context. The report then identifies several ways forward, discussing trade-offs and alternatives while integrating good practices and knowledge from other countries addressing similar issues. Finally, the suggested options are outlined, including the technical specifications, policy reforms, and procedural changes needed to enact these solutions. 1.2. History and Present Objective of ODAmoz 7. ODAmoz was developed in 2005 by ODAdata on behalf of the European Commission and the Embassy of the Netherlands, responding to the needs of traditional DPs to coordinate and monitor official development assistance (ODA) to Mozambique. The platform was initially managed by DPs, until 2006, when ODAmoz became the responsibility of the Directorate of Investment and Cooperation (DIC) under the former Ministry of Planning and Development (MPD). In 2015, following the government restructuring, the DIC became the Directorate of Cooperation (DC) in the Ministry of Economy and Finance (MEF), the successor to the MPD. Following ODAmoz’s change in management, DPs provided limited technical assistance to the GoM to ensure proper management of aid data and the platform. 8. Initially, ODAmoz’s main objective was to provide DPs with a tool, based on international standards, to fulfill their reporting obligations to the GoM on project plans and quarterly disbursements (see ODAmoz.mz.org). From 2005 to 2007, ODAmoz 3 This is limited, however, by the fact that AIMS generally only captures disbursements and not actual expenditures. 3 Aid Data Management Assessment - Mozambique captured and managed project information from a majority of European Union (EU) members and G-19 donors—the Program Aid Partners (PAPs). In 2006, ODAmoz captured an estimated 80–90 percent of ODA; in 2007, ODAmoz was expanded to include United Nations (UN) agencies. 9. Following the establishment of Mozambique’s State Electronic System of Financial Administration (e-SISTAFE), an upgrade was planned in 2008 to connect ODAmoz to e-SISTAFE. The upgraded system, ODAmoz Version 2.0, would create an interface between the two systems and modules for budget elaboration and execution.4 This new platform was planned to  Be compatible with ODAmoz 1.0, allowing for full integration of existing data;  Allow for data access and analysis around key, national-level policies—for example, 5-Year Plans, the Sustainable Development Goals (SDGs)—and include indicators, goals, sectors, provinces, and districts;  Link to e-SISTAFE's Budget Preparation Module, with the option to expand to other components, such as linking to the public accounting system for budget execution;  Be able to visualize data geographically with maps; and  Create reports for the diverse needs of DP, government, and public users. 10. ODAmoz Version 2.0 was completed in 2012, but it only partially fulfilled the planned mandate due to unforeseen complications. Basic reports and map functions were added, but the system continued to use the Organisation for Economic Co-operation and Development (OECD) Development Assistance Committee (DAC) sectors—as opposed to the GoM sector codes, which is widely considered best practice for the AIMS. This gap suggests that the current data structure in ODAmoz (as it is currently being captured) cannot integrate with the GoM processes. Nevertheless, the upgraded system is now capable of accepting basic data on projects and producing project summaries and useful reports by sector, location, or DP. 11. ODAmoz’s mandate has expanded since being transferred under the authority of the GoM and upgraded to the new version. According to DC, ODAmoz now has four main objectives: 4 Integration of the Integrated Financial Management Information System (IFMIS) and AIMS is widely seen as possible; however, it can be quite difficult to achieve and many development technology firms have been trying for years to do this. A particularly poignant case is Liberia, where DG has invested hundreds of thousands of dollars in such a project, with limited success. The difficulty is putting into the government accounting system projects whose finances are not in fact controlled by government and do not use government systems. What has proven easier is IFMIS-AIMS compatibility. In Somalia, for instance, where fields for both systems are similar, the AIMS was restructured to use the same codes (such that, a sector report from the IFMIS will make the same sectors as one from the AIMS). In Rwanda, the AIMS is currently being linked to the IFMIS for better integration of off-budget aid into the national budget; along with Rwanda, Kenya and Iraq are seen as good examples in which aid and budget data are linked. Relatedly, Ghana has not yet linked both systems; however, its AIMS captures aid and debt figures together, which are extracted, put into Excel, and then fed into the country’s budget management system. 4 Aid Data Management Assessment - Mozambique  To support the medium-term expenditure framework (MTEF) and country budget processes  To make available external finance forecasts and trimester disbursements  To serve as an instrument to allow for the analysis of the impact of externally financed programs and projects  To improve coordination and harmonization of external finance information between sectors, the GoM, and DPs 12. Up until 2014, ODAmoz collected DP data based on this mandate, but it then went temporarily offline in 2015. The main cause of the 2015 shutdown was a failure to coordinate the renewal of the VMware license for the server (explained more in depth later). In mid-2016, the system came back online and, to date, nine projects have been entered, from Austria, Belgium, Germany, and Spain. 13. The 2015 shutdown was symptomatic of larger issues limiting the system’s relevance and usability. The ODAmoz platform requires advanced technical skills to make basic system alterations, and technicians with the necessary skills were neither identified locally, available within a reasonable time frame, nor cost-effective, according to interviewees. ODAmoz therefore could not be adapted to changing demands for reports or new data fields. The system was unable to produce the necessary updated reports to inform the GoM’s planning and budgeting process. When new information became available on donor results from the PAP’s Performance Assessment Framework (PAP-PAF), new fields could not be created in ODAmoz to store the data. Then, when the Government restructured and changed the names of key ministries, system administrators could not update ODAmoz’s drop-down options available to users. Data entry became harder for users and system data less accurate, as ODAmoz became increasingly outdated. When the system went offline in 2015, it was already losing relevance for both the suppliers and users of aid data. 1.3. Aid Data Demand, Supply, and Use Data Demand 14. Demand for aid data in Mozambique was judged by the assessment team to be high. Demand comes from the MEF, other government institutions, the DP community, and the wider public. 5 Aid Data Management Assessment - Mozambique Box 1: Demand for Aid Data  The MEF’s DNPO and CEDSIF demand aid data for the planning and budget process, tracking budget support commitments and disbursements, and reporting expenditures.  The MEF’s DC demands aid data for annual aid reporting and coordination processes.  The MEF’s DNT demands aid data for debt management and macroeconomic forecasting.  The MEF’s DEEF demands aid data to plan, evaluate, and prioritize public investments.  The MEF’s DNMA demands aid data to monitor and evaluate donor -funded investment projects.  MINEC demands aid data when approving DP programs and country strategies.  Line ministries demand aid data for annual planning and budget processes and for tracking projects.  DPs and implementing partners demand aid data for project planning and management.  The PAP-PAF process demands aid data to monitor aid effectiveness and coordinate between DPs and government.  Sector Working Groups (SWGs) demand aid data for coordination between sector stakeholders.  Provinces and subnational administrations demand aid data to track projects in their areas and regions.  Civil society organizations (CSOs), journalists, and citizens demand aid data to hold government and donors to account.  The wider public demand aid data to understand what projects are taking place and participate in planning. 15. While data users differ greatly, the assessment found that most data requested was the same. In general, interviewed users wanted to know which DP is doing what, where, and when and how much it costs. Overall, users wanted to receive aid data in formats that are easy to use, such as Excel spreadsheets with project names for the DNT or A4 printable/PDF project profiles for civil society. A few users also required specific coding, such as Chart of Accounts (CoA) codes or loan agreement numbers. Others required additional, unique fields such as public investment management (PIM) project ID codes or more detailed sector codes. Regarding the former, a strengthened relationship between aid data management and public expenditure would lead to broader efficiencies in overall development spending, a topic that is already under discussion between the GoM and World Bank. Data Supply 16. Mozambique uses ODAmoz, a web-based AIMS to collect and supply data. Web- based systems are a standard platform used in aid recipient countries because ‘flat’ formats, such as Excel, are too limited in their functionality.5 DC sends quarterly e-mail requests to its list of DPs’ focal points to enter aid data directly into the ODAmoz website. DPs, which have individualized accounts to enter data on the backend of the platform, then have 15 days to complete data entry before the system is locked again. 17. Data entry is done manually by each DP. Most ODAmoz data is typed, or copied, from the DPs’ own internal project management systems and then adjusted and analyzed to fit the platform. DC previously provided regular trainings6 to new DP focal points on using the system; however, such trainings have become more and more infrequent and are scheduled on an ad hoc basis. 5 In particular, multidonor projects are quite hard to capture in ‘flat’ formats, which are often employed in simpler data collection exercises. Furthermore, online platforms enable large numbers of users to enter —and access—data simultaneously; this is particularly important as it quickly becomes difficult to manage the process of compiling and re-sharing spreadsheets with large numbers of individuals. 6 Besides trainings, there is also an ODAmoz user manual. 6 Aid Data Management Assessment - Mozambique 18. A small amount of data in ODAmoz is supplied from international databases; however, not all potential sources have been integrated. International sources that have been linked include the OECD DAC’s Creditor Reporting System (CRS), DFID Devtracker, World Bank Client Connection, and World Bank Statements (that is, for loans). No data has been sourced from the International Aid Transparency Initiative (IATI) Registry, which houses standardized aid data from 473 DPs and nongovernmental organizations (NGOs).7 To date, no validation efforts have been conducted. 19. Data was previously only available on donor commitments and disbursements; however, in recent years, additional expenditure data is becoming available. DPs are increasingly being asked to report on expenditure in other reporting formats. This data was not originally captured in ODAmoz, as reporting such data used to be considered too much of a burden to request from DPs. Given the recent changes in ODAmoz, however, it may be useful to include the data going forward. Data Use 20. ODAmoz has yet to become established as the main source of aid data used by stakeholders in Mozambique. Most aid data used for reports or planning is gathered instead through separate, individual requests sent to in-country DP offices and not from ODAmoz. None of the DP stakeholders interviewed reporting using ODAmoz to obtain aid data. As a result, DPs are being asked for data multiple times, in multiple formats, and through multiple staff, including from and through their headquarters. Aid data is requested through separate spreadsheets, e-mails, or written documents (such as PAP-PAF forms), occasionally in hard copy. Donor responses to these requests for data are typically tailored to the format of each request or by sending project documents, such as logframes, that were developed for other purposes. This system of multiple requests for data is inefficient, with DPs fielding frequent requests from different departments, which likely causes increased data gaps or human errors. 21. Ad hoc aid data requests have varied levels of success in getting responses from DPs, often depending on the strength of the existing relationships between the requestor and DPs. Coordinating line ministries or ministries with a formal/legal relationship with a DP (such as the DNT or MINEC) reported finding it easier to obtain data, and the data they received was of sound quality. Users without any of these relationships, for example, civil society, the wider public, DNPO, DEEF, and to some extent, DC, found it more difficult to obtain the data—particularly off-budget data, which is not captured elsewhere. 22. According to the assessment interviews, users who were able to access data typically did so using one of three routes:  By using the contacts they have at DP offices through joint working on projects, such as line ministry staff, subnational administrations, and implementers/NGOs  By leveraging a legal, contractual, or formalized requirement—for example, when G-14 DPs submit their general budget support (GBS) or pooled fund commitments as part of the PAP process, when MINEC collects country strategies, or when the DNT collects data on disbursements made from loans (contracts) guaranteed by the GoM 7 Doing so could save data entry users a lot of effort, as well as allow for data validation; however, IATI data are generally not granular enough to be of interest for national-level aid data management efforts. 7 Aid Data Management Assessment - Mozambique  By being part of a DP-led process, for example, SWGs 8 Aid Data Management Assessment - Mozambique 2. Existing Issues 23. Mozambique’s current system of aid data management is fragmented and inefficient, with many potential sources of data left untapped. Figure 1 presents a visualization of the current state of aid data management in Mozambique.8 The left-hand side of the flowchart represents the supply of data from DPs. In the middle, the chart maps the institutions and systems that collect and transfer the data, using key categorizations of the different pathways for aid data. The right-hand side of the flowchart represents the core uses for the data, including the GoM budget and expenditure processes, and SWGs for DPs. Many other potential uses of the data are possible; however, this flowchart highlights the key functions. 24. There is a large degree of potential value added in boosting the GoM’s ability to capture and manage aid data. The diagram also displays a ‘potential gain’ block toward the top right, representing the data that is available—and possibly being supplied and captured— but is not currently connected with other processes, and thus it remains unused. 25. Addressing these issues will improve efficiency of managing domestic and foreign development resources. Proper aid data management ensures that aid data is used in the MTEF and national budget processes. 8 Figures 1 and 2 are not to scale; nevertheless, the relative size of the bubbles corresponds to the estimated percentage of the overall category. 9 Aid Data Management Assessment - Mozambique Figure 1: Flowchart of Aid Data Management Status Quo 10 Aid Data Management Assessment - Mozambique 2.1. Data Collection Issues 26. ODAmoz was designed with clear objectives to simplify and centralize aid data collection and management; however, recent challenges have limited the system’s ability to deliver on that mandate. The current system, where ODAmoz is not reliably online and does not produce usable data, has led to DP reluctance to spend time entering data. Without being linked to other government or DP processes—in particular, with the planning and budgeting process—ODAmoz data entry quality was reduced, with few incentives to fix problems when they arose. Instead, many stakeholders developed and used independent aid data collection systems, such as sector-specific spreadsheets, that were better tailored to their particular needs. In the health sector alone, six separate aid data exercises arose in parallel to ODAmoz.9 27. The most pressing issue is that ODAmoz is not using the national budget classification categories. Currently, aid data cannot be easily combined with budget data to analyze all development spending, regardless of the source of funds. For example, although sector data is currently collected, the data uses the (old) OECD DAC purpose codes and cannot produce a report with sectors that are recognized by other GoM processes. This function is essential for ODAmoz to demonstrate relevance and usefulness for DPs and the Government, especially during the planning and budgeting process, which, in turn, will incentivize users to supply more and better data for the system. 28. Current data collection processes are time-consuming and duplicative, and significant amounts of aid data are not captured at all. These challenges led to a negative trend where more data is lost—or captured but not shared—which then limits aid data use. This subsection details the specifics of these issues. 29. ODAmoz is unnecessarily complex, with over 50 mandatory data fields. Users who complete all available fields (including optional ones) can fill up to 112 data fields for a single project. Having too many fields means data entry is time-consuming and tedious, leading many users to skip fields. Indeed, a review of the data shows that many fields are left blank, suggesting that either the data is not readily available or DPs skip fields because there are too many.10 30. Manual data entry leads to a high risk of human error, especially since many DP focal points are not trained in using the system. According to the DPs interviewed for this assessment, typing aid data from internal project management systems into ODAmoz is a time-consuming process—exacerbated by system-specific issues (developed later in the report)—with many opportunities for data entry error. DPs reported varying degrees of difficulty using ODAmoz, with many commenting on the lack of clarity around definitions and field delineations. DC previously provided regular trainings to new DP focal points on using the system; however, such trainings have become more and more infrequent and are scheduled on an ad hoc basis. There is an ODAmoz user manual; however, given the complexities around aid data fields and definitions, many questions and issues need to be addressed and resolved by DC staff. 9 Survey of External Funds (Inquérito de Fundos Externos, IFE); International Health Partnership (IHP+) Survey; Spending in AIDS Measure (Medição de Gastos em SIDA, MEGAS); the WHO’s National Health Accounts (Contas Nacionais de Saúde, CNS); World Bank’s Health Expenditure Review; and Monitoring and Analysis of Financial Resources (Monitoria e Analise de Recursos Financeiros, MARF). 10 ODAmoz user interviewees claimed that it was generally a bit of both. Regarding the latter reasoning, many fields do not have any clear users. 11 Aid Data Management Assessment - Mozambique 31. Project data entry often requires input from several people, organizations, or groups, further hindering complete data collection. For example, one DP might provide the basic project details and committed funds; the implementing partner might supply the current level of expenditure, the final project locations, and the logframe; and the GoM might supply the conversion to the nation sectors and appropriate CoA codes. As discussed below, the current system is not designed to allow data entry on a single project from multiple users, which results in extensive off-line coordination, errors, or data gaps. 32. Many aid data collection efforts are overlapping and/or duplicative, requesting information that is already being gathered by another source. Figure 1 clarifies that, although there is aid data flowing in Mozambique, it is not necessarily flowing through ODAmoz (that is, a single, centralized platform). Data entry into ODAmoz is not comprehensive:11 only 36 percent of disbursements from 2014 were correctly reported in ODAmoz, according to 2014 PAP matrix indicators 12 and 13 (the latest year for which data is available).12 The assessment team found that with multiple, competing demands for data, DPs are likely to prioritize other data collection requests from collaborating partners instead of ODAmoz data entry. 33. Most requests include the same basic fields (for example, project name, sector, start date, and end date). This is an inefficient use of the DPs’ and GoM’s time and effort. Furthermore, DPs may be confused about where to submit data, given the multiple repositories within various GoM ministries, departments, and agencies (MDAs): it is unclear who is collecting what data and for what purpose. With the confusion caused by multiple repositories collecting the same data, it is possible that DPs only complete some submissions, but not all, leaving each repository incomplete and the GoM without any authoritative source of aid data. As such, significant amounts of aid data (for example, all aid from non-G-14 DPs not covered by sector aid surveys) are collected independently of an integrated national planning process, contravening one of the GoM’s primary objectives for ODAmoz. Independent data collection efforts are rarely consolidated with ODAmoz’s repositories, thus risking the loss of critical data. Part of this fragmentation is the result of decreasing use of budget support, fewer DPs in the G-14 group, and increasing aid from China, which does not engage in DP cooperation measures or disclose its aid data. An additional factor, however, is that the latest G-14 memorandums of understanding (MoUs) no longer require DPs to report their on-budget but off-Single Treasury Account (Conta Única do Tesouro, CUT) support. This is a large—and growing—loss of data. 34. Collected data is not effectively shared or used, leading to significant missed opportunities for evidence-based analysis. Given the important role of foreign aid in Mozambique’s development portfolio, access to—and utilization of—this data during the national planning and budgeting processes would lead to substantial efficiency gains in both the allocation and use of domestic development resources. Yet, the various organizations collecting data are holding on to—not sharing—that data. This is represented visually in Figure 1 by the lack of connections between data collection tools and recipient ministries or units. For example, 11 See http://www.eeas.europa.eu/archives/delegations/mozambique/documents/news/20140704_1_en.pdf. 12 http://ago.org.mz/wp-content/uploads/2015/05/ANEXO-IV_AM_RA-2015_Cumprimento-da-Mtriz_QAD- dos-PAPs_ 15052015.pdf. 12 Aid Data Management Assessment - Mozambique  All DPs sign new programs and country strategies with MINEC; however, these are not then used to identify lists of actors, volumes of aid, or similar projects. Furthermore, the documents—many of which are public—are not shared within the GoM;  All G-14 DPs submit data on their GBS and pooled fund commitments to the DNPO; however, this is not made available in a sharable format;  The DNT’s debt department manages precise information on all concessional loans in their Commonwealth Secretariat Debt Recording and Management System (CS-DRMS) database; however, the data is not shared with other GoM units;  Data in ODAmoz is used solely for an annual report (which was not produced in 2015). Data is not used in the GoM’s planning and budgeting process, reports for line ministries, or packaged for SWGs, leading to significant lost opportunities around efficient domestic resource planning; and  Sectoral data collection exercises are not compiled into a central resource. As an example, the MEF does not systematically collect the data captured by line ministries. 35. ODAmoz does not have a data validation process to ensure database accuracy. According to the analysis of the assessment team, significant inaccuracies can be found in ODAmoz’s data. In other regional countries, such as Rwanda, potential quality issues are addressed proactively (weekly or monthly): checking projects for double counting, exchange rate errors, and missing fields and following up with DPs that entered inaccurate data.13 ODAmoz could produce automated reports that flag the latest changes for DC staff to validate. For some DPs, (those without country offices, for example) DC staff may need to directly enter data, similar to a hybrid system used in neighboring Tanzania. Furthermore, data validation could be built into the management of the AIMS.14 For example, a user should not be able to enter disbursements that sum to greater than the overall value of the project, an error noticed by the assessment team on several occasions in existing ODAmoz projects. 2.2. Institutional and Coordination Issues 36. Two separate institutions manage the ODAmoz platform and house the server, which leads to miscommunication and a lack of authority to fix problems. Discussions with DC, the manager of ODAmoz, and the National Institute of Information and Communication Technology (INTIC) of the Ministry of Science and Technology (MCTESTP), its host, uncovered a lack of institutionalized channels for communication or a formal understanding of roles. The institution responsible for the system’s use has no formal 13 DP provision of data to the AIMS, with subsequent government validation of data is generally the default delineation of responsibilities. That being said, some countries collect data themselves based on official project documents and agreements between governments and DPs and then also use this information to manage their donor community and hold them accountable for what they have promised to deliver. A hybrid of this currently takes place in Tanzania. 14 Identification of such features needs to be done by someone familiar with aid management and not left to developers, as it is the day-to-day experience with aid management that helps identify such issues (for instance, knowing that disbursements can be negative but commitments cannot or that a project that is on-treasury cannot be off-budget). 13 Aid Data Management Assessment - Mozambique control over its usability, much less any formal authority to ensure that the platform is online and performing. 37. Communication gaps between the government entity managing ODAmoz (DC) and the entity housing its server (INTIC) over hosting arrangements forced ODAmoz offline for almost a year. Communication failures led to delay of the payment of the annual fee for ODAmoz’s VMware license, effectively shutting down the platform.15 38. The software on which ODAmoz runs is the property not of the GoM but of an international nonprofit, Development Gateway (DG). DG is an industry leader that develops and manages proprietary AIMS called Aid Management Platforms (AMPs), which are used in many donor recipient countries. DG took ownership of ODAmoz following its incorporation of the private firm ODAdata, which had developed the original ODAmoz system. DG also supervised the system upgrade to ODAmoz 2.0. Interviews with DC staff indicate that they are unclear whether they can modify or update ODAmoz’s software code without the permission, or assistance, of DG. 39. ODAmoz has few feedback mechanisms for stakeholders to discuss needed changes, ask for help, or receive updates on the latest issues. An aid data steering committee could perform these functions, similar to the former ODAmoz Steering Committee. 40. Fragmentation of the GoM’s relationships with DPs contributes to poor aid data management. The majority of DPs in Mozambique are no longer part of the PAP G-14 group. This means that most DPs have limited aid data relationships with the GoM, beyond sending MINEC copies of large programs and country strategies. Regular contact for most projects is through line ministries. Even within the MEF, coordination relationships with DPs are fragmented, as all MEF units have their own, independent relationships: the DNPO collects PAP GBS and pooled fund data, while the DNT collects loan data. Many major DPs are also managed by MINEC, not the MEF.16 Multiple contact points from the MEF for DPs undermine the central coordinating function of ODAmoz. 41. DC is not currently proactive regarding following up with non-compliers, according to the DPs interviewed for this assessment. Successful AIMS teams in neighboring countries reach out to DPs that do not submit timely data entries, ensure regular training of DP focal points, and maintain an updated list of DP contacts. DC partially fulfils this mandate: while e-mailing quarterly calls for data entry, it attaches the list of DP focal points for review. This method, however, excludes DPs whose focal points have already left their post (or institution) and may not follow up with their replacement. DC could be more proactive by sending staff to attend DP coordination meetings, such as the SWGs, quarterly DP-GoM forums, PAP meetings, and debt negotiations discussions. In this context, DC could then verify the ODAmoz focal points and update contacts for missing DPs. DC could also be proactive about supporting DP coordination through identifying how, and when, DPs access and use ODAmoz data and surveying users as to how the platform might be more useful. 15 As an aside, given that free alternatives exist, Mozambique’s AIMS need not rely on any paid soft ware licenses. 16 While DC and MINEC jointly handle all bilateral and multilateral donor relations, the Ministry of Justice handles local NGOs (MINEC handles international NGOs); it is unclear who takes care of private implementers. This leads to yet more fragmentation. 14 Aid Data Management Assessment - Mozambique 42. Key GoM institutions have limited knowledge of ODAmoz and/or have limited awareness of its functions or capability. Consistent communication is critical for ODAmoz to establish standing as a central coordination body and a credible source of data. For example, even when ODAmoz went offline, DC could have continued to collect data using alternative methods, such as online surveys or a flat format, which would have allowed DC to continue producing annual reports. No report was produced in 2015, with no indication that a retroactive report will be produced either. 43. DC is currently not providing regular support to DP and GoM staff on using ODAmoz. In addition to regular training, a core DC function should be troubleshooting and answering user questions in a timely manner. Many interviewed DP contacts expressed confusion about data entry, definitions for fields, or data entry responsibilities. 44. The GoM does not have dedicated staff supporting ODAmoz, which diffuses responsibility for making the site functional and effective. Currently, many GoM staff, in several different directorates and departments, officially work on ODAmoz but have less than 10 percent of their time committed to managing the platform. Given the experience of other countries at similar developmental levels, such as Tanzania, an AIMS requires one to two full-time staffers to function effectively. 2.3. Technical and IT Issues 45. ODAmoz is not user-friendly enough for nontechnical staff to perform minor backend enhancements and fixes. For instance, ministry names should be updated, sectors changed, or organizations added without staff needing advanced technical skills to perform these tasks. While many organizations focus on manuals to help improve technical capacity, experience from other countries suggests that additional manuals rarely resolve technical capacity issues. An ideal AIMS can be operated without complex manuals;17 this requires simplification on the user side and higher-capacity hosting. 46. Relatedly, ODAmoz currently has an inappropriate split between adjustments that can be made by nontechnical staff and adjustments that require programming skills. Some field options, such as DP names for drop-down menus or user accounts, can be administered through the ODAmoz master user account and access portal. However, choices for the sectors, ministries, locations, and pooled funds are hardcoded into the SQL schema, which requires IT skills to update.18 47. ODAmoz does not have functional exports of data that can be readily integrated with other government systems. Data exports, which can be designed as ‘ready to import’ reports into other databases, can improve the use of ODAmoz data by other GoM institutions. The DNPO, for instance, needs reports with full CoA codes for on-treasury projects to use during the budget process. Similarly, sectoral monitoring and evaluation (M&E) systems could benefit from a list of projects with logframes. Central and line ministry budget and planning officers require off-budget commitment and disbursement data, to complement 17 For example, ODAmoz’s current manuals require that the user has knowledge of Rub yGems, a skill currently lacking within the ministry. This issue contributed in part to the shutdown. 18 As is, technical trainings are carried out in Brazil and even the smallest of changes can require costly missions from Washington, DC. As the AIMS generally requires regular (every six months) adjustments and tweaks, as well as emergency fixes within 48 hours, it would behoove DC to procure these skills locally. The success of e- SISTAFE and the substantial community of developers present in Mozambique suggest that this should not be difficult to achieve. 15 Aid Data Management Assessment - Mozambique IFMIS-managed on-budget and on-STA data to plan future activities and investments. For this to work, however, the AIMS needs to follow the budget programmatic structure, something which ODAmoz does not do.19 48. Most users of ODAmoz require not just data but reports; however, the portal lacks the ability to generate user-friendly reports. Having predefined reports makes accessing data quick and easy, increasing the use of ODAmoz data, and therefore the incentive for users to enter data. ODAmoz currently recognizes this need by featuring reports on the main page—an improvement over many other AIMS layouts. Yet, it could improve the report templates available for download, including templates that are aligned with the import requirements from key data users. A few predefined reports are available for download (with additional suggestions in the next section); however, many are in need of technical fixes. 49. ODAmoz does not have the flexibility to allow multiple financing instruments for a single project. This issue was noted by interviewed DPs and confirmed by the assessment team. Currently, projects can be entered either as a grant or a loan, and thus projects with both grant and loan funding must be entered twice. In more flexible platforms, such as Bangladesh’s AIMS, the project value is the total value of all the associated financing instruments.20 This is important because projects often have multiple funding sources: perhaps both a grant and a loan instrument, from different funders, or with different start and end dates. 50. While Mozambique has many pooled funds and joint funded projects, ODAmoz lacks a field or marker to flag pooled or jointly funded projects. Currently, its financing separately, often with a different name from the other components. This makes it difficult and time-consuming to identify and track joint funded projects. A better practice would be to allow DPs to append their financing to an existing project shared with another DP. For example, once the first DP adds the second as a funding agency, the second DP then receives permission to enter its financing data. 51. ODAmoz currently does not allow more than one user to edit or update a single project, leading to an increased risk of data gaps. Increasingly, DPs do not have all the data requested by ODAmoz in their own systems, with necessary data collected by implementing organizations. This is particularly the case for World Bank projects. Ideally, while a DP may enter a new project, name, and value, it should then be able to assign an implementing partner to then log in and enter additional data on disbursements and locations. 52. ODAmoz does not currently have safeguards to prevent double counting. Many suggestions for improvements mentioned in the next section will eliminate some forms of double counting; however, additional measures can add safeguards against double entry. For example, when a DP is entering a new project, ODAmoz could show similar projects (similar 19 A successful international example of this process is seen in Liberia, where the AIMS was successfully aligned to the program codes from the government’s IFMIS using the same numbering system for the government’s finances (that is, budget, projects, and expenditures). The AIMS uses a unique project identifier, or a UPI, to reference projects in IFMIS; this helps prevent double counting and enables the government to then track individual projects easily across both systems. Furthermore, each AIMS project is also aligned with the nomenclature used in the government’s MTEF (sector codes, sector names, ministry and agency code, ministry and agency name, MTEF policy code, and so on). Liberia’s AIMS is updated before the budget preparation process and its data then prepared for use in national planning. There are ongoing efforts to determine how to replicate this practice for potential adoption in other country systems in the region. 20 For example, the system could be configured so that the start and end dates of the project are the start date of the first financing instrument and the end date of the last instrument, respectively. 16 Aid Data Management Assessment - Mozambique sector, dates, financing amount, and organizations) for the DP to check, ensuring it is not reentering a project that has already been entered. In other AIMS, double counting occurs most often when a project is entered both by a bilateral donor and by the multilateral agency implementing the project. This could be resolved by allowing roles for ‘funder’ and ‘implementer’, with the flexibility for organizations to add themselves to either list, as some bilateral DPs both fund and implement parts of a project. Reports can be produced listing projects by either their funders or by the implementers, removing the incentive to double report (Kenya’s eProMIS allows for this). This way, both the funder and implementer receive credit, regardless of who enters project information into the AIMS. 53. ODAmoz is currently unable to capture unprogrammed funding, that is, funding that is not yet allocated to a specific project. This means that the forward projections are highly inaccurate, particularly for DPs with shorter programming cycles. International experience suggests that the best solution is to allow a category for ‘currently un- programmed’ support, for example, to a specific sector, to be temporarily added for use during the planning process. 54. DPs currently cannot upload documents into ODAmoz. Document storage could be a useful feature to increase the amount of information available in ODAmoz. For example, MINEC could upload and store copies of the publicly available bilateral agreements and related documents they collect;21 DPs could upload mission reports, logframes, and other documents. The ability to view the data in these documents, without the laborious process of typing it out into ODAmoz fields, would help establish ODAmoz as a central repository for data without creating hundreds of sector-specific fields. 55. ODAmoz does not allow for disaggregated distinctions in budget fields. Few development projects are 100 percent on-budget: most DPs also have funds for evaluations and their own technical assistance staff working on the project. Making fields such as ‘on- off-budget/treasury’ and ‘channel of delivery’ more flexible would allow DPs to more accurately reflect their projects. 56. ODAmoz does not have any tables converting between international coding systems and those of the GoM. Providing such tables could make data entry simpler, as well as improve consistency. For example, Mozambique-specific sectors are required to make the data usable in national-level processes, and a table converting the user entry of DAC sector ‘11200 Basic Education’ to Mozambique’s national sector ‘Education’ might make data entry easier for DPs whose databases are organized by DAC sectors. 57. Whether it is the server, the way it is programmed, or the Internet connection, ODAmoz’s Excel reports can only be downloaded with significant delay. A standard Excel report can be generated in approximately 60 seconds; ODAmoz currently takes over five minutes to produce a report, regardless of how many DPs’ projects are being queried. For users with unstable Internet connections, such a low connection speed and subsequent delays are especially problematic. Adopting a simpler platform with enhanced report production capabilities and/or a more modern server and server software will likely solve this issue. 21 Alternatively, MINEC could also include a clause in all bilateral agreements requiring data disclosure to DC, a proposal that the assessment team mentioned twice to MINEC representatives. 17 Aid Data Management Assessment - Mozambique 58. ODAmoz does not have an autosave function, causing many DPs to lose data. An autosave functionality is a standard component of newer AIMS, allowing users to return to partially entered projects without difficulty. This is particularly important for countries with unstable Internet access. 59. There is no auto-backup functionality. The MEF’s IT team created one backup of the platform’s server; furthermore, the external hard drive is kept off-site for added protection. Backups of server data are needed on a regular basis, however, and should be saved in an easy-to-read format to prevent possible data loss. 18 Aid Data Management Assessment - Mozambique 3. Recommendations 60. A potential reorganization of aid data management to improve sustainability is shown as a flow chart in Figure 2. Improved data collection procedures could solve duplication issues and clarify institutional relationships. The demand for this data is already high, as witnessed from the proliferation of ad hoc parallel data coordination mechanisms. This flow chart addresses the complexities and overlaps of data collection, which was shown in Figure 1. The vast majority of data collected by these systems is the same: each piece of data is therefore supplied and recorded multiple times. A single, centralized repository for aid data (that is, an AIMS), where all users enter data into one system and which then supplies everyone with data, is likely to be more efficient. It would also deliver better quality data with less effort:  Data has to be entered only once, allowing for more comprehensive data entry.  Stakeholders only need to learn and operate one system.  Data links between DPs and the GoM are simpler and clearer, and data is requested only once.  Lines of authority on aid data are clarified, strengthening incentives to complete data entry and leading to more consistent data sharing.  Increased collaboration on data entry will help strengthen validation and verification, improving data quality. 61. Consolidating systems into a single, centralized AIMS would require agreements from stakeholders to streamline data collection currently done through other systems. Figure 2shows the potential gains from a centralized AIMS, such as ODAmoz or a successor platform. However, DPs would need to shift their current data management practices to focus primarily on ODAmoz to both provide and retrieve data when needed.22 To function effectively, a single AIMS would need to fulfill four key requirements:  It has to collect the data everyone needs.  It needs to share that data with everyone.  It must be user-friendly.  It relies on increased coordination with all stakeholders. 62. The World Bank’s recommendations center on redesigning aid data management and capturing aid data as an input into the planning and budgeting process. This can best be done by closely aligning aid data management processes with the Government’s budget. The AIMS and IFMIS should be integrated, or at least compatible, as is currently being done in various ways in Liberia, Rwanda, and Somalia. For Mozambique, 22 Alternatively, one of the other current systems could be chosen to be expanded. However, ODAmoz, managed by the MEF, is likely to be a good choice as most of the current systems are designed to meet more specific needs and are MS Excel-based, so they are difficult to extend to either many fields or users. 19 Aid Data Management Assessment - Mozambique this would require basing ODAmoz—or its replacement—within CEDSIF and the MEF’s existing budget data management mechanisms and processes. 20 Aid Data Management Assessment - Mozambique Figure 2: Flowchart of Improved Data Management 21 Aid Data Management Assessment - Mozambique 3.1. Solutions to Data Workflow and Collection 63. Global experiences with AIMS provide a clear picture: the majority of AIMS users want fairly simple and standardized aid data. They want to know who is doing what, where, and when and how much it costs.23 Interviews with ODAmoz stakeholders, as well as knowledge from aid data management experiences in other countries (particularly in Somalia, where a similar assessment was recently undertaken by the World Bank), led the assessment team to develop the following two categories: core fields that are needed by multiple users and additional fields that are needed by only a few users. This is necessary because the average time taken to enter a new project and update a project should be minimized: approximately 20 minutes to enter a new project and 3 minutes to update a project—the average estimated time it takes for AMP users. Shortening, and simplifying, data entry will increase DP buy-in and voluntary compliance with data collection requests. Core fields are likely to include the following: Table 1: Likely Core Data Fieldsa ‘Core’ Data Needs Relevant AIMS Fields Who Who is providing funding?  Funders Who is involved in implementation?  Implementers What What is the project name?  Project title What is its objective?  Project objectives/purpose Which sectors does it target?  Sectors  Share of project value by sector Where Which projects are active in Mozambique?  Region Which projects target a specific region?  Share of project value by Region When When will the project be implemented?  Start dateb  End date How What is the overall budget of the project?  Project value much How much has been spent to date?  Amount spent to date How much was spent last year?  Amount expected to be spent next year How much is expected to be spent next year?  Project reporting currency  Exchange rate to MZN/USD More Where can I find out more information?  Document uploads or links  Project contact details Note: a. Linking aid projects to results and SDG reporting would increase the number of data fields. b. For example, having project planned start date, approval date, effectiveness date, first disbursement date, and actual start date complicates the data entry process, especially as the definitions for these fields vary significantly between DPs. Given that use of this field is generally approximate (for example, just locating the project within a year is generally sufficient), all fi ve fields can be replaced by a simple ‘start date’, for which any of the above definitions can be used. 64. To build confidence in the system, it is best to start with a minimal set of fields and add more after the platform has been demonstrated to be working for several years. Each additional field increases the effort required to enter the data and reduces the chance of having a complete dataset. An AIMS such as ODAmoz should not overreach: it will always be quicker and easier to consult existing contracts in government or donor offices to obtain the most detailed level of project-specific data. Sector institutions are likely to ask for additional, sector-specific fields; however, these requests should be rigorously evaluated as to whether (a) they are needed by multiple users, (b) those users actually have a clear business need for the field (such as an already running process), and (c) the data exists. Non- 23 The assessment recorded very little interest in how well aid was being used, no doubt a function of the poor quality and quantity of aid data currently being recorded. 22 Aid Data Management Assessment - Mozambique mandatory fields could be added to assess specific data needs; however, this should be limited to help keep data entry as simple as possible.24 Sectors that want to conduct additional analysis with ODAmoz data can use downloaded spreadsheets that are expanded using supplemental data from project documents.25 65. Improving how fields are captured—and the appropriate structure of the data/database to capture them—is critical for overcoming current data sharing gaps. Fixing the database structure is vital to ensure that, by collecting the right data, ODAmoz can then supply the right data. Three examples are cited:  To be useful for the DNPO and line ministries, data needs to be coded according to the GoM’s CoA, where possible. This means that, for example, ODAmoz should use national sectors from the CoA to enable aid data to be easily inserted into the GoM processes alongside its financial data.26  For the DNT to be able to use ODAmoz to track new loans and their expenditures, ODAmoz needs to allow multiple financing instruments for each project. This involves not just providing a total value for the project but one that is an aggregate of the values of the different financing instruments (as a single project may comprise both loan and grant financing). Each instrument also needs its own start and end dates for projects that are extended by adding new financing.  For compatibility with some GoM systems, it may be useful to include project or instrument ID codes (that are shared between systems), as project names can vary; this would speed up the process of matching data between systems. An example would be PIM ID codes or CS-DRMS ID codes. 3.2. Solutions to Institutional and Coordination Issues 66. DC needs to clarify the different roles and responsibilities it holds in relation to ODAmoz. If ODAmoz remains hosted at INTIC, direct lines of communication need to be established between INTIC and the MEF, ensuring that the platform is online, functioning, and performing. INTIC must also be accountable for ODAmoz through a clear, formal agreement between the MEF and MCTESTP. This agreement must clarify whether INTIC is solely responsible for hosting or also responsible for administration. Alternatively, ODAmoz could be hosted at CEDSIF—which also manages e-SISTAFE, hosted on commercial server space rented and managed by DC (similar to existing websites)—or hosted and managed by a private firm by outsourcing with a service level agreement.27 Suggestions on how to resolve this institutional issue bleed into technological issues, given the importance of the platform server; as such, more detailed recommendations for this issue can be found in the next 24 Exceptions may be where a key data process requires a few core fields. For example, data collection on G-14 annual reporting of GBS and Pooled Fund commitments may be worthwhile to add as core fields. 25 For example, if the Food and Agriculture Organization of the United Nations (FAO) and the Ministry of Agriculture wish to produce analysis on how aid is contributing to rice production, they could export a list of all the projects in the agriculture sector from ODAmoz to MS Excel and then add additional fields specific to rice projects with data from project documents. Users could view project documents uploaded into or linked to ODAmoz and use the contact details to solicit more detailed project information. 26 It should be noted that the OECD has recently created additional sector codes that make it easier to align aid with budget sector codes. 27 The level of Internet connectivity and uptime offered should be factored into this decision (such options are detailed more in depth in the next subsection). 23 Aid Data Management Assessment - Mozambique subsection. Nevertheless, it should be noted that hosting and management of ODAmoz within CEDSIF would have the added benefit of ensuring coordination with e-SISTAFE. 67. The ODAmoz Steering Committee should be relaunched to improve communication and allow for feedback mechanisms among stakeholders. Based on the assessment team’s experience with similar committees in other countries, DC could lead the committee representing the GoM, with a DP co-chair that is ideally non-G-14 as a way of promoting inclusiveness beyond the traditional DPs. The committee should meet quarterly and involve all relevant stakeholders, including all DPs (G-14, UN agencies, and nontraditional DPs); MEF national directorates; MINEC; key line ministries; and select CSOs. Such a committee could institutionalize communication channels and ensure that bottlenecks and other problems are identified and resolved swiftly. 68. ODAmoz’s aid data collection mandate should be reinforced to address fragmentation in the GoM’s relationship with DPs. DC should restart engagement with DPs by updating and circulating the annual ODAmoz data collection and report production calendars, as well as a flow chart outlining data entry responsibilities and actors. These documents should also be available from the online ODAmoz portal itself. Mapping and formalizing the GoM-DP relationships, and establishing the coordinating role of DC through ODAmoz, could address this issue. Centralized coordination could also facilitate consistency checks of data collected from the sectors, the DNPO, and ODAmoz. 69. ODAmoz’s mandate should be expanded to include all DPs. ODAmoz was initially designed to capture G-14 DPs and then later UN organizations, which also contribute to budget support. Given the rising share of off-CUT aid from non-G-14 DPs, there is a growing need to diversify the target users of ODAmoz beyond this original group.28 A key step to demonstrate this inclusivity might be to remove the ‘ODA’ from ODAmoz and, therefore, portray a greater openness to non-ODA, South-South coordination providers. ODAmoz could also be expanded with additional features, useful for a wider range of DPs, that support macro-forecasting, calculating the Balance of Payments, budget planning by line ministries, and SWG coordination. 70. DC could increase awareness of ODAmoz through strengthened communications, such as e-mailing predefined ODAmoz reports on a monthly or quarterly basis to a broader listserve. For example, all 22 sectoral groups should be sent the relevant pre-made sector report each quarter. Similarly, each region should regularly be sent the relevant report; this public dissemination should also incentivize DPs to improve their reporting. Documents using ODAmoz data should quote ODAmoz as the source and include a link, thus helping raise the profile of ODAmoz as an institution as well. 71. DC should provide a phone and e-mail helpline service to answer queries that are often straightforward but too specific to include in a user manual, such as on data entry, field definitions, or data entry responsibilities. Many questions relate to definitions or categories, such as whether to include a regional project, or how to classify a project according to national sectors. User manuals are helpful but never comprehensive, and they are best supplemented by support staff. 28 There is broad consensus within both the government and DP communities, confirmed during the May stakeholder workshop held at the World Bank Country Office, that ODAmoz should aim to capture all aid data, not just that of the ‘traditional donors’. 24 Aid Data Management Assessment - Mozambique 72. Relatedly, increased staffing within the MEF is needed to ensure effective aid data management. Sufficient staff are needed for directing and managing the platform, as well as relaunching regular trainings and providing timely troubleshooting. Ideally, the team would have one staff member with full-time responsibility and then each other staff member with part-time sector responsibility, or responsibility for a group of DPs, spending one day a week checking and following up. Tanzania divvies up responsibilities over DPs among its five full- and part-time AMP staff (as well as the four full- and part-time staff for Zanzibar). This is the absolute minimum needed for effective aid data management in an aid dependent country, but it is significantly more time than DC currently dedicates to aid data collection.29 73. Outside of maintaining a technical platform, DC staff must build regular routines around aid data management. This includes updating DP focal point lists, contacting and following up with DPs for new data, understanding collection fields, following the annual budget calendar, and maintaining a good filing system. Indeed, only a fraction of the unit’s capacity focuses on a modern AIMS and IT system, and the main factors of success are linked to organizational systems. 74. Despite these technical issues, aid data management capacity still largely depends on nontechnical incentives and workflow. One way of evaluating an agency’s AIMS management capacity is whether the same management unit could collect the necessary aid data in hard copy. 30 Thus, when DC stopped performing its basic aid data collection and reporting functions when ODAmoz went offline, it suggests that DC’s management capacity needs to be strengthened in addition to technical and IT solutions. 3.3. Solutions to Technical and IT Issues 75. DC needs an interface in ODAmoz for nontechnical users to update data fields, as the fields need to be changed regularly. The national CoA is typically adjusted every year and, as ODAmoz becomes further integrated with the CoA, it should mirror these annual changes. Millennium Development Goal (MDG) fields, which are currently hardcoded into ODAmoz, should be replaced with the SDGs. Lastly, some fields that are not part of the main project information should be editable—either added or removed—by DC staff without the oversight of a programmer. 76. ODAmoz needs additional pre-produced reports that respond to user needs. ODAmoz currently has a limited number of reports, which are visible and easy to access on the front page of the website without a login. Currently available pre-made reports include DP and project profiles and lists of projects by location and sector; however, at least six more templates are needed to respond to user needs:31  A report for the budget planning process, which would likely require a list of project names and descriptions, by GoM sector and region, summing the value expected to be spent in the next three years (in MS Excel and PDF formats). 29 In comparison, the comparable IFE data collection employs two full-time staff for just one single ministry. 30 To be sure, addressing technical and data structure AIMS issues is also a priority. ODAmoz is significantly more complicated and prone to error than other existing AIMS, such as DG’s AMPs, in the Democratic Republic of Congo, Ethiopia, Malawi, Tanzania, and Uganda. If ODAmoz cannot easily handle complex data entry, DPs will not bother to enter data, rendering the database unreliable. Similarly, if ODAmoz is not widely used by the GoM and DP actors, DPs will not see the point in devoting the necessary time for data entry. 31 Based on the assessment team’s discussions with users, as well as knowledge of AIMS use elsewhere in the region. 25 Aid Data Management Assessment - Mozambique Standard AIMS reports that give the instrument type, total value, DPs, and implementers are typically not very useful.  A report of CoA-coded comma separated values (CSV) files (with a single row per transaction) for CEDSIF for import into e-SISTAFE.  Sector-specific reports such as a report for the Ministry of Health with a list of projects and other data to replicate the IFE format.  A report listing DPs and aggregating their projects while calculating the indicators used at PAP meetings, which would save DPs the time spent in preparing these before such meetings.  Printable (and PDF) reports of province or sector summaries, which are often in demand by sector ministers and regional staff.  A report listing all loans with funder, loan value, currency, loan ID code, and sum of disbursements to date, which are required for the DNT to validate loan data against the data in the CS-DRMS. 77. Pre-produced reports need to be user-friendly. The existing maps option should be able to show more than five projects at a time, which is necessary to view all projects active in a given region on one page. Pre-made PDF reports should include a hyperlink to the source so that users can check online for updated information. Report formatting is also problematic and should be revised: pre-made report options should include filters, for example, by sector or by project status; this is currently only available through personalized reports (Relatórios Personalizados). Basic filters are a core feature of other AIMS, for example in Kenya’s eProMIS, where report templates are easily available for download, including on donor commitments broken down by budget projections, estimates, implementing ministry, and source of funds. 78. For those queries that are not covered by the pre-made reports, a general Excel export is needed to allow users to do their own analysis. ODAmoz has this feature, but it is not as user-friendly as it could be: definitions of all the fields are not readily accessible, it requires a number of clicks to find the required data, and the export can be slow. ODAmoz does not have a built-in graphing interface; however, users who wish to make custom charts are more likely to do so in Excel to take advantage of the more advanced and flexible features. Indeed, a built-in charting interface can never replicate this and so is typically an unnecessary complication. 79. There are three potential approaches—not including retaining the status quo— available for the GoM to choose to address the broader platform issues. Each approach has separate technical requirements. Table 2 highlights the various options (including maintenance of the status quo) strengths and weaknesses; the following subsections detail the options. 26 Aid Data Management Assessment - Mozambique Table 2: Advantages vs. Disadvantages of ODAmoz Options Four key Status quo - Embrace Multiple Option 1: Consolidate Systems Option 2: Reinstate ODAmoz as Sole Option 3: Redesign Mozambique’s requirements Parallel Systems (Shut Down and Incorporate ODAmoz- Aid Data Collection System, with AIMS, Preferably Housed within /challenges ODAmoz) Specific Features Improved Hosting, Some Technical Help, CEDSIF Minor Changes Data Mixed - Individual systems Poor - Not possible to capture Mixed - Can adjust existing fields (for Good - Assuming provider can deliver collection collect data relevant to them, but aid data structure needed for an example, update ministries) but cannot Mozambique’s requirements exactly (not no system collecting data AIMS in one of the current add or remove fields (for example, for just provide a system designed for other relevant for DC (unless one is Excel/paper-based systems; better budget integration), so unlikely to countries), then ODAmoz can collect all started in Excel - but likely to be complexity leading to failure. be sufficient for ODAmoz to become data required and become dominant too simplistic to meet needs). comprehensive and sustainable. system. Using and Poor - Separate systems make Poor - System not online, Mixed - Online/public system, can Good - Online/public system with all sharing data combining data difficult, not likely Excel based, no pre-made potentially program some more reports; reports for all users and formatted online, no public access, no pre- reports, less focus on data for however, not all required reports Excel/PDF export made reports. aid coordination. possible; no PDF export. Usability/ Poor - Manual data entry into Poor - Manual data entry using Mixed - May be able to solve some Good - Can incorporate all requirements Design/ multiple systems likely leads to Excel sheets resulting in issues (for example, removing unused (for example, checks on data entry, IATI Technical lack of data entry. complex compilation but works fields) but not others (for example, import, multiple reporters per project, when time and capacity are double counting, pooled projects, pooled fund structure). Can also have dedicated; not owned by DC. multiple financing instruments, automated backup, autosave, and maps translation to national sectors). with more than 5 projects and so on. Reliability and speed may improve with better hosting but no autosave, fixed maps, and so on. Coordination Poor - Multiple systems, DC (or Mixed - stronger link to a Mixed - Single system with DC Good - ODAmoz is the central system any organization) not in control. process, but owned by ownership; however, parallel systems for all aid data needs and is directly budget/line ministries, not DC. still existing (as unable to adjust linked to planning and budgeting sufficiently to meet their needs), meaning processes, resulting in greater use and continued problems with sustainability. buy-in. DC in control and in demand. Estimated 0 Minimal costs USD 2,000–40,000, plus related costs USD 50,000–500,000 Costs (hosting, licensing) 27 Aid Data Management Assessment - Mozambique Status Quo: Embrace Multiple Parallel Systems (Shut Down ODAmoz) 80. The status quo means that ODAmoz is back up and running; however, many parallel data capture initiatives are still being pursued in the sectors. Shutting down ODAmoz and embracing the sector-specific exercises would result in no additional training or funding; furthermore, there are good incentives for each entity to ensure that their own systems are sustainable. If there were additional funding, this could be used for a full-time DC staff to travel between DP offices, managing the different parallel systems to collect and share data. Such an option would require the export of all historical data to Excel, as well as the making of backups and arrangement for the transfer to other systems. However, even in the best-case scenario, all the disadvantages outlined above of duplicated entry and low access to data would remain. As such, retaining the status quo is Not Recommendable. Table 3: Status Quo - Embrace Multiple Parallel Systems (Shut Down ODAmoz) Option Estimated Cost Developer Options Licensing Estimated Hosting Options DC Capacity (USD) Timeframe Requirement Retain the status quo Zero (save for Excel skills for DC to None required 1 month to develop None required None for ODAmoz of multiple parallel potential additional maintain spreadsheets and test the but extensive to systems and shut costs to DC for a full- of projects spreadsheet manage the down ODAmoz time staff to oversee spreadsheet that will parallel systems) be needed instead 28 Aid Data Management Assessment - Mozambique Option 1: Consolidate Systems and Incorporate ODAmoz-Specific Features 81. Option 1 would seek to find the most sustainable system that is nearest in scope to ODAmoz and augment it (for example, by adding fields to the PAP Annual Reports to DNPO or to the sector-level exercises to capture all the ODAmoz fields). There would be significant additional work to compile all the Excel sheets and share the data, and it is unclear how these would be rolled out either to non-PAP DPs or to smaller sector ministries to ensure fuller coverage than at present. Again, however, as is the case for the status quo, all the disadvantages outlined above of duplicated entry and low access to data would remain. This option is likewise Not Recommendable, given the complexity inherent in compiling and managing the data. Table 4: Option 1 - Consolidate Systems and Incorporate ODAmoz-Specific Features Option Estimated Cost Developer Options Licensing Estimated Hosting Options DC Capacity (USD) Timeframe Requirement Consolidate systems Minimal, but Excel skills and None required One year to negotiate None required Little, as no system and incorporate substantial time input knowledge of aid and test integration of but much increased ODAmoz-specific management process former ODAmoz workload to collect features into other required to lobby for fields into other data for DC work system(s) and add fields from system(s) and from other parts of ODAmoz to other process(es) government system(s) 29 Aid Data Management Assessment - Mozambique Option 2: Reinstate ODAmoz as the Sole Aid Data Collection System, with Improved Hosting, Some Technical Help, and/or Minor Changes 82. Option 2 could range from relatively economical to expensive and is similar to the approach tried with the previous upgrade from ODAmoz 1.0 to ODAmoz 2.0. While this would likely lead to a substantial improvement (also through renewed effort), the failure to tackle major issues suggests this would be another short- to medium-term fix, likely working for a few years to a decade and then requiring another massive intervention after the platform becomes obsolete. For example, ODAmoz would likely still be unable to supply data to the budget process and therefore parallel systems would continue. Furthermore, the database would still not accept multidonor projects, leading to double counting. This is Not Recommended: it is not capable of addressing the systemic challenges flagged above nor would it lead to improvements in data comprehensiveness, a problem that has limited use of this data in the past. Technical Options 83. Continuing the ODAmoz platform would not incur any costs, although it is unclear if there is a way around the annual license fee for the system. The VMware license would likely still be needed and it would remain hosted at INTIC with the same connection and speed. There would not be an increase in technical capacity to make adjustments. With this solution, ODAmoz would be up and running the majority of the time, as was the case over the last 10 years. 84. There are several options to improve the hosting under these approaches. First, if ODAmoz had its own server, VMware (and license) would not be needed. Alternatively, INTIC could use a free hypervisor (for example, Xen) or virtualization solution on Windows (VMware Player). Finally, ODAmoz could be run on Windows Server with the right installed components and some assistance. These options could take place at INTIC, CEDSIF, elsewhere in the MEF, or a commercial supplier and would take perhaps a month to transfer to the new installation.32 The primary consideration would be the technical capacity of the host, Internet connection, and, if commercial, cost.33 Specific arrangements between DC and INTIC on hosting and management would need to be clarified, for example, as it relates to INTIC staff time and the clear delineation of roles. 32 ODAmoz does not require a complex server. DG’s Technical Manual states that ODAmoz requires 2GB of RA M, 1 processor, and a 20 GB hard disk. This is less than the specifications of an average laptop and should cost less than USD 750; even if the specifications were doubled, it should only cost up to USD 1,500, including a small UPS and dual hard drives, power supply, and so on. 33 A local commercial company with a Service-Level Agreement, or a commercial host abroad, administered by the MEF. A commercial Platform As A Service (PAAS) would have the advantage of outsourcing all the server maintenance and security arrangements to the provider; the cost should be under USD 2,400 a year. 30 Aid Data Management Assessment - Mozambique 85. None of the options above, however, solve the issue of technical capacity to administer ODAmoz. Hiring technical help, such as fixing the incorrect sectors and ministries, and overseeing the server transfer, would be a simple solution. Indeed, there are more than sufficient local developers with the Ruby/Linux experience required, although some minor technical support may be needed to oversee and guide the programmers. 86. The cost of implementing minor modifications to ODAmoz—such as autosave of data entry, removing unused fields, and programming a budget export report with CoA codes—could be significant improvements for a low price. Local programmers would be far more affordable; however, as the code for ODAmoz is owned by DG, the GoM may not have the right to modify it and would require permission from DG to employ local developers. Alternatively, DG might insist on doing the work themselves, which would significantly increase the expense incurred. To avoid another round of changes that do not solve the issues, technical assistance would again be required to hire and guide the developers. The experience of the previous upgrade, as well as of similar situations elsewhere in the region, is that nonlocal developers are unable to provide the technical assistance needed. Table 5: Option 2 - Reinstate ODAmoz as the Sole Aid Data Collection System, with Improved Hosting, Some Technical Help, and/or Minor Changes Option Estimated Cost Developer Options Licensing Estimated Hosting Options DC Capacity (USD) Timeframe Requirement Improved hosting - 2,000 if a new server None required License for ODAmoz 1 month to reinstall Clearer understanding DC has insufficient INTIC is needed; VMware from DG. Also ODAmoz without of roles, for example, capacity for system and DG license too, if requires VMware using VMware, add whose responsibility administration required license, unless it is one week if need to paying for the (requires Postgre-SQL moved to its own procure dedicated VMware license was and Ruby); this needs server and stops using server. so that last year’s to be transferred to VMware.a problem is not the hosting repeated and license organization. Unclear cost budgeted for. whether INTIC has (and can retain) these skills. Improved hosting - 2,000 if a new server None required, save Commercial. Also 2 months to arrange, 1 CESDIF CEDSIF staff have CEDSIF is needed; VMware for CEDSIF’s staff requires VMware month to set up the skills to manage and DG license too, if time license, unless it is the server and app required moved to its own (Ubuntu, Postgres, server and stops using Rails), but not the VMware ability to edit PostgreSQL to add new modalities 31 Aid Data Management Assessment - Mozambique Option Estimated Cost Developer Options Licensing Estimated Hosting Options DC Capacity (USD) Timeframe Requirement Improved hosting - 5,000 for a server, None required, None required 3 months for transfer - MEF IT. On a As above, unclear if MEF IT (dependent UPS, and so on if assuming staff time (installation of about 3 days’ work dedicated server (note the MEF IT has the on having a server hosted in the MEF covered Windows license) and several days for that the requirements capacity to manage it room) training are only 2 GB of (as ODAmoz is a RAM) website, and they manage other websites, this seems possible) or the ability to edit PostgreSQL to add new modalities Improved hosting - 5,000 for a server, Reliance upon the None required 3 months for transfer - On a dedicated server Unclear if DC would MEF DC (dependent UPS, and so on if MEF IT or (installation of about 3 days’ work (note that the rely on the MEF IT on having a server hosted in the MEF contracting of local Windows license) and several days for requirements are only and if they have the room) developers training 2 GB of RAM) capacity or hire contractors. Improved hosting - 150–250 per month to None required, None required 3 months for transfer - Significant benefits of MEF/INTIC/CEDSIF Commercial (arranged hosting company assuming staff time (installation of about 3 days’ work simplification by would still need to locally) covered Windows license) and several days for using a Rails PAASb conduct the training administration, unless that was also outsourced. Some technical help - 1,000 for local Local developers with No additional costs as 1 month to agree to Not applicable - Requires capacity to additional to the developers, 5,000 Ruby/Linux not modifying the changes, implement, although could guide changes; above options to fix (and up) for experience code but changing and test probably assist with would need technical the broken reports, international options following the the new hosting knowledge to hire and incorrect sectors, developersc - technical manual guide developers ministries, and so on maximum of 5 days’ work Minor modifications - From 5,000 for local Local to international DG may not allow 6 months to specify, Not applicable - Requires capacity to low-hanging fruit: developers to 40,000 modifications to agree, implement, and although could guide the changes; autosave of data for OECD developers source code or may test changes probably assist with would need technical entry, removing (depending on who insist on doing (and the new hosting knowledge to hire and unused fields, owns the Source billing) the work guide developers programming budget Code) themselves export report with CoA codes 32 Aid Data Management Assessment - Mozambique Note: a. VMware is a ‘type 1 hypervisor’, a program installed on a hardware server that divides it into several small servers that share resources. INTIC is using one hardware server to run several platforms in addition to ODAmoz. If ODAmoz had its own server, then it could be installed directly and would not need a VMware license. b. The provider takes care of all the server and operating system maintenance and security, leaving the user to maintain the application. c. Rough estimates are USD 100 per day for local or non-OECD freelance developers, USD 250 per day for local or non-OECD company, USD 500 per day for OECD freelancers, USD 750–1,000 per day for DG or similar OECD company. 33 Aid Data Management Assessment - Mozambique Option 3: Redesign Mozambique’s AIMS, Preferably Housed within CEDSIF 87. To fully resolve the functional issues identified in this assessment, ODAmoz needs significant changes and/or a newly designed platform. This last option would likely take the longest—perhaps a year, excluding procurement—but it has the potential to be the most efficient, sustainable, and—in the long run—cheapest. Weighing the potential pros and cons, this report identifies a redesign of Mozambique’s AIMS as the Recommended Option. Alternately, ODAmoz could be revised to adopt the major modifications outlined above (for example, those requiring changes to the data structure), as well as a comprehensive approach to smaller changes. This would take a minimum of six months and DG would still presumably own the source code, so permission would need to be sought (and paid for). 88. The final two choices, both variants of Option 3, involve procuring—or developing—a new AIMS; most importantly, this new platform should be housed within CEDSIF. This would directly address the current disconnect between aid data supply and demand: as is, the processes responsible for capturing aid data are separate from those responsible for using aid data in the national planning and budgeting process. Ensuring that an AIMS is housed within CEDSIF, the same institution managing e-SISTAFE, would facilitate the process of better integrating aid data management into budget data management. One option could even be the development of an aid data module within e- SISTAFE. 89. The first possibility would be to procure a commercially pre-made AIMS. The choices are AIMS from DG, Synergy, or Catalpa, the three major industry providers. All three have high up-front costs, monthly/annual fees, and international support requiring missions to meet face to face (totaling USD 250,000–500,000). All three would own rights to the code, although Catalpa does make some core code available under an open source license. It would be expected to take from six months to a year for negotiation and installation, the arrangement of which differs between providers DG (GoM hosted) and Synergy and Catalpa (they host). These pre-made AIMS are complex and arguably better suited to higher capacity contexts. Importantly, none are sufficiently modifiable to meet Mozambique’s specific needs and would require crosswalks for the aid data to be compatible with budget data. 90. The second possibility would be to procure a customized, commercial AIMS, designed and built by a commercial company to Mozambique’s needs. It might cost USD 100,000–400,000 and take approximately a year to produce, depending on the company and the system complexity. Djibouti and Bangladesh recently procured AIMS in this way, both with fairly high degrees of success.34 The GoM would own the code and the rights to modify it (including with local developers) and could choose to host it either in-house or with a service provider. It could be built to fit the GoM hosting capacity and, most importantly, could be specifically designed to integrate seamlessly with e-SISTAFE. 34 Myanmar did as well, with an open-source AIMS. The benefit of open-source software, in which the license specifies that anybody can use it without restriction, is that all the contributors benefit from the improvements made by the other users. The project could incorporate several already existing open-source components, such as Bangladesh’s IATI-import module, and if one firm made a geomapping module, it would instantly be made available to all, ready to be customized for each country’s AIMS. 34 Aid Data Management Assessment - Mozambique The capacity to design and specify an AIMS would require significant technical assistance support, including hiring and managing the developers and provide feedback during the process. 91. Either possibility would require a rapid data assessment and wireframe to map out the exact steps needed to take in development of a new AIMS directly linked to e-SISTAFE. Such a study, feasible in one or two months, would determine the exact needs of the client in terms of final data fields, user ability, auto-generated reports, and interface, for inclusion in the vendor ToR. It would also set forth the processes needed to collect aid data from DPs, push that data into e-SISTAFE, and pull all donor project data from e-SISTAFE as well; this last step would allow for public access to data on all aid flows in one place, be it on- or off-budget and -CUT. This study will also inform whether a commercial off-the-shelf or customized system is preferable. Table 6: Option 3 - Redesign Mozambique’s AIMS, Preferably Housed within CEDSIF Option Estimated Cost Developer Options Licensing Estimated Hosting Options DC Capacity (USD) Timeframe Requirement Big modifications - From 50,000 for local Local to international Unclear who owns 6 months n.a. Requires capacity to Multiple donors per freelancers (plus the source code. If it guide the changes; this project, multiple some technical is DG, they may not would require technical funding sources per assistance for allow modifications assistance (also to project, guidance) to 200,000 (or insist on manage the comprehensive for DG undertaking the developers). reporting, working work) budget integration, and so on. Commercial off-the- 300,000–500,000 for DG, Synergy, Catalpa The companies own 9 months to 1 year DG (GoM hosted), Negotiation and site shelf AIMS - Pre- DG and Synergy. (none of which allow all the rights to the for negotiation and Synergy and Catalpa administration, as these made AIMS based on Catalpa is free for the for modifications to code (although installation; longer if (they host) sites are complex UNDP long-term basic version but meet specific needs) Catalpa does make adjustments are agreement 250,000 for the some core code needed professional version. available but needs All require investigating on the monthly/annual fees license) and support. Commercial Custom 100,000–400,000, OECD international, None - The GoM 1 year GoM hosting, either Capacity to design and AIMS - An AIMS depending on the non-OECD would own all the in-house (preferably specify AIMS - designed and built by company and international, local, code and the rights. CEDSIF) or with a Requires significant a company to complexity of the combinations, open- commercial service aid management Mozambique’s needs system source provider technical assistance 35 Aid Data Management Assessment - Mozambique 4. Next Steps 92. With ODAmoz back online as of mid-2016, the GoM has demonstrated its commitment to effective aid data coordination and streamlining data collection across the GoM MDAs and DPs. Yet, despite these efforts, ODAmoz will continue to be challenged by significant shortcomings in its structure, capabilities, and usability. The assessment team and all consulted stakeholders strongly recommend that this report, and its recommendations, be reviewed and discussed as part of the ongoing GoM-DP collaboration. Once the GoM has decided on a preferred option to manage ODAmoz systems, all stakeholders should commit to supporting and contributing to the GoM’s approach for strengthening aid data coordination. 93. Regardless of the decision on how to proceed on the technical options for ODAmoz, a number of core constraints should be addressed within DC. These issues are concentrated in three priority areas:  Strengthening ODAmoz staffing - All of the proposed solutions for improving ODAmoz result in a significant workload for DC. DC should support this process by allocating sufficient staff for directing and managing the platform and clearly specifying the roles and mandates of part-time staff engaged in coordination activities.  Improving communication - ODAmoz remains challenged by the lack of awareness of its functions and mandate. DC can build on existing DP coordination mechanisms and collaborate with line ministry staff to ensure that all DPs submit accurate data through the current system.  Reinforcing ODAmoz’s data collection mandate - Following the brief shutdown of ODAmoz, DC should restart engagement with DPs by updating and circulating the annual ODAmoz data collection and report production calendars, as well as a flow chart outlining data entry responsibilities and actors. These documents should also be available from the online ODAmoz portal itself. 94. Regardless of the option chosen, DC should ensure that any new platform be housed within CEDSIF and integrated to the greatest extent possible into e-SISTAFE. International experience has shown that for an investment in aid data management to be worthwhile, the resulting data needs to be utilized; the primary clients for such data are the institutions responsible for the national planning and budgeting process. The main lesson learned from this assessment is that to be useful to government and worth the investment in limited resources, aid data must use national budget classification categories and must be readily integrated into the national planning and budgeting process. 95. Given the pros and cons of the three existing options, as well as their various iterations, the assessment team recommends the following next steps to be taken with the MEF:  Convene the relevant stakeholders—MEF, World Bank, and UNDP, but also CEDSIF, INTIC, MINEC, Belgian Technical Cooperation (BTC), and others—to discuss the costs and benefits of the three possible solutions. 36 Aid Data Management Assessment - Mozambique  The MEF, in conjunction with other relevant government actors, determines which solution best suits the needs of the GoM.  The World Bank, MEF, and UNDP strategize the way forward and draft terms of reference for work, ensuring that all interventions complement existing and pipeline World Bank activities around budget and debt reform, as well as enhance the public investment management system. 37