Our main finding is that importing IATI data is achievable, but it requires some careful (human) interpretation of data in the first instance. Once that has been satisfied, data (especially financial data) can automatically flow in, reducing the burden of data collection and the need for human intervention going forward. Designing a generic solution (not donor-specific) is possible and can be achieved without overly complicating the user interface – the module has been tested with 15 donors. There are some clear limitations in data quality from certain donors; for these donors, more interpretation in the module or manual data entry in the AIMS will continue to be required until their data improves. In some cases, the data quality issues are so significant that they prevent those donors’ data from being imported at all. The work also highlighted some limitations in the way the IATI Standard captures data.

2.1 Large-scale IATI import is possible and improves quantity and quality, but has to be handled carefully and requires human intervention

As we developed the module we gradually added complexity over time, testing with more and more donors. By the end of the development process, the module was able to work with data from at least fifteen donors: Asian Development Bank, Belgium, DFID, Canada, EIB, EU, GAVI Alliance, Global Fund, Netherlands, Sweden, Switzerland, UN Habitat, UNDP, World Bank, WFP. The list included some large donors not yet captured in the AIMS. In section 2.4 we discuss our difficulties importing data from different donors.

With a small amount of human input, we were able to import almost all IATI fields into the AIMS, including sub-national locations and project documents. Results and conditions don’t have a location in the AIMS at the moment. We did not have to make any bespoke per-donor tweaks in the source code. If something could not readily be handled automatically because of limitations in that donor’s data, the donor would need to help interpret it or it would not be imported (and could be manually entered into the AIMS later).

2.2.1 Improvements in data quality captured in AIMS

In line with past work, data availability comparisons with different donors suggested IATI import would lead to significant improvements in the quantity and quality of data captured in the AIMS.

The module follows the agreement between donors and the GoB that reporting to an AIMS is a donor responsibility. The module was tested with current IATI data from fifteen donors and received feedback from several, however time constraints, made it impossible to run through the full process of IATI data import with all donors in person. The data quality findings here are therefore assumptions about how donors would use the IATI import module. As previously stated, donors’ input is vital for interpreting the data accurately. Donors are best placed to know which projects (and sub-components, in some cases) should be imported into the AIMS and which should be excluded, given in-country agreements about the types of data that are reportable to AIMS. Data quality metrics have been established for the AIMS and it will be possible to monitor improvements over time.

2.2.2 Greater granularity and more detail

With that caveat in mind, we can highlight a few of the data quality improvements that were identified during the development process. For example, one DFID project saw a remarkable improvements in the granularity of data captured (see Table 2, below).

Table 2. Improvements in detail for DFID project “Promoting Financial Services for Poverty Reduction in Bangladesh”

Field AIMS (before IATI) AIMS (after IATI)
Disbursements (number) 8 177
Locations 0 17
Project documents 0 7

Greater disaggregation of financial data will be particularly valuable for two reasons. Firstly, it allows the data to be disaggregated. Previously, one disbursement covered the period 2007-2014. This is in line with recommendations from the Government in order to keep the burden on donors manageable. However, it was therefore not possible to identify how much was spent in each year, or each quarter. There are understandable reasons for this: entering quarterly disbursements for this period (7 years) would require 28 entries to be calculated from the donor’s own system and typed into the AIMS, a significant burden when applied to all a donor’s projects. Importing the data from IATI, however, can occur automatically once the project has been mapped, and new disbursements can flow in automatically.

Secondly, where financial data covers a precise date rather than a range of dates, more accurate currency conversion is possible. In the case of the single DFID disbursement covering 7 years cited above, currency conversion (from GBP to USD) is inaccurate – in the course of 7 years, the GBP:USD exchange rate between these two currencies fluctuated significantly (from virtually 1:2 to 1:1.47 at the time of writing). Accurate currency conversion is vital if the data is to be useful in other Government of Bangladesh processes.

2.2.3 Greater volume in financial data

We did note some improvements in the value of funding captured when using IATI data as opposed to manually entered data. New projects not yet captured could easily be imported, and more up to date financial data also increased the volumes recorded in the AIMS.

However, again, it is important to stress that the module allows donors to make their own decisions about whether they would like to use the financial data in IATI or continue manually entering data into the AIMS. Donors can compare the amounts in their IATI data with the values currently captured in the AIMS and decide which data is a more accurate reflection of their spending in country. Donors are best placed to do this as they have access to the best data about their spending.

