Future infrastructure to support the IATI Standard

This sounds like ODA macro-management. I accept that this may be the most prevalent use of AIMS at present, but is this really the IATI vision? Is this really what in-country decision-makers need? I would go so far as to argue that ODA macro-management (for which double counting is an issue) is an edge case. Is IATI a bean-counting balance sheet, or part of what the data revolution promotes as data-driven decision-making?

I agree that we can provide more focused (even standardised) outputs from IATI data, but for every person satisfied with this use case you will find many to the contrary. We already have a ‘basic’ standard, common to all: it is defined by mandatory fields.

To return to my much-used UNDP example. Would you like to see the arithmetically clean $400m number they report to the CRS, or the $4bn they account through IATI for their activities on the ground?

Hi,

Is there a list of the mandatory fields somewhere? I tried here in the guidance but couldn’t see it. There is mention in the upgrades for specific mandatory fields?

[quote=“bill_anderson, post:21, topic:1047”]
Is this really what in-country decision-makers need?
[/quote] from my experience, yes - it is not everything they need, but a list of all the active and pipeline projects solves 80% of the needs for 80% of the users. At worst, it is a good starting point for them to be able to follow up further - at which point the use cases become too individual/unique to be able to cater for as a consistent group.

[quote=“bill_anderson, post:21, topic:1047”]
is this really the IATI vision?
[/quote] - I am not sure what the IATI vision is, but it would seem to me that first catering to the dominant user need would be a good start - I could be wrong that this is the dominant user need - and I think that DI commissioned some research last year working out who the users of IATI data were, is that something that is public yet? If not, a public mapping of the different user groups and their data needs sounds sensible to help define what the IATI vision is - and to guide future iterations of the standard/effort.

RE the UNDP example - of course we want the 4bn (UNDP mainly as an implementer, not as a funder), but are you suggesting that in the quest for simple export of basic fields in a flat format, we will not get the $4bn, but instead the $400mn?

I am agreeing (110%) that your use case can be met by a standardised export - and we should do this.

I’m disagreeing that your use case can be used to define the standard itself

Hi - also agreed, IATI is much more than just this one use case

http://dashboard.iatistandard.org/comprehensiveness_core.html

aha - thanks @bill_anderson - based on that, I think @ibrahim and I are suggesting a slight expansion of the core/manadatory fields?

Agreed(100%)

Agreed(100%)

what I am proposing is that the standard has two parts: “Basic” and “Extended”, The “Basic” is the mandatory and the “Extended” is all the others.

Hi @ibrahim

Yes, I think that ‘basic’ and ‘extended’ are a good idea - although there might be ‘extended - results’ and ‘extended - openAG’ etc, i.e. multiple different extensions for different more specific use cases. The reason I like this idea is that it should make it easier to focus on comprehensiveness and usability in the key fields first - and at the same time, perhaps answer some of the needs of those currently campaigning for simplification, and those wanting more extensions. What worries me is that IATI already has some structures e.g. the different parts of the XML tree, and this would add another structure that runs across that which would add complexity.

Matt

As this is a matter for a Major upgrade I guess we have a couple of years to prepare a campaign around this.

Noted…campaign starting now :slight_smile:

Any ideas about the paper I thought that DI commissioned last year on IATI users?

@bill_anderson thanks - regarding recipient country data needs, it mainly references this 2014 USAID report - which has three case studies - and each give their data needs on 34, 80 and 129 .

I just put the three into a google doc, and it is already quite suggestive on how the mandatory/core fields need to change in the next major upgrade if IATI is to meet the data needs of aid recipient countries. In summary, those requested across all three case studies, but not currently mandatory include:

  • Reporting results
  • Basic financials
  • Sub-national locations

I guess the next step is consultation with the data providers to see which of these they are able to supply?

