Sprint 2

STATUS: CONFIRMED

• Overview
  • Data integrity
  • DP data overview
• 1. Build a basic interface
• 2. Filter and group projects
  • a. Establish hierarchy
  • b. Filter out projects likely not relevant to Bangladesh
  • c. Determine whether projects should be reported by this DP or another
• 3. Match projects between IATI and AIMS
• 4. Display matched and unmatched projects

Overview

The main goals of sprint 2 are:

1. build a basic interface that can read data from the API defined in sprint 1
2. ask the user a series of questions to try to filter and group projects into a) those that this user is responsible for reporting and b) those that other users are responsible for reporting
3. match projects in IATI data to those in the AIMS; and obtain a list of IATI and AIMS projects that do not match;
4. display related IATI and AIMS projects side by side.

Data integrity

• data in the live AIMS should not be touched
• data in the test AIMS can be changed and adjusted as necessary for the purposes of testing
• data in the IATI import tool can be deleted and re-generated at will throughout the development process, until we agree otherwise, perhaps in some of the last few sprints.

DP data overview

For the purposes of this sprint, we will use data from Canada and DFID.

^* this is currently the only- or most-used identifier. There may eventually be more than one identifier in use; see below.

The data from both DPs is good. See also some more detailed data analysis for Canada and DFID.

1. Build a basic interface

It is up to the software supplier to design / suggest a basic interface. Mock-ups will be provided at http://test.brough.io/bd/ – but these will be some ideas and suggestions; the software supplier does not have to follow them rigidly and is encouraged to suggest alternatives.

The interface needs to be flexible enough to allow data for a particular donor to be filtered and mapped to the AIMS data, including (eventually):

• mapping individual projects in IATI to projects in the AIMS
• providing some granularity on field-level mapping between IATI and AIMS projects
• allowing for different types of projects to be handled in different ways
• providing user login and authentication
• being fast and responsive in low-bandwidth environments

This user interface can be gradually be built up and improved upon over the course of the sprints. It can potentially be quite plain at the outset (e.g. undesigned wireframes), if there is a need to concentrate on the other components of the sprint. However, it should eventually look clean and slick on most modern browsers (IE 7+ unless particular desired libraries have compatibility issues – we can adjust this requirement by mutual agreement).

2. Filter and group projects

a. Establish hierarchy

Some DPs will use a hierarchy of projects in their data. We need to ask the DP which hierarchy they would like to map to the AIMS. We should provide them with our recommendation, generated by establishing the % of activities at each hierarchy that have a match to the AIMS. The highest match wins.

We should also show some sample data to the user (iati-identifiers and titles for one parent activity and all of its chidren, to a maxmimum of 5 activities at each level), so that they can understand the decision they are making. This can look something like this example.

b. Filter out projects likely not relevant to Bangladesh

Show all activities on a page. Deselect those where:

• recipient-country percentage for Bangladesh is less than 20%
• aid type is B01 (core support to NGOs) or B02 (core contributions to multilaterals)
• activity-status is not 2 (i.e. closed projects)

We will want to revisit these filters later, so they should be implemented in a flexible way.

The user should be able to move projects from one section to another (i.e. to manually select to include or exclude particular projects)

c. Determine whether projects should be reported by this DP or another

IATI data may include multiple activities for the same project, as each organisation involved can publish the part they are responsible for. For example, DFID may publish its contribution to a World Bank project as one activity, and the World Bank may publish its implementation of that project as another activity.

Generally, where one DP A is giving funds to another DP B registered elsewhere in the AIMS, DP B should be responsible for the activity, and DP A should be listed a providing contributions to that activity.

We therefore need to try and determine if a DP’s activities are likely relating to their own activities (“mine”) or another DPs (“not mine”). See also a brief discussion of project types in the documentation.

In a similar way to the previous step (b), we want to filter out projects, but in a flexible way so that the DP can choose to adjust the results if they do not agree.

Projects are determined as “not mine” if:

• the implementing organisation is of organisation type 40 (“multilateral”);
• the implementing organisation has a ref 11000 (“donor governments”) or 13000 (“third-country governments, delegated cooperation”)
• the implementing organisation has a ref that matches a “fund source” from the AIMS – NB there is a field to state the IATI identifier of the organisation, but will not always be filled out

The user should be presented with a list of unique implementing organisations, and asked to determine if any of those are known to exist elsewhere in the AIMS. For example, the implementing organisation could be listed as simply “WB” which the user can easily identify as “World Bank”.

There should be a list of projects in each section and it should be possible to manually move projects from one section to another.

3. Match projects between IATI and AIMS

Initially, to match projects between IATI and the AIMS, we will rely on the project ID or IATI Identifier being filled out in the AIMS.

We can check this two ways:

• IATI’s iati-identifier matches the “IATI Identifier” field in the AIMS
• IATI’s iati-identifier, excluding the organisation identifier (found in reporting-org), matches the “IATI Identifier” or “Project ID” field in the AIMS

An overview of the project IDs in the AIMS suggests this data is fairly good, so this should work well. We can revisit alternate options for trying to match projects if this does not work sufficiently well.

4. Display matched and unmatched projects

This page should have four sections:

1. Projects that matched between IATI and the AIMS
2. IATI projects that were not found in the AIMS
3. AIMS projects not found in IATI
4. Projects defined as “not mine”

In the first two sections, only projects defined as “mine” should be shown.