2.2.4 Using the best data from multiple sources

Projects which involve several IATI publishers will have data available from several IATI datasets as well as the data manually typed into the AIMS. Once the process of mapping an IATI activity to an AIMS project has taken place, the managing donor often has several sources of data available, allowing them to chose the most useful one. For example, the financial data from a funding donor might be the most up-to-date, whereas the project location might only be available from the implementing donor, and the local AIMS data will probably have the only translation into Bengali.

2.2.5 There will be differences in the data captured in different systems

There are some clear reasons why amounts may be different between IATI data and the AIMS – they are likely to be at least slightly different. This should not come as a surprise, given that a main goal of using IATI data is improving the quantity and quality of data collected. If the data were already perfect, there would be less of a reason for trying to use IATI data. These discrepancies could be a result of some of the following factors:

  • More timely data in IATI: the most recent financial data is available in IATI but has not yet been manually entered into the AIMS.
  • Exclusion of certain components not reportable to AIMS: some projects are not reportable to the AIMS in Bangladesh if they have not completed the government approvals process. Components of projects should also be excluded if they include spending before the government approvals process completed (for example, procurement or other preparatory work) or if they are for donor project management.
  • Human error: when entering large amounts of data manually into any system, human error is inevitable. For example, accidentally adding an extra digit would increase the value of a project by at least a factor of ten.
  • Currency conversion: using exchange rates from different sources could make small differences to the amounts when converted to a different currency. Using a different date will make a larger difference if there have been significant fluctuations in exchange rates.
  • Projects deliberately excluded from IATI: donors may choose to exclude certain types of projects from publication. This could be due to principled exclusions, e.g. for security or safety reasons. It could also be due to other policy reasons, which may be less clearly defined (or somewhat arbitrary) and harder to anticipate. For example, Germany excludes from publication all projects which were closed as of January 2014. The World Bank excludes many “trust fund” projects where they do not receive any funding from the World Bank (this may change in the near future).
  • Fields deliberately excluded from IATI: donors may not yet have begun to publish certain fields to IATI, though that information has been provided to the AIMS locally. For example, the Netherlands does not publish projected disbursements in its IATI data, though this information has been provided to the AIMS.
  • Data accidentally excluded from IATI: there may be cases where information does not get published (or is published incorrectly) due to bugs in data generation processes.

These issues are not a reason to use or not to use IATI data in preference to data manually entered into the AIMS. They merely serve to illustrate the range of reasons why numbers may differ and the need to allow users – principally, in-country donor staff – to decide which value is most accurate. In some cases, donors will need to consult with staff in headquarters who are responsible for generating the data. The fall-back to any issue is that donors can continue to use the AIMS as at present – continuing to enter data manually. However, they can also choose to import particular fields or projects from IATI.

2.2.6 Merging projects and avoiding double-counting

All systems – regardless of whether the data is captured from IATI or manually entered into AIMS – have to handle double-counting and duplication where the same project (or overlapping components of the same project) are reported multiple times from different perspectives. The IATI Standard does have some mechanisms to handle this (e.g. traceability at the transaction level, related activities), but usage amongst donors is far from sufficient, and even if the data were published perfectly according to the Standard, some human intervention would probably still be required. However, with that human intervention (and an appropriate interface), using IATI data without introducing double counting is possible.

2.2 Design considerations

2.2.1 Necessity of human intervention

We viewed manual intervention in IATI import as a necessity for several reasons. Firstly, limitations in terms of either the data or the IATI Standard mean that additional information needs to be captured at the data import stage. Some pieces of information required at the country level (but not present in IATI data or the Standard) need to be captured. Other information needs to be interpreted or explained by humans – particularly how activities published by different organisations relate to each other.

Secondly, and particularly as the use of IATI data in country systems is still in its infancy, there are good arguments for retaining human intervention to check or validate the data. Even if the data and standard were perfect, it is important to proceed carefully to verify the data and ensure that it has been correctly interpreted. These broader processes will also be strengthened if donors take responsibility for the data they are importing, which they can only do if they have sight of the data. Otherwise, there is the danger that country offices do not recognise the data published by headquarters and refuse accountability for the information that has been entered about their activities. This may also be an issue where IATI data lacks a notice that it can be considered a publisher’s official data.