Edit: perhaps I am barking up the wrong tree here - a multiple year wait to change the mandatory fields is a very slow process, and I am not convinced that most of the countries I have tried to excite about IATI will have that much patience. Perhaps better is to gather together a definition of what data fields recipient countries need, and see if we can make a specific quality measurement with which to address donors for improvement. As well as a list of key fields, tt could also include things like requiring the activity description being provided in the national language of the recipient.

There is at least one organization I know of whose business model operates at a national or higher level. Why would you make sub-national locations mandatory when not everyone operates at that level.

Reporting Results is another area I have concerns with as results frameworks vary across the multitude of domain we operate in. In the case of health, we might be tracking, and have targets for, an indicator we would want to mention to help give context, but would not expect a result for another year or more.

I fully agree to re-looking at what is mandatory, but it should be from the perspective of what all organizations have in common so that at the end of the day, when analyzing data you are getting closer to comparing apples to apples, which is not always the case today, or at least that is my 2 cents.

Mat, question of clarification on the disbursments info in the list above: if this is meant to be in a single line per project, I assume disbursments to date, in FY and new FY would be totals, not disaggregated by transactions (like we are asked to publish)? This actually jives with data requests we get from the field ie adding up disbursments by year (or sometimes quarters), not by specific transaction. Just checking that I’m not misunderstanding.

Hi @YohannaLoucheur exactly right, this would be aggregated disbursements. It is not like I can’t see the value of having the individual disbursements in the standard, just that none of the 5 recipient countries I have worked with recently actually uses them in that way e.g. for annual ODA reports, budget integration, sectoral planning, M&E etc, so for a flat reporting standard, it seems like it would hugely simplify the reports, without losing any/many use cases.

This is a very important point. Not only would it simplify the reports (ie the data), but in some cases it would remove an important barrier to getting buy-in from partners - for instance in cases where commercially-sensitive information may be revealed by publishing individual transactions.

This is a great example why we need feedback from actual users of aid data (not necessarily IATI data), to better understand how they use it, what they need so IATI tools can be responsive.

Hi @YohannaLoucheur - completely with you on IATI needing to be driven by user feedback both in terms of demand i.e. few country level processes need individual disbursements, and also supply, e.g. your information that aggregation

This post mentions a set of user stories that the IATI secretariat use to guide future developments - perhaps a a community we need to go through these again and check how they might have changed since they were first developed?

@Imogen_Kutz are these something you can share - or am I getting the wrong end of the stick and they are user stories in terms of how users use e.g. d-portal etc, but not in terms of the supply and demand for IATI data? If so, are you aware of any user stories / IATI user profiles/analysis that has been done? I only know of the recent DI report here? I guess there must have been right at the beginning?

1 Like

Wearing my DI cap, we are preparing a flat file serialisation not a million miles from your needs. If we can agree on your required columns we can piggyback your job onto ours. Until we are in a position to provide this as a standard output from the data store …

@bill_anderson that sounds great (the datastore version too of course), is the first version a d-portal output?

What is going to be the most helpful way to engage on the columns? No problem to give my choice, but I am sure there will be plenty of other variations/tweaks?

How about a google doc where we could list the colums, and do the different use cases as rows, marking which fields they would need to see if that suggests a clear set?

I am also mindful of @YohannaLoucheur’s previous posts requesting the ability to select/unselect/order which columns appeared in a ‘flat file serialisation’.

I am also aware that we are getting to the stage where different IATI tools (at least the ones that have to make decisions) might end up giving different results based on their different assumptions e.g. I think OPIA allocates a uniform distribution to sectors without percentages but this raises the possibility that the different tools will start producing different outputs e.g. if the flat file tool that you are working on takes a different approach and this might lead to confusion about which is the ‘real’ IATI.

First version is going back to the registry. We have this “unbundling aid” tool which presents 2006-2015 CRS data. We will be adding 2016-2020 data from IATI, which involves a partial IATI to CRS conversion.

For this particular piece of work we could produce a superset of requirements which could be trimmed.

I think this is inevitable. We will share our methodology once finalised. There is, for example, the challenge of double nesting (multiple sectors and countries) which the standard doesn’t currently express an opinion on.