Results framework without hard indicator periods

Context

The EUTF is using RSR to track the progress of its projects. This is a large portfolio of around 300 projects. One of the core features of RSR and an important reason for its use by EUTF is the ability to enter indicator reporting data and have this data aggregated.

The projects are organized in three levels. The top level has only one project, the “root” EUTF project. A number of indicators are defined here. Currently they are 19 indicators organized in one result, EUTF indicators. Then there is a second level, DEC, on which the management of the project activities is run. The third level, CTR, represents the actual field activities and it is on this level that the reporting from the field takes place.

Typically some of the indicators from the EUTF project are imported to the DEC while a set of unique results/indicators are created on this level and those are imported to the CTR child projects. In some cases the EUTF indicators that are used by the DEC are imported to the CTRs too. In some cases there are also results/indicators defined on the CTRs that are not imported from the DECs.

The main concern for EUTF is that the current way RSR works, where indicator periods are set and inherited when importing a results framework is too much of a straight jacket. The EUTF itself is a fund that runs until 2025 and the DECs span long time frames although not necessarily the full length of the fund. The CTRs in turn are shorter in duration still and different CTRs under the same DEC can have different time frames.

RSR being very hard to use for the EUTF as a data gathering and reporting tool in its current form. This document investigates how RSR can be extended to meet the needs of the EUTF while at the same time keep on functioning in the same way as before for our other partners that use the structured way of reporting that indicator periods provides.

High level overview of new features

The core change is to eliminate the hard links between indicator periods on different levels of a framework. Results and indicators retain their links to parent results and indicators, but the indicator perdiod does not. Instead the aggregation of periods from a child to a parent is based on finding all child periods that have date ranges that fall withing the date range of the parent (Including date ranges that coincide). There are several ways child period dates could be set, see below.

The period dates could still be inherited when importing a results framework, but it's probably better to base the period dates on the start and end dates of the project the framework is imported to. In the case of EUTF this is the logical choice since the duration of projects on the different levels is so varied. The only constraint that needs to remain is that a period, or set of periods, on a child may not extend beyond the start or end date of its parent indicator period. (Possibly a parent could have an indicator period with no dates.)

Aggregating based on the rule above leads to all current frameworks, that are set up with multiple periods that are common across the framework levels, working exactly the same as now. But in the case of EUTF, and any other organisation that has similar needs, it allows for a looser structure where IndicatorPeriodData (aka Updates) could either include a full date range, or just a timestamp representing the end of an implicit period, the start of which would be the previous end date or the start of the project.