Hoverview

donor reporting · logframe · monitoring and evaluation · results-based management

When to use a logframe

A four-quadrant test for deciding when the logframe is the right instrument, and what it costs to keep one alive.

Ask a room of programme staff what they think of the logical framework and you will get two answers, usually from the same people. It is the discipline that forced their team to say what success actually looks like. It is also the spreadsheet they filled in at 11pm because a donor deadline required it.

Both are true. The tool is rarely what separates them. What separates them is whether the logframe suited that programme in the first place, and whether anyone touched it after approval.

What the logframe was built to answer

The method has a specific origin. In 1969 USAID could not give Congress a straight answer about whether its projects achieved what they set out to achieve, and commissioned a review of its project evaluation system. The review named three problems: vague objectives, unclear management responsibility, and evaluations that had become adversarial. Leon J. Rosenberg, working first at Fry Associates and then at Practical Concepts Incorporated, produced the four-by-four matrix that most of the sector still recognises.

The design borrowed from three places: management by objectives, which holds managers accountable for results rather than effort; the scientific method, which treats a project as a hypothesis that can be tested; and systems analysis, which insists that a project sits inside a larger environment it does not control. The assumptions column exists because of the third one.

The method spread quickly and was adopted or adapted by bilateral and multilateral funders as a component of results-based management. That spread is why the logframe now arrives at most organisations as a requirement rather than a choice. The UK's Department for International Development is a clear example: from 1 January 2011 logframes were mandatory for all newly approved DFID projects regardless of value, removing the £1 million threshold that had previously exempted anything smaller. The department merged into the Foreign, Commonwealth and Development Office in 2020, and the requirement travelled with it.

The decision, in two dimensions

The useful test is not whether something counts as a development project. It turns on two questions about the environment the programme sits in.

The first: how much evidence-based outcome accountability is expected? Not activity reporting, but outcome accountability. Will someone outside the organisation ask whether the change actually happened, and expect evidence rather than assertion?

The second: how many parties does delivery depend on, and how uncertain is the causal chain? Is success distributed across agencies, ministries, suppliers, sub-partners and communities, or can one team deliver this and observe it end to end?

Plot those two and four situations appear.

Both high, and the logframe earns its place. Outcomes matter as much as outputs, delivery runs across organisations that do not report to each other, and more than one party needs a shared logic model before anyone can agree what will be measured or who is answerable for it. This is the case the method was designed for, and nothing else does the job as economically.

High accountability in a simple context: take the elements and skip the matrix. Borrow indicators, baselines and targets for your benefits and key performance indicators. A full sixteen-cell matrix is overhead you do not need when one team controls delivery and the causal chain is short.

Low accountability in a complex context: use a lighter logic model and revisit it often. Systems mapping or outcome harvesting will serve better. A logframe here will be out of date faster than you can get it approved.

Both low, and a classic project plan will do. Saying so out loud saves everyone a fortnight.

The method fits public-sector reform, health, education, environment and social-impact work. Those are the places where success depends on agencies, departments, suppliers or communities acting together, where donors, regulators, boards or environmental, social and governance (ESG) commitments require evidence, and where the parties involved have to agree on cause-and-effect pathways before they can agree on anything else.

Where to be careful

The critique of the logframe is old, well documented and mostly fair. Bakewell and Garbutt's 2005 review for Sida remains the standard reference, and INTRAC still publishes it on the grounds that the analysis has aged well. One of its persistent findings is that the approach can inhibit participatory planning, because logframes are frequently written in head offices rather than in the field.

Des Gasper gave the sector its vocabulary for the failure modes, and the three terms are worth keeping straight. A logic-less frame is one written after the design was already settled, to satisfy a form. A lack-frame is what you get when a situation is jammed into a matrix too small to hold it, and the logic that existed at the start is lost in the fitting. A lock-frame is one that is fixed at approval and never updated again, which blocks exactly the learning the framework was supposed to support.

The third is the one most programmes actually suffer from.

Four situations warrant caution or adaptation:

  • The problem and the intervention are still emerging. You cannot write a testable hypothesis about something you have not yet identified.
  • Cause and effect are nonlinear. In complex adaptive systems, the vertical logic of the matrix asserts a directness that does not exist.
  • Indicators would be premature or misleading. An indicator chosen too early becomes the thing the programme optimises for, whether or not it tracks the change anyone cares about.
  • The logframe would be treated as a static compliance document. This is Gasper's lock-frame, and it is the most common of the four by a distance.

The adaptive management literature is blunt about that last one. In a widely circulated checklist for spotting genuinely adaptive programmes, the alarm bell rings loudest when the logframe and theory of change remain unchanged across the life of a programme despite a shifting context and repeated opportunities to learn. The same authors are clear that adaptive programming does not mean a programme without goals, or one with continuously shifting goalposts.

