Agreeing best practice - Using Hierarchies

Consultations
#1

Recently I’ve been looking at how we can best use Hierarchies in IATI. The tech team are looking to agree guidance in the interim before the next upgrade. See here for a post about our proposed Future use of Hierarchies.

Our draft guidance is here. Please do comment on this post and in the document.

Below is a summary of our reasoning behind the guidance:

Structuring data
Organisations can use multiple hierarchical models to structure their data. These should best reflect an organisation’s internal structure.

  • The original intended purpose of hierarchies was to enable the earliest reporting of an organisation’s own internal funding decisions and flows.

  • Any number of hierarchies can be used, provided that they are sequential (this rule to be added at the next upgrade).

  • For example, an organisation may need multiple hierarchical structures to reflect their allocation of funds (use-case from DFAT Australia):

Simple:
One bilateral program fund
All budget/ commitment/ expenditure in one country

Moderate:
One non-bilateral program fund
All budget/ commitment done at a higher (regional/global) level
Expenditure attributed to countries after the end of each financial year

Complicated:
Multiple program funds - bilateral and non-bilatera
Budget done at various levels e.g. country and regional
Commitment covers entire investment
Expenditure attributed to countries after the end of each financial year

Internal transfers
Incoming Funds and Disbursements should be used to show allocation of funding/transfers of funds within an organisation:

  • No new type of transaction can be added until the next standard upgrade.

  • Using ‘Incoming Commitment’ and ‘Commitment’ is not appropriate as this would require changing their definitions: http://iatistandard.org/203/codelists/TransactionType/.

  • Using Incoming Funds and Disbursements means the same principles of traceability apply, as with transactions between organisations.

Strongly advise organisations to include the name and ref in the <provider-org> and <receiver-org> transaction elements:

  • This should become mandatory at the next standard upgrade.

  • This allows internal transfers of funds to be identified by the matching provider and receiver org refs.

  • To avoid double counting, only transactions which have differing and should be counted.

Relating activities
Organisations should explicitly detail the relationship between different activities and the internal flow of funds through them using the Parent and Child relationships:

  • When looking at the data, this will help the user navigate the activities.

Other points to note

  • Cannot have hierarchies across organisational boundaries.

  • Related activities can be declared across organisational boundaries, as per the current IATI schema. Our guidance is that Parent, Child and Sibling relationship types should not be used this way: http://iatistandard.org/203/codelists/RelatedActivityType/.

  • Organisations can choose how to structure their data. This allows their IATI data file to best reflect their practices e.g. creating hierarchies based on internal financial flows or results reporting.

Future use of Hierarchies
#2

For reference, here’s the draft from the 2.03 proposal on adding this guidance: https://docs.google.com/document/d/15UVjpbHpIEiDzAujxjgNen9liAFRIsC54M7MIxuSd38/edit

There was a lot of discussion on it here: Tech Paper: Hierarchies

Much of what’s covered in this new guidance appears to be about traceability, rather than hierarchies (here’s the traceability draft guidance). I’m not convinced it helps to conflate these two related topics. There are a number of questions on hierarchies that aren’t addressed here. For instance, the original guidance referenced above recommended against using sibling relationships, but that isn’t mentioned here. There’s also the question of whether it’s necessary to declare reciprocal relationships between parent and child (e.g. if A declares B as a child, is B obliged to declare A as a parent?) The guidance doesn’t answer this.

There’s some existing guidance on the IATI standard website on using hierarchies. Some of this new guidance updates that. For instance, previous guidance stated that lower level activities inherit data from parent activities. But this new guidance suggests that’s no longer the case, and all fields should be present at all levels. Where it’s the case that previous guidance is updated or contradicted, an explanation should be provided for the change.

#3

Thanks for sharing this @amys, I think we are long overdue a discussion on this to gain some more clarity and consensus on how we should be proceeding! I added some suggestions in the document itself, but to summarise:

  1. I think it would be good to look back at previous discussions and guidance (e.g. [1][2][3]) as in several respects the proposed guidance is not really consistent with what has been agreed or discussed before (and therefore would represent a breaking change).
  2. I think the @hierarchy attribute is very useful, as you can easily select “project” or “sub-component” activities without having to cycle through all potentially relevant activities in order to establish this relationship. Also, I have not seen any good arguments in favour of removing it. Doing so will be a breaking change and will make using the data harder.
  3. I have not seen any good use cases for showing the flow of finances internally within an organisation. I also think this would be a breaking change as it would lead to double-counting in existing systems using IATI data (which follow existing guidance).
  4. I would like to understand more why others think hierarchies are not useful and should be discouraged. In my experience, hierarchies are useful from a perspective of data use for a number of reasons – and should be actively encouraged (even if they are currently not correctly visualised in most IATI tools):
    • For example, in the Bangladesh AIMS, we allow users to import whichever hierarchical level they want to. For DFID the most useful level is project (level 1), for the EU it’s the contract level (level 2). For MCC it would probably be the project level (level 2).
    • @bill_anderson also provided a good example for World Bank projects where having greater granularity in the unit of aid (by publishing project components) would provide more useful information – but importantly, these project components should also be linked together to form recognisable World Bank projects to be useful at country level.
