Disaggregation of results

[nadiagorchakova]

Context

M&E systems that are built for learning and to help organizations address inequities (which is a key priority of the Sustainable Development Goals) must disaggregate indicator data in order to unveil potential inequities among different groups. Disaggregation involves dividing data by categories like sex, age, race, caste, etc. For example, knowing the disaggregation of voters in the US by race and gender can helps us understand the racism and sexism still present in this country.

Regarding compliance with IATI standard, indicator dimension is part of the current IATI version 2.02. See for more details:

On target dimension: http://dev.iatistandard.org/202/activity-standard/iati-activities/iati-activity/result/indicator/period/target/dimension/

On actual dimension: http://dev.iatistandard.org/202/activity-standard/iati-activities/iati-activity/result/indicator/period/actual/dimension/

Problem

Target and Actual Dimension fields are already part of the Project Editor in My RSR:

However, these fields are not currently shown on the project page. Also it appears, that the fields do not go into the IATI file either..

Partners who need to use disaggregation of indicator values are currently using a hack - they input desegregated information, e.g. numbers per gender, age group, race, etc in actual value comments. Like in this project, for example:

Suggested solution

Disaggregation of results & indicator values by gender, age group, race, etc should be shown in the My Results page, once this information is input in the project editor.

Values from these fields should be part of IATI reporting.

In case of parent-child hierarchy, results from all children (grouped by gender, age group, race, etc) should be aggregated to the parent level.

'Dimension' fields should be added to RSR validations set as well (right now, the fields open up in Project Editor only if you select IATI validation set).

Values from 'Dimension' fields should appear in My Reports: 'Results and Indicators Overview' and 'Results and Indicators' table

Mockup

https://projects.invisionapp.com/share/EWANT8P3R#/screens

[nadiagorchakova]

I'll move this one to Product and Design repository. There were some related requests from Henry about the same thing. Needs to be investigated a bit more.

[punchagan]

There are already models called IndicatorPeriodTargetDimension and IndicatorPeriodActualDimension which attempt to implement this.

[nadiagorchakova]

Also, as Gabriel mentioned, we might actually try and re-use the code that will be written for https://github.com/akvo/akvo-rsr/issues/2446, as some of the components might be similar/same.

In #2446 issue, the idea is to allow user input several values that go into the calculation of the actual value (numerator and denominator)

[punchagan]

@mato74 We ( @Kiarii @nadiagorchakova Ethel and Anthony ) would like to get your inputs on this issue.

Based on our discussion and our reading of the IATI standard, we conclude the following things:

• IATI calls disaggregations as dimensions
• A dimension, as defined by the IATI standard, is just "some kind of a tag" on an indicator update to "describe" the category of the data being reported.
• If an indicator has two disaggregations (for example male/female), the IATI standard expects two different indicator periods (one each for male and female) with different dimensions attached to them.

@Kiarii has worked on wireframes for this feature, without taking inputs from the IATI standard. The design seems quite intuitive to use, but there are some problems with getting this to work correctly with IATI's expectations.

The design puts the disaggregations at one level lower than the indicator periods in the hierarchy, and each disaggregations has it's own actual value associated with it. So they are different from IATIs dimensions, in that they are not just tags, but more.

• The design currently also has target values associated with each disaggregation, but Ethel suggested that usually disaggregations don't have target values and only indicators come with target values. So this is up for discussion. But, if this is removed, this will become impossible to be mapped back to the IATI's convention of having a separate indicator for each dimension, for the same period.
• It seems like actual value comments usually go with the whole indicator, rather than disaggregations/dimensions, in practice, and that's what we have in the current design. Again, that makes it tricky to get IATI exports working correctly.

We were wondering if you could throw some light on why the IATI standard treats dimensions the way it does, and if we are missing on some use cases that led to this schema in the IATI standard.

[AkvoAnt]

@punchagan (@Ethel): What I've seen (in a different sector) is that separate indicators are simply created for collecting disaggregated' results, i.e. instead of having a indicator that reads 'Number of PEOPLE ...', you have two indicators split so that they read 'Number of YOUNG WOMEN ...' Then you auto calculate (locked) the sum of FEMALE and MALE to get PEOPLE.

Is it out of reason/functionality to ask Partners do this when setting up their Results Framework? For all appropriate indicators of course.

Also, possible to that you split the target for total PEOPLE, e.g. 50% male - 50% male, or 60% female - 40% male, with the Partner determining percentages when setting up their Results Framework.

Just quick first thoughts.

[AkvoAnt]

Update after meeting with Marten and Kiarii: https://docs.google.com/document/d/1YU3-NKHwqm52MjSWW5bb5B7D5jeXARk3os8rn0FrPAk/edit