Tech Paper: Hierarchies

Standard Management 2.03 Decimal Upgrade Discussions
#1

The Activity Standard allows for publishers to reflect their particular business model by reporting their activities in a hierarchical structure: for example using hierarchical levels to distinguish between programmes and their constituent projects and sub-components. Rules and guidance are unclear, inter alia, as to:

  • What elements must be inherited by a child activity
  • At what level commitments and budgets can be reported
  • At what level results can be reported

This also impacts upon publisher statistics methodology.

Please add other hierarchy-related issues here

This paper outline is part of the Agenda for the IATI TAG 2016 Technical Consultation Workshop

:bird: #IATI #TAG2016

Tech Paper: Miscellaneous Rules and Guidelines
Representing different levels of programme management in IATI reports
Standards Day: Outline Agenda
#2

Flagging that we also identified some hierarchy related issues when considering traceability. Not sure if any of these were very substantive, so will check with @stevieflow if there is anything we should add to this.

#3

Thanks @TimDavies

I think we found examples that go against the guidance held within the schema:

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

The schema does not test for this, meaning people can easily publish transaction data at multiple hierarchies.

A related issue exists if some organisations pursue publishing requirements for their supply chain (for example) as splitting various IATI elements across hierarchies could present challenges for testing and verifying data (eg: test only for element x at hierarchy y)

#4

Thanks @stevieflow and @TimDavies . We are also aware that there are many publishers using hierarchies in very different ways which of course makes things very difficult for data users. As a result we are hoping to establish a definitive set of guidelines that all publishers can agree on and can use? Also we are looking at making hierarchies more usable for their original intended purpose which was to enable the earliest reporting of an organisation’s own internal funding decisions and flows.

In addition, as it may not be possible to validate the proposed guidelines via the schema and /or rulesets it may be necessary to include additional code within the Validator to check that hierarchies are being used consistently (if possible)?

Anyway, hopefully we shall be publishing the initial proposals here soon.

#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