Future use of Hierarchies
#4

Thanks for the engagement so far. We’ve had a number of responses on Discuss, in the document and in separate e-mails. Key areas to clarify:

  • We’ve proposed deprecating the @hierarchy attribute and not the reporting of hierarchies

  • We recognise that there are breaking changes proposed which need an integer upgrade, but we should be able to publish some guidance beforehand. Exactly what this is will change as we discuss the guidance.

  • What we mean by ‘internal transactions’
    Better language could be ‘internal decision making’? There are organisations (particularly governments) wanting to publish data in a timely way, and for them this means publishing their internal allocations and decision making, rather than the physical disbursements and expenditures later on. @markbrough and @stolk does this fit with your experiences?

  • Using multiple hierarchical structures. We’re working with organisations who want to use a range of hierarchical structures, depending on the complexity of their activities e.g. activities with multiple parents. We want to find a way for this to work for both publishers and data users.

  • Avoiding double counting. If, when following this draft guidance, for each internal transaction/decision the provider-org and receiver-org is included, these will be the same, and therefore these transactions can be excluded when analysing the data.

#5

Hi @amys, thanks for your reply.

It would be great to understand in more detail the arguments about why this would be a good idea and how the benefits outweigh the (I would argue substantial) costs of even more disruptive changes to the Standard. Even when making integer upgrades, I think we should avoid breaking changes which significantly increase the costs for data users as well as for publishers. I really don’t see any demand or need for these changes.

I don’t think representing financial flows within an organisation is the main reason for having hierarchies. It would be great to see arguments explaining why this would be desirable (and why those benefits offset the costs of additional complexity). I think the reason for having hierarchies is much simpler – as I argued in the guidance document:

Hierarchies allow organisations to publish activities according to their own business model or structure (for example, projects and sub-components)

Having a consistent hierarchy makes it much easier to use the data. If it is really important for organisations to have multiple hierarchical structures (some specific examples would be helpful) then perhaps we can find a way for them to be able to publish in as consistent a way as possible without making their data more difficult to use.

#6

I’ve added my 2 cts. to the Google doc.

Summarizing here:

  • I get the impression the document provides more guidance on ‘traceability of funds’ than on the use of hierarchies.
  • I.m.o. the main question is: how do we represent the internal allocation of funds. I’ll give the reasoning we used in the Dutch publication guidelines below. *
  • I don’t see the use case for displaying the internal ‘transfer’ of funds:
    • I haven’t seen any cases yet where funds are actually transferred within organisations, meaning these transactions would have to be ‘made up’. I think IATI should be descriptive, showing what actually happens.
    • I wouldn’t be interested in seeing internal cash flows - I dont think this provides any relevant intelligence within the scope of IATI.

*)
Background to the use of Incoming Commitment for showing the internal allocation of funds:

When drafting the NL MoFA IATI guidance, initially we tried to steer away from asking for any internal transactions. In order to intelligently create a network of activities and organisations, the inflows and outflows of an organisation should suffice. We were expecting to see incoming flows at the ‘parent-level’ and (most) outgoing flows at the ‘child-level’.
Until we realised there were two cases that couldn’t be modeled:

  1. an organisation receiving co-funding at the ‘child-level’. This could still be visualised assuming the rest of the activity budget would come from the parent-activity.
  2. we found that sometimes activities at the ‘child-level’ are funded from multiple activities at ‘parent-level’. This couldn’t be modeled without showing internal allocations.

In discussions with organisations we found that within organisations, usually there is no cash flow - unless the organisation has multiple legal entities holding different bank accounts, in which case they are often also different publishers in IATI (see for example Amref or Solidaridad). Funds are allocated to activities in a process that most resembles the ‘incoming commitment’: a program manager or fund manager allocate money to activities in a formal process which is also audited.

Real transactions (cash flow) only take place as soon as money is transferred to partners (disbursement) or spent on goods or services (expenditure).

Only one transaction is needed to make the connection between activities. In our guidance we’ve deliberately chosen to always ‘point in the same direction’ - meaning receiving activities should always point at their provider. Keeping the relation at the child-level has a few advantages:

  • It allows for maximum flexibility when planning new activities. Each new activity only needs to point at its parent(s).
  • When money is disbursed to a partner or allocated internally, not all administrative details (activity numbers for instance) may be known yet.