While the first set of issues can be addressed through improving the quality of data published in IATI – by improving the way donors publish and some improvements to the Standard – the second set of issues will likely remain for some time until both donors and government have confidence in the quality of data that is being published. We do not see “one-click import” as either realistic or desirable in the short or medium term.

Throughout the module, where possible, we tried to guess the correct response to reduce the labour intensiveness of the work, but requested users to correct these responses where they were inaccurate. This happens at each of the stages. For example, where an organisation is using multiple levels of activities (e.g. projects and sub-components, often referred to as a “hierarchy” in IATI), we try to guess the correct level by seeing which level has a greater match with projects already in the AIMS. We allow the user to adjust this if they disagree.

The area that probably required the greatest human intervention was around implementing organisations. Given the limited and inconsistent use of organisation identifiers in IATI, it is necessary for users to interpret each implementing organisation reported in the IATI data and determine how they relate to organisations already stored in the AIMS. Where the names of implementing organisations are individually identified in IATI data (the Asian Development Bank is a good example), we were able to fairly reliably compare and match them with the names of implementing organisations in the AIMS. Where the implementer was recorded as ‘International NGO’ this required input from a user with detailed knowledge of the project to make the data useful.

2.2.2 Keep the complexity away from users, where possible

Our intention was to keep complexity of IATI data away from users where possible, while asking them to take decisions where we required human intervention to interpret the data.

All of the data retrieval happens automatically behind the scenes. We retrieve data nightly from the IATI Datastore, and tie specific reporting organisations to funding organisations already captured in the AIMS. We convert to a standard version of the IATI Standard (v2.2). At no point does the user have to touch or see XML.

Mechanisms were required to match projects reported in IATI data with those reported to the AIMS. We initially developed an interface to allow projects to be manually grouped and matched from IATI to the AIMS, using a “drag and drop” interface. However, in Bangladesh the project ID field in the AIMS was fairly consistently populated with the same (or similar enough) ID codes used in donors’ IATI data. and so we were able to take a shortcut and compare IATI identifiers with AIMS project codes. We therefore didn’t have to develop a more complicated methodology of trying to match projects by using other information (for example, trying to compare titles in each system, or with matching algorithm based on a combination of sector, dates, keywords, involved organisations etc). This allowed us to significantly simplify the process.

2.2.3 Donors work differently; their data is also different

We had to progress donor by donor due to the variety and complexity of different donors’ IATI data, and the need to understand how different donors were using the IATI standard, and the AIMS. Data cannot be imported automatically in bulk form. Rather, a more careful and somewhat manual process is required – requesting people who know the data well to interpret it and explain how it relates to other information. This is particularly the case where projects are reported by more than one organisation. We reasoned that the people most likely to understand individual donors’ data are those donors themselves; this fit well with existing data collection processes in Bangladesh, where donors are themselves responsible for entering information to the AIMS.

Working through donors individually had an additional advantage of allowing us to take a closer look at the quality of individual donors’ data. We discuss issues arising from this work in section 2.4 below.

2.3 Practical considerations

2.3.1 Relationship with developers

We were able to complete this work in a short timeframe for a three of reasons. Firstly, a local IT company, Technovista, was fast, flexible and responsive to requests and had two programmers working full time for the development period. A close, collegiate and open working relationship was conducive. Technical assistance with a detailed understanding of both IATI data and aid management helped steer the development process and allowed experimentation with different approaches until we reached a solution that worked in the generality of cases.

Secondly, the source code for the AIMS is owned by the government and was originally developed by Technovista, meaning that there were no issues in terms of gaining access to the code, or having the rights to modify it, and that we could get moving quickly. One of the programmers had worked on the original AIMS, which also meant that much of the terminology was familiar. However, as long as there is sufficient guidance from team members with IATI and aid management experience, there is no requirement for AIMS programmers to have this knowledge. This significantly increases the choice of developers available for similar work.

Thirdly, the contract with UNDP allowed many trips at short notice to Dhaka when needed and convenient for ERD and Technovista. Four missions rather than the originally planned two were needed to get sufficient contact time. Software development (especially given that it was experimental) required significant face-to-face time between ERD, the developer and the technical assistance. It is not something that can be done remotely, or with only a few visits. Otherwise, some of the many small details upon which the quality of the system depends can be missed, because they are difficult to communicate. The danger is then in creating a technically good system that is not a good fit for the context. Working remotely with Technovista generally worked well – however, face to face time was invaluable and the additional missions we undertook were important for refining the end product.