The answer that emerged from that debate is not abolition. One review of adaptive management practice concluded that the response is to handle logical frameworks, results frameworks and theories of change more reflectively and elastically, and that the sector needs planning, monitoring and reporting tools that work within the dominant aid paradigm rather than against it.

What it costs to do properly

Four things need to exist before a logframe is worth writing: a defined problem, knowledge of who is involved and what each party wants, baseline measures or a credible plan to get them, and indicators that are feasible against data sources that actually exist.

None of that is an afternoon's work. If your process allows an afternoon, you are not producing a results framework. You are producing a document that looks like one.

The baseline point deserves emphasis. A missing baseline is visible and can be filled. An invented baseline is invisible and contaminates every subsequent judgement about whether the programme worked.

Logframe and theory of change are not rivals

The framing of logframe versus theory of change has never been especially useful. A theory of change is primarily a design tool. It explains how and why change is expected to happen, and it can hold multiple pathways and feedback loops. A logframe is primarily a monitoring, evaluation and reporting tool, giving a concise structured view of what the intervention does. They serve different purposes at different points in the programme lifecycle.

In practice: build the theory of change to choose the pathway and surface the assumptions, then derive the logframe from the pathway you selected. The logframe inherits its causal claims from something explicit, rather than acquiring them by accident from the shape of the template.

The part nobody designed the logframe to solve

Here is the situation the 1969 matrix was never meant to handle. One programme. Four funders. Each with its own template, its own vocabulary, its own numbering scheme, its own rules about how many indicators an output may carry and what may be changed after approval.

One donor calls the top level Impact, another calls it Goal, a third calls it Overall Objective. One puts activities inside the matrix; another keeps them out. One requires at least two indicators per output; another caps you at three. One wants percentage targets accompanied by absolute numbers; another wants cumulative and incremental figures in the same cell.

None of that is a disagreement about your programme. It is a disagreement about rendering. But because most teams hold their results logic in whichever document the biggest donor asked for, the differences get resolved by hand, in copies, and the copies drift. By month eighteen there are four logframes, nobody is certain which is authoritative, and a figure corrected in one has been quietly left wrong in the others.

The sector knows this is expensive. The Grand Bargain named donor reporting as a priority area for reform precisely because funders use widely different terminology to request what is essentially the same information, and the resulting administrative burden falls hardest on the people writing the reports. The 8+3 harmonised narrative template was the response, and it has moved. The 2022 independent review reports that as at the end of 2022, over half of all grant-giving signatories were using it in at least some form with their civil society partners. It publishes no more precise figure than that, and it notes that the benefits are only fully realised when adoption reaches scale.

Harmonisation is the right direction and it is slow. In the meantime the burden is structural, and it does not fall on donors.

Treating it as a living artefact

The programmes that get value from a logframe treat it as something that accumulates rather than something that gets filed. It is updated as evidence arrives and as context shifts, and the update is visible to everyone who relied on the previous version.

Making that safe requires two things that spreadsheets do not provide.

The first is a record of what changed, when, and on whose authority. The adaptive management community arrived at the same requirement from the opposite direction. The standing objection to adaptive programming is that decisions become invisible and unaccountable, and the answer proposed under the heading of adaptive rigour is a documented, transparent trail of intentions, decisions and actions. That trail is what distinguishes adaptation from making it up as you go along.

The second is a firm line between a revision and a correction. A closed reporting period that gets silently edited destroys the audit trail that made the framework worth keeping in the first place. A restatement preserves it: recorded, explained, superseding the earlier figure without erasing it.

A short checklist

Before you write one, answer these:

  1. Will anyone hold you accountable for outcomes, with evidence, or only for outputs?
  2. Does delivery depend on parties you do not control?
  3. Is the causal chain stable enough to state, or still being discovered?
  4. Do you have baselines, or a funded plan to get them within the first quarter?
  5. Are the indicators feasible against data sources that actually exist?
  6. Who is allowed to change this after approval, and how will that change be recorded?
  7. How many donor renderings of this logic will you be maintaining, and who keeps them consistent?

If question three is unanswerable, use a lighter logic model and come back to it. If question six has no answer, you are about to produce a compliance document.

Question seven is the one without a settled answer. The 8+3 template is moving in the right direction and it is moving slowly. Nobody has yet said what a team maintaining four renderings of the same logic is supposed to do in the years in between.

Sources

Origins of the method

Critique and adaptation

Adaptive management and rigour

Donor requirements and reporting burden

Theory of change