#7

Hi @amys, thanks for kicking off this discussion.

I wonder if some of the underlying assumptions are skewing the tech team’s approach to this.

Assumption 1: Internal financial flows
It feels like you assume that the internal structure only reflects financial flows, and that doesn’t seem to be the case for the organisations that have commented here - MFA, DFID, Oxfam Novib.

In DFID we hold no financial information at h1 level, it is all at h2. We are in fact considering moving to a 3-tier structure (Programme-Project-Agreement) to allow much more flexibility across the wide range of programming types within a large and complex organisation like DFID.

So I don’t think an “internal financial flow” assumption is valid.

Assumption 2: Cascade down
The other assumption you make is that activity information can be cascaded down from a higher level to a lower level. The document specifically mentions budgets, locations, sectors.

I would actually argue that the flow is the other way round - that higher level activities should reflect aggregation of lower level attributes.

But I also think that it would be unrealistic to copy all lower level attributes to the higher level. It may be more sensible to keep those attributes separately because the lower level provides significantly more detail. This is particularly true of attributes like location, but could equally apply to document-links and other elements where multiple duplication would be unhelpful to the end user.

Assumption 3: Hierarchy attribute is not helpful
I think it is useful to have a specific hierarchy attribute, which allows someone to see at a glance what the structure is, rather than having to parse all the related-activity elements up and down the tree.

2 Likes
#8

I agree entirely with John. We (Denmark) has opted for a two-tier hierarchy, with all transactions at the lowest level - the original statement of best practice. The lowest level reflects the financial nucleus of our partnerships - the commitment level in financial terms, or the engagement/aggrement level in the vocabulary of programming guidelines.
The upper level is indeed better understood through the aggregate data from the underlying level, rather than the other way round. It corresponds to the program-level of our design and management procedures - thus it will become a more interesting entity when we, hopefully, solves our problems with semi-automated publication of substantial documents.
That is basically how I see it - the detailed and machine readable data are best published at lowest level, whereas the ‘information’ from human-readable documents and reports most often will be referring to the upper level.
We would never consider to use the hierarchy to reflect ‘internal flows’.

#9

Useful comments from @JohnAdams and @OJ_ – looking at the document again, I think it would be really useful if we thought a bit more about the effect on usability of the data from organisations’ different decisions on how to structure their data using hierarchies. This could factor into guidance or organisations’ own decisions about how to publish their data.

For example:

  • using an inconsistent hierarchical structure means you have to cycle through the data to find the highest-level or lowest-level unit of aid. This is a much more complicated exercise than simply selecting all h=1 or h=2 activities
  • allowing multiple parents for the same activity means that you cannot easily flatten the data. For example, if a child has $500 of disbursements, you don’t know if that should be attributed to parent 1 or parent 2.
  • allowing transactions (maybe other fields too) to be published at different levels rather than only at the lowest level means certain calculations become impossible. For example, if commitments are published at the parent level and disbursements at each of the children, it is impossible to know how much a particular child activity has remaining to disburse (i.e. you cannot calculate commitments-disbursements).

Maybe it’s actually a pretty simple question we need to ask here – can I flatten this data into a spreadsheet in a way that is useful and looks sensible?

#10

A related remark: We should not try to reflect budgetary structures in the activity-file that would be better reflected in an upgraded organisation-file. With last approval of changes to the ‘type-of-aid’ code list I believe that we should have the ingredients we need for an inclusion of ‘core-contribution’ and ‘softly earmarked funds’ in the organisation_file – expanding the current budget-tag to include the expected ‘income’ of those kinds, either at the general budget (core) or at the defined level where the organisation can manage soft earmarks (whether thematically e.g. humanitarian funds, or geographically e.g. regional funds). By adding a simple primary key (‘budgetline_id’) in the organisation_file, at the relevant leaf-level for disaggregation, it would serve as a very valuable foreign key from the activity_file – making it possible to be transparent how the activities are funded in any combination of tightly earmarked contributions (only recorded in the activity_file) and the organisations own budget – and here (in the organisation_file) make it clear whether the core-budget is supplemented by softly earmarked contributions.

I hope to find partners that will lend me a hand drafting such an ‘upgrade’ to the organisation_file, having it on the agenda for TAG in November. It would worthwhile to prove that core-contributions and soft earmarking are the most efficient modalities in development-cooperation, also when it comes to IATI-reporting … aiming to reduce any need currently found to plunge into complex activity-files as you are quoting. I still don’t get the need for tracking ‘internal flows’ in external reporting, and in my world it is not a hierarchy if there are multiple parents to one child. So I obviously need to understand the need of these reporters before I can hold any opinion on what to ignore when you are flattening.