Tech Paper: Hierarchies

Standard Management 2.03 Decimal Upgrade Discussions
#5

Thanks @Wendy

I’d add a note of caution in terms of the written-but-not-enforced-rules. Having them operational in the online IATI validator would be useful - but we should be minded that it is perfectly possible for others to validate their data via other methods (XMLLint, for example), using just the schema, and no other rules.

#6

Thanks @stevieflow and the point you make about IATI Standard ‘rules and guidlelines’ is a very timely one and is another issue that we are planning to explore at the TAG see Tech Paper: Miscellaneous Rules and Guidelines

We need to be absolutely clear about what defines ‘The Standard’ eg is it more than just the Schema and rulesets? What other publishing requirements should it include? etc.

#7

@stevieflow are you saying that it is possible to use the schema to validate things such as reporting transactions at the non-lowest level?

#8

@stevieflow are you saying that it is possible to use the schema to validate things such as reporting transactions at the non-lowest level?

@bill_anderson No. The “rule” for this is just written in the textual description for this attribute - not enforced by the schema via any condition. Correct?

Additionally, consider a publisher with two IATI activities:

  • Activity A at hierachy 1 - contains transactions
  • Activity B at hierarchy 2 - also contains transactions

The schema does not check other activities/files to validate the one in hand. It has no awareness that activity A should not have transactions, nor to look in activity B for them.

Consider this publisher: http://dashboard.iatistandard.org/publisher/malariaconsortium.html

This file:
http://www.malariaconsortium.org/IATI-XML/GB-CHC-1099776-J7.xml - passes validation - eg:
http://validator.iatistandard.org/?perm=www.malariaconsortium.org_IATI-XML_GB-CHC-1099776-J7.xml_1485599180

However, within that one file are activities across two hierarchies, both of which contain transactions

#9

W’ve actually adviced organisations to use transactions at different levels of hierarchy: you may run a Programme funded by a donor (transaction for incoming commitment) and have a couple of child related-activities for specific Projects in that Programme, with commitments and disbursements to other organisations.

Exactly like Steven’s example of the Malaria Consortium sketches. And in line with the DGIS Guidelines.

  • An open question is whether transactions between a parent and child activity are needed (not always represented in the financial system that feeds into the IATI data).

  • It often is possible to “collapse” a parent and its child activities into a single activity node that has incoming and outgoing transactions.

So there indeed some questions:

  • Should there be “implicitly declared” or “default” flows along parent-child relations?
  • Should it be allowed to declare a parent-child relation across organisational boundaries?
  • What exactly does it mean to declare a hierarchical relation? We mostly see it used for the way eithr organisational processes or financial flows are structured, but you could also declare parent-child relations based on your theory of change (with more output-oriented results at lower levels, and outcome-oriented results at higher levels of the hierarchy).
#10

Really interesting, thanks @rolfkleef

To just expand on:

It often is possible to “collapse” a parent and its child activities into a single activity node that has incoming and outgoing transactions.

We’ve been looking at this with @JohnAdams and DFID, in terms the use case of “fund managers” publishing information about their link in the chain.

In one example the fund manager takes a nested approach - publishing incoming funds into a central activity, and then disbursing through to hierarchy 2 activities that then disburse out to the implementing orgs. This seems to place an overhead on both the publisher and data user, and we’re not sure of the benefit

Hence, I pulled this slidedeck together to propose a “flat model”, making it less complex to deal with. A trade off could be less detail, but it seems to pay on maintaining utility of the data, versus completeness.

Arguably, the above does not have much direct relation to hierarchies, as we remove them in the flat model. Our core focus is on getting to a point where data can be well-maintained, leading to ease-of-use.

#11

Thanks @stevieflow and I just wanted to add that the primary benefit of using hierarchies for the management of funds that are received by an organisation into a central ‘pot’ before being subsequently disbursed to other funds / projects/ contracts etc. is that it enables the publisher to publish information about funding decisions as near to real time as they are made within the organisation. It can be many months or even years before some funds are actually disbursed to another external organisation so using hierarchies can facilitate the transparency of the funding as it is moved through the organisation over time.

#12

The hierarchy of activities is usually how an organisation already structures the data in their own systems, so it’s actually not that difficult or error-prone to produce IATI data that reflects this.

It improves transparency of how organisations operate (in some of our workshops this leads to discussions about ways of managing your work).

The difficulty is in the transactions from parent to child: there usually are commitments, but an equivalent of a disbursement may be missing. (Hence my question about implicit flows in such structures.)

#13

Current rule is " If multiple levels are reported then, to avoid double counting, financial transactions should only be reported at the lowest hierarchical level."

I think we have consensus on the need for a change so that commitments and incoming funds can be reported at any level. (And ditto for budgets.)

The outstanding issue is disbursements and expenditures. @stevieflow I don’t see examples of this in your Malaria Consortium case. Have I missed it?

Yes, I think so.[quote=“rolfkleef, post:9, topic:539”]
Should it be allowed to declare a parent-child relation across organisational boundaries?
[/quote]

No. I think this could create havoc. Relationships between organisations are expressed through money or role. Isn’t this sufficient?[quote=“rolfkleef, post:9, topic:539”]
What exactly does it mean to declare a hierarchical relation?
[/quote]

It is the representation of an organisation’s business model in circumstances where NOT representing it makes it difficult for an organisation to accurately describe its activities.

I think we should strengthen our guidance that hierarchies add complexities for users and should only be used when a business model can’t be otherwise described.

#14

Our draft paper, is now available here

Feel free to add comments to the document or to continue the discussion in this thread. I will take on an editorial role and combine all comments and suggestions into a coherent document as we go along.

Please note that we have had a further rethink as a result of this thread and are now proposing that any transaction can occur at any hierarchical level provided that there is no double counting within the hierarchical group as a whole.

#15

Thanks! I’ve added some comments (request for clarification).

@bill_anderson I tend to agree with you on the first two questions:

  • Implicit transactions (as in the document) make sense to me.
  • Adding cross-organisational parent-child links may make representing a partnership contract with one lead organisation easier, but in the current way, a lot of other things a lot harder.

For the third, I would promote rather than restrain the use of hierarchies to stay closer to existing information models.

But there is the question of “multiple hierarchies” (rather than “multiple levels of one hierarchy”). This comes up with reporting results: how can you report multiple results and indicators, and have them organised in multiple hierarchies that are cross-organisational (in partnerships) and/or in-organisation hierarchies?

#16

Sorry @bill_anderson, I missed your comment:

@stevieflow I don’t see examples of this in your Malaria Consortium case. Have I missed it?

This example file validates to the schema, but has activities across different hierarchies, that have the transaction element. I was not looking for any mix or range of different transaction types, as the standard guidance does not declare any distinction:

If multiple levels are reported then, to avoid double counting, financial transactions should only be reported at the lowest hierarchical level.

#17

I have tidied up the proposals in the draft paper in the light of @rolfkleef’s comments.

On the question of removing hierarchies altogether - which as @JohnAdams comments could arguably simplify the use of data:

  • If we had to start building the standard from scratch again I would definitely be in favour of a ‘flat’ approach which used a simpler way to express publisher business models and relationships between activities.
  • However 50 publishers are using hierarchies. We can’t - other than through an integer upgrade - force them to change the way they publish.
  • There could be a slow pragmatic solution to this whereby: publishers are persuaded to voluntarily stop using hierarchies; guidelines encourage publishers not to use them; and the attribute is deprecated once no longer used by anyone.
#18

This one hurts my head. The only answer I can suggest is “with extreme prejudice”.

Is this a serious use case?

#19

In our work with results frameworks in partnerships, we precisely run into the problem that there is no way to express related-result/indicator relations.

Sometimes the indicator logic “follows the money”, but an activity with co-funding may serve two different donor results frameworks, or even a third if you have an organisational results framework as well. These frameworks may or may not overlap.

We can show results from the data, but in order to present that in a hierarchy other than through the activity structure, we need separate non-IATI data. People start circulating spreadsheets with indicator names and id’s within a partnership.

It would be easier to show people “what’s in the data” if result hierarchies can be deduced from the data as well. Doing that leads to discussions about possible further standardisation within and across organisations.

#20
  • Would it help if there was something that allowed you to relate an indicator to a donor framework so that for a single activity two similar (but not identical) indicators could be linked to the donor requirements.
  • Would it also help to be able to indicate in Activity A that results reported in Activity B (irrespective of publisher) also apply to activity A?

You’ve still lost me on this one

Agreeing best practice - Using Hierarchies
#21

Interesting discussion! I added a few comments in the document in defence of hierarchies :slight_smile:

Basically, I think they are very useful for interpreting / understanding the data. In the Bangladesh work we’ve used them quite a lot. On the publisher side, I think they also allow data to be accurately expressed while also making it possible to publish more detailed data by publishing subcomponents of larger programs.

At the same time, we definitely need better advice on ways of handling hierarchies from the user perspective. It would also be good if some of the major tools that exist for exploring the data (particularly d-portal) handled this better.

Hierarchies - related-activity definition (included 2.03)
#22

@bill_anderson Yes, I think this rule will clarify the handling of fund hierarchies.

I am not sure about the rule “provided that there is no double counting within the hierarchical group as a whole.” It might be interesting information to track the outgoing flows from hierarchy level 1 to hierarchy level 2. E.g. when want to answer questions as “How much is programmed by the fund manager (=actually allocated to specific implementing organizations) but is not yet disbursed to the implementing organizations.”.

So the double counting should i.m.o. be dealt with at the moment of presentation and not on the moment of publishing the data. How you deal with it is depending on your use-case. I agree with @markbrough that the IATI consuming tools should take care of this. The data need i.m.o. to represent the real world business process as close as possible?

#23

The current usage of hierarchies across 500+ publishers is as follows:
43 publishers are currently using 2 levels of hierarchies
6 publishers are currently using 3 hierarchies
2 publishers are using the highest number of 4 hierarchies

Do we know who are the 6 and 2 using >2 hierarchies?

Agreeing best practice - Using Hierarchies
#24

@JohnAdams There is a view on the IATI dashboard that shows hierarchy use. Clicking on the column heading also enables ordering of the data which is useful.