Results frameworks and indicators in one system

A Results Framework is best understood as a map of what a programme intends to change, how it expects to bring that change about, and how it will know whether it succeeded. The map is read as a chain: activities produce outputs, outputs contribute to outcomes, and outcomes contribute to a longer-term impact. Each level exists to explain the level above it — an activity is undertaken because it produces a particular output, and that output is delivered because it is expected to move an outcome, not as an end in itself.

A simple agricultural example makes the chain concrete. A programme trains farmers (an activity). Farmers who attend that training gain skills (an output — something the programme directly delivers and controls). Trained farmers who go on to actually use improved agricultural practices in their fields (an outcome — a change in behaviour the programme does not control, only influences) then see their production and income rise, and their households' wellbeing improve over time (the impact — the long-term change the programme contributes to, alongside many other factors outside its control).

Impact is the highest-level, longest-term change a programme contributes to — "improved livelihoods and resilience of smallholder farmers," for instance. No single programme usually achieves impact alone; it contributes toward it, together with other actors, other conditions, and time. Outcome is the medium-term change a programme expects to see among the people it works with as a direct result of its outputs — "farmers adopt improved agricultural practices" is an outcome, and it is a genuinely different claim from having simply delivered training. If a programme trains 1,000 farmers but only 700 of them go on to use what they learned, the 1,000 is the output and the 700 is the outcome — and it is the outcome, not the output, that the programme is ultimately accountable for.

Output is what the programme itself produces and directly controls — the immediate result of an activity, such as "1,000 farmers trained on improved agricultural practices." Activities are the concrete tasks a team carries out to produce that output: conducting training sessions, distributing agricultural inputs, establishing demonstration plots, running field visits and farmer group meetings, providing extension services. A full Results Framework for a single programme typically reads, top to bottom: an impact statement; one or more outcomes beneath it; several outputs beneath each outcome; and the activities that produce each output — for example, impact "improved livelihoods of smallholder farmers," outcome "farmers adopt improved agricultural practices," three outputs (farmers trained, demonstration plots established, farmers linked to input and service providers), each delivered through its own set of activities.

A Results Framework on its own only states what change is intended — it says nothing about whether that change actually happened, which is exactly what indicators exist to answer. An outcome such as "farmers adopt improved agricultural practices" needs a defined, measurable indicator attached to it — for example, "percentage of targeted farmers adopting at least three improved agricultural practices," with a stated baseline (perhaps 25% before the programme began), a target (70% by the programme's end), and a genuine, reported actual each period. Only once those numbers exist side by side — baseline, target, actual — does a Results Framework stop being a set of intentions and start being something that can show real progress.

A Results Framework and an action or implementation plan answer two different questions, and the two are easy to conflate. The Results Framework asks what change is being sought — the outcome "farmers adopt improved agricultural practices" is a statement of intended change, not a plan of work. The action plan asks what the team will actually do to bring that change about, by when, and who is responsible: conduct farmer training (an extension officer, January to March), establish demonstration plots (a field officer, February), carry out follow-up visits (the field team, March through June), collect adoption data (the M&E officer, every quarter). A sound action plan exists to deliver the Results Framework, not to replace it — a programme with a detailed activity schedule but no stated outcome, or a stated outcome with no plan for reaching it, has only done half the work.

A common practical failure mode in programme measurement is not a bad Results Framework or bad indicators individually — it is that the framework lives in one document, often a spreadsheet or a donor-required PDF, while the indicators are actually tracked somewhere else, and the two are reconciled by hand, occasionally, under deadline pressure. Every reconciliation is a chance for the tracked numbers to drift from what was originally approved. Keeping the hierarchy and its indicators as a single, live structure — rather than a document plus a separate tracking sheet — means a change to an indicator's target or unit is visible everywhere it is used, instantly, rather than requiring someone to remember every place a stale copy might exist.

A Results Framework in METRA GET is a hierarchy of logframe items (goal, outcome, output, activity), each of which can carry indicators. An indicator is defined once with a unit, a level, and — where it applies — a disaggregation scheme, and that single definition is what every report, dashboard and export reads from.

Indicators can be manual (a number a user enters each period) or computed from a linked dataset or form field, so the same indicator never has two different calculation paths inside one project.

The action-plan side of this same hierarchy is the project's Workplan: each workplan activity links to a logframe output, carries a responsible party, a status and a progress percentage, so the Results Framework's outcomes and the team's day-to-day delivery schedule stay connected as one structure rather than two documents reconciled by hand.