Isn’t this (best) expressed in the data as funding going to the same activity? In other words, by the recipient indicating both donors’ incoming funds to this activity and/or both donors indicating which recipient’s activity their funding goes to?
1 Like
I had always interpreted related activity as being for situations where activities were related e.g. in terms of objectives, joint planning etc, but where there were no financial flows that would already have allowed that link to be made, whether it was between different donors, within a donors portfolio etc.
Perhaps more importantly, do we know many publishers who have a publishing process where they lookup the activity codes of either related activities or activities/org codes from other publishers that they are funding? If not, all this is a bit optimistic no?
IOM had a few conversations with a few of our donors while at TAG and off-line. Knowing the donor reference is often known at the time the donor agreements are signed. We don’t currently have a place to store that info such that it can easily be pulled into our IATI data set but we are working on it.
Expecting us to look it up after the fact is ambitious. Particularly when some of our donors don’t publish their donations to us until after we’ve published the projects they have funded. We be playing catch up most of the time.
The challenge we face (may not be an issue for others) is that we don’t know what our project ID will be at the time of signing the agreements. That would require a follow up to communicate that information back to the donor if they want to reference our IDs. That too is ambitious I believe but would be a possible solution for linking two donors to the same project.
It is imperfect but our plan was to use the participating-org/@activity-id or provider-org/@provider-activity-id elements/attributes/?? when we do. Our (perhaps incorrect) understanding of related-activity wasn’t for this purpose. If you “experts” tell me otherwise, we still have time to course correct as we don’t yet publish this info.
That’s a challenge we identified as well when trying to figure out how to get activity IDs. My very simple suggestion: put your activity ID (and org ID for that matter) on all your communications to the donor, especially reports. Very little cost, no risk, and tremendously useful if the donor ever wants the info.
We do and always have but that doesn’t mean the donor does anything with it that makes its way into IATI.
Maybe I am missing something in the workflow here, but isn’t it always the case that at the moment of signing the contract/agreement, the donor knows their own funding activity-id? In that case the recipient can always point back to the donor’s activity-id (which is mentioned in the contract). So the key point here is to point upward in the funding chain and not downward, since that would require the donor to refer to not (yet) existing activities.
Herman - you aren’t missing anything. What you suggest is completely possible assuming the recipient system has a place to store that data. My point was only that it would only work in one direction and thus might not help all users depending upon what direction they are coming from along the chain. I would have thought that ideally both donor and recipient would cross-reference one another so the traceability could work in either direction.
As you point out @Michelle_IOM it is already possible for donor and recipients to cross reference each other and the IATI Standard does already make provision for that to happen. However, as @Herman has mentioned (and it was also my understanding) I think that the original intention for traceability within IATI was just to trace upwards within the funding chain? As @Herman and @YohannaLoucheur have pointed out a donor or funder can generally provide their own originating IATI activity identifier to the recipient via contract documentation and/ or as part of the contract management business process etc .
Interestingly, some of our most recent work within the Grand Bargain (particularly around issues relating to Localisation) is highlighting that there would indeed be value in being to be able to trace both ‘up’ and ‘down’ the funding chain. Presumably for this it happen, Donors and other funders would need to regularly ‘harvest’ the recipient activity identifiers and add them into their own systems. I think this process could certainly be automated and it would also provide donors with an automatic confirmation or validation that recipients have also now published the receipt of that funding to IATI? As a result I would be very interested to hear any views from donors or others on the practicalities and appetite (or lack of?) for making this happen?
NB as this question is moving away from the original post topic I am happy to move this post to a new topic if required
4 Likes
@Wendy +1 for starting a new thread. The reciprocal links question is v interesting, but it’s sufficiently different to this related-activity discussion.
@Herman @stolk @pelleaardema - I was looking at a full set of “linked activities” via the Yes I Do programme just recently.
Whilst the use of linkages via transactions is clear, there is also use of related-activity (parent) between different organisations in this chain.
Hence, Rutgers declare their activity has a parent of the Plan Nederland activity:
Given we have a set of 29 activities from nine publishers, we could just consider this as a slight blip - esp as other publishers in this “family” do not act this way. However, I’d be interested to hear thoughts about this - especially if it starts to break stuff!
1 Like
Hi, @stevieflow @Herman @pelleaardema , within the DRA alliance, the lead organization in a ‘joint response’ is actually the holder of the parent activity, whilst participating organizations in that ‘joint response’ publish the child projects. As far as I know DRA members do not use the related activity across to point up to an alliance member in the ‘joint response’ lead role (rotating function in the alliance). But I find the use of related activity parent, better than provider org activity ID, as DRA acts as an alliance. That is also often the case within the Oxfam Confederation, where participating affiliate contribute from their parent to executing affiliates implementing.
Thanks @stolk
Whilst I’m not aware of a specific “rule” that governs usage of related-activity , perhaps we have to be pragmatic in terms of what means “external” It seems quite legitimate to use this within the context of a delivery chain / consortium, as evidenced.
I do think this isn’t in the Netherlands MFA guidance - would be interested to hear from @Herman & @pelleaardema
@stevieflow and @stolk: in the Dutch MFA guidelines we have added the related activity with the purpose of enabling publishers to model the logical activity structure of an alliance, even if there are no transactions (yet).
Another example that makes the case for ‘standardising the standard’.
If my memory serves me correctly the original Version 1 codelist contained 3 values - parent, child, sibling. A child was defined as a ‘sub-component’ of a parent: the assumption being that they both belonged to the same organisation.
This is not, however, clear in the wording of the standard (in both schema definition and code list).
There were four codes in version 1.01: http://reference.iatistandard.org/archived/101/codelists/related_activity_type/index.html
The text which includes “sub-component” has always been there. It looks like “reported to IATI” was added along the line, but I can’t see whan (@andylolz: would you know?)
If there is any assumption about who publishes, then this isn’t / wasn’t stated.
A fifth code, “Third Party” was added in version 2.01 update: http://reference.iatistandard.org/203/codelists/RelatedActivityType/
It was added in v2.01 in this commit, as part of this issue. It’s mentioned at the bottom of the related proposal:
- A clearer definition has been found for the proposed Related Activity Type
I’ve mentioned it before, but this sort of historical paper trail is really useful for maintaining organisational knowledge. It’s pretty good in this instance, but could be better.
We shouldn’t be in a situation where the only explanation for a change resides in the memory of the previous tech lead! 
Hence the importance of removing all ambiguities by standardising the standard.
For what it’s worth this, I believe, was the initial set of codelists, dated 3 December 2010 - https://drive.google.com/file/d/1n8Gjm6Tpn5LJeZEFsB5PI7gESzDuJEHS/view
This folder contains the documents that were (I believe) present on the first iatistandard website, end of 2010.
1 Like
Yikes! Some of those look eerily familiar.