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.