The software development was not as technically complicated as originally expected. Technovista suggested the project was “low complexity” in comparison to the projects they usually undertake. The most challenging part was the methodology – working out how to interpret the IATI data, including handling different ways donors could structure their data and common ambiguities or limitations in the quality of the data. Interfaces that made sense in terms of that data as well as aid systems and business processes then had to be designed and tested.

2.3.2 Need to develop context-sensitive processes

A few features of the context in Bangladesh were important to consider. As with many AIMS, donors are responsible for entering their own information into AIMS. This was not only an agreement in principle – in practice, donors generally were entering their data into the system themselves. This feature was key to replicate in the design of the IATI import module: the main users should be donor staff in country offices.

Secondly, projects cannot be reported to the AIMS until they have gone through the government approvals process. There is no field in IATI data for identifying projects (or their sub-components) that have been approved. It was therefore necessary for the interface to allow projects and sub-components to be deselected according to the knowledge of the user (donor staff in the country office) about whether a particular project has yet been approved.

Thirdly, capacity considerations were important to consider but also a somewhat moving target, which posed a challenge. At the outset of the work, there was quite significant technical capacity within ERD. Indeed, ERD could probably have supervised software development themselves. However, as the Aid Effectiveness Project drew towards a close (end June 2016), several of the more technical staff left. The technical assistance had to take a much closer part in the management of the development process than originally anticipated.

Capacity constraints could pose problems for ongoing maintenance and development of the module. Moving donors from manual reporting to automatically importing data from IATI should rapidly lead to a significant reduction in burden and increase in data quality. However, that will require some technical support in helping donors use the module, handling more difficult data and dealing with unforeseen ways in which donors can publish. The module has been designed to be as user friendly as possible and the manual should help answer most questions. However, there will inevitably be questions and issues where technical support will be required.

2.3.3 Don’t view the AIMS in isolation

A final consideration is that the AIMS needs to be seen in the context of other Government of Bangladesh systems and should not be seen apart from them. The AIMS requires inputs from some of these systems, for example retrieving exchange rates from Bangladesh’s central bank. The Bank of Bangladesh kindly provided an API with monthly averages for exchange rates from 20 currencies and agreed in the future to also provide daily rates. These rates are now retrieved automatically, whereas before they had to be manually keyed in each month.

The AIMS also provides inputs to other ERD systems, particularly the Foreign Aid, Budget and Accounts (FABA) wing of ERD. FABA needs data on aid projects for internal ERD budgeting processes, including debt management. It also collects data for the budget office of the Ministry of Finance. If good quality data could flow through to FABA from AIMS, it would not only reduce duplication of effort on the part of both ERD and donors from parallel data collection processes. It would also strengthen the individual systems – FABA would gain a good and reliable source of data at low ongoing cost.

Finally, AIMS also needs to be seen in the context of the various ERD wings overseeing relations with different donors. We had the opportunity for discussions with only a few wings, but it is clear that they could benefit from better quality data and from not having to chase donors to obtain the data they need (particularly for the purposes of monitoring project execution).

2.4 Limitations in IATI data from particular donors

The solution we designed does not set a minimum data quality threshold for importing data to the AIMS. It is up to donors to decide whether they think their data is an accurate reflection of their aid activities. However, there was a clear mix in the quality of data. In some cases, the data quality issues were so significant that it was not possible to use the data. In other cases, particular fields were hard to use. We include some of the more important limitations here.

2.4.1 Activities that don’t look like projects

In some cases, it is hard or impossible to map the activities published by several donors to actual projects captured in the AIMS. UNICEF (and possibly UNFPA) publish “results” rather than projects, as part of internal efforts to “manage by results”. However, a side effect has been to obfuscate projects from their internal systems and IATI data. As a result, it is impossible to map UNICEF and UNFPA activities to the projects they currently report to the AIMS. It appears that this is due to systems limitations, which also appear to have some negative implications for the way that these organisations’ country offices are able to manage their programs. These systems limitations should be urgently reviewed.

In other cases, it is very difficult (maybe not impossible – just time-consuming) to map activities in IATI to projects in the AIMS. USAID publishes very granular activities that roughly correspond to a “contract”. Each project may (and normally does) have multiple contracts (“awards” in USAID terminology). These contracts would ideally be combined into single activities to represent one project. Secondly, it appears that a very large number of (often quite small) administrative spending lines are being published. Filtering these out helps to reduce the “noise” in the activity data, but this meant that we had to add a new feature to the interface to make possible this sort of manual filtering. Thirdly, the US uses a hierarchy that has a “sector” as the top-level activity. This is unlike any other IATI publisher: a sector is not a real unit of aid, and in IATI data should instead be published as a classification of an activity.

2.4.2 Generic, broad, or insufficiently specific organisations

A significant issue we encountered was the number of publishers that did not identify a specific organisation as the implementing organisation of a project. There were several cases where DAC Channel Codes were used instead of specific organisations. This led to many instances of organisations such as “INTERNATIONAL NGO”, “RECIPIENT GOVERNMENT”, or “OTHER” (as in DFID’s data), or “NATIONAL EXECUTION” (as in UNDP’s data). In at least one case (Australia’s DFAT) there were no implementing organisations listed.

Where specific organisations were listed (e.g. “Economic Relations Division, Ministry of Finance”), we could generally guess which organisation this was referring to and map to the organisations already listed in the AIMS (the Asian Development Bank’s data was particularly good on this front). However, where only generic or broad categories were stated (as in the examples above), donors will have to manually enter this data in the AIMS.

2.4.3 Other data quality issues

There were other issues that were much more limited to specific donors. In the case of Germany, the data shows cumulative disbursements to date, rather than providing specific disbursements or at least the total amount in each month. This financial data cannot be used, as the full amount of the disbursements for all projects is stated to be the day on which the most recent publication took place. In the case of the World Bank, a large number of projects are missing, as the World Bank does not currently publish projects for which it is just the implementer and where the projects do not receive any funding from the World Bank’s own resources. Most trust fund projects therefore do not appear. This posed some challenges in trying to map other donors’ contributions to trust funds to projects managed by the Bank. The World Bank also aggregates financial data by quarter which means it is not possible to slice the data by month, and would also make it difficult to use the data in countries with a fiscal year that doesn’t map to the same quarters of the Gregorian calendar (Afghanistan, Iran and Nepal are three examples of such countries).

2.4.4 Donors with no usable data

Some donors don’t have any data that can be used. Either they have not begun to publish to IATI at all, or they are republishing CRS data annually. This data is far too infrequently published and is not timely enough to be useful for aid management at country level. These donors will need to continue manually entering their data into the AIMS, while other donors will be able to automate much of the work. However, hopefully in time, the module will provide positive incentives to these donors to begin publishing good quality data to IATI. In the meantime, the better quality data captured in the AIMS as a whole may also provide some motivation to provide better data manually. The benefits of the IATI import module are therefore not restricted to those donors already publishing good quality data.

2.5 Limitations in the IATI Standard

2.5.1 Lack of organisation identifiers, particularly for public bodies

The sometimes poor quality descriptions of some implementing organisations is a major constraint to using this data as part of AIMS. The starting point should be to improve these descriptions. However, even if the text of these fields were improved, there would still be a need for human intervention as the text of these fields is often insufficiently precise. Overcoming this problem would require donors to consistently use the same identifiers to refer to the same organisations. This issue is partially resolved for NGOs and the private sector, as codes issued by national registration bodies can normally be used as authoritative identifiers (though online, public databases of these identifiers may not always be available). However, for public bodies – particularly in recipient countries – there are generally no such identifiers available. Developing a consistent methodology for referring to these bodies will be vital if this part of the process, mapping to implementing organisations, is ever to be fully automated.

2.5.2 Avoiding Double Counting

Projects where more than one organisation is involved are hard to import in a way that avoids double-counting. There are some mechanisms in the IATI Standard for resolving this: traceability of financial data allows you to see how financial data flows through the chain, for example. However, it is hard to identify activities which involve co-financing or contributions to trust funds, or which are contributions to groups of projects that are managed by other organisations.

The IATI Standard does provide the ability to refer to the activity identifier of another organisation’s share of a co-financed project; however, the IATI Standard website could provide clearer guidance on how to effectively implement this. Trust fund projects are not well identified in IATI and there is also insufficient guidance on how trust fund or pooled funding type arrangements should be structured. It would be useful to have consensus and guidance on how to identify each of the following types of activities:

  • Contributions to pooled / trust funds (which may fund many projects)
  • The pooled / trust fund itself
  • Projects that are funded out of that pooled / trust fund.

Similarly, there was not sufficient use of the ‘related activities’ element which could be used to identify co-financing. In fact, none of the organisations we worked with used the “co-financing” related activity type. Solving double-counting for official donors will be vital if this work is to be effective.

As explained in section 2.6.2 below, we only worked with data from ‘official donors’, typically bilateral and multilateral aid agencies. However much IATI data is published by implementing organisations, NGOs and foundations. If the interface were expanded to include these organisations who typically work further down the chain on most projects, the need to solve issues of double counting would be paramount.

2.5.3 Exchange rates and interest rates

We were fortunate to have access to an API from the Bank of Bangladesh which allowed us to perform fairly accurate currency conversion. However, in the case of loans, exchange rates become much more important as debt servicing and repayment often must be according to a specific exchange rate agreed in advance between the government and donors. In IATI, there is no way to state a specific exchange rate alongside disbursements. Interest rates are also vital for understanding the nature of loans and for debt management. There is no mechanism for sharing this data in IATI, even if donors were willing to do so.

2.5.4 Verifying data and ability to contact the publisher

Data entered manually into the AIMS is formally verified by local donor staff as the donor’s official data, which the government can then publish and donors can be expected to stand behind. This is not the case with IATI data unless there is manual intervention of the form advocated in this work. IATI data generally does not provide specific contact details, is of unclear provenance from the perspective of recipient countries and is therefore not considered official data that can donors can be help accountable for. This is particularly problematic when the contact given for many activities is a generic email and is therefore not sufficient to verify the validity of data. It is also problematic when local donor staff are not aware of the source of IATI data and how it may relate to the data in their internal project management systems at country level.

2.6 Limitations of this work

Aside from the challenges listed above, additional limitations were necessary to restrict the scope of the work and ensure that our goals were realistic and achievable. Other features of the environment in which we were working may also limit the transferability of our findings and the relevance of this work in other contexts.

2.6.1 Language

English is quite widely prevalent in the Bangladesh government and the AIMS itself is in the English language. Outside the government, the lack of Bengali project titles and descriptions will clearly become a problem for increasing access. In countries where use of English is less widespread, there may be more issues in using the data, though we did not explore these. The module was developed to take English versions of data published in multiple languages (e.g. Canada publishes titles in English and French) so it could probably be adapted to select a different language. There were a few cases where information was published in a language other than English; in these cases, donors can choose to exclude that information for now and continue manually entering it into the AIMS.

2.6.2 NGO data and traceability

It was decided early on to focus on official donors for several reasons. Firstly, the issues of double counting are difficult enough to resolve when working only with official donors let alone trying to include many other levels of implementing partners. Secondly, the AIMS is not set up to handle multiple levels of reporting (i.e. reporting the same project multiple times from different perspectives); indeed, doing so while avoiding double-counting is a particularly complex problem to overcome. Thirdly, from a practical perspective, working with data from a smaller number of organisations limited the scope of the work and simplified testing and development.

Nevertheless, some of the techniques that we have developed for merging and delegating projects from different organisations could potentially be applied to incorporate NGO data. It may also be the case that the software could be applied to NGO data with some limited adjustments, though we did not investigate this possibility.

2.6.3 Interface and generalisability of the software

There were several iterations of development and we are pleased with what has been developed in such a short time, the interface is still somewhat complex. This is partly because it is trying to do some quite complex things, particularly in merging projects from different organisations. It was also probably somewhat inevitable given the experimental nature of the work and the need to get something working. However, it would certainly benefit from a further round of development to simplify complex steps and reconsider user experience and design, particularly following user feedback.

The module itself could potentially have been more generalised to deal with different sorts of systems and to have a looser relationship with the AIMS with which it interfaces. Indeed, this was the intention at the outset. There were a couple of reasons why it was consciously decided to compromise on this point. The main issue was limited time, meaning that it was necessary to develop very rapidly without the time to spend on adding further layers of abstraction into the data model. Getting a first working version in Bangladesh would be useful both broadly in other contexts and narrowly in Bangladesh. Broadly, the methodological developments could be directly applied in other contexts and the software could (without too much effort) be adjusted to work with a different AIMS. Indeed, it is likely that some adjustments would be required regardless of the nature of the module developed. A good working version in Bangladesh should also provide an important demonstration effect that this is possible and provide motivation for further work in this area. Having a good working version in Bangladesh will also support and strengthen the AIMS in that particular context and in time should support development more generally.