It is two things at once: a planning tool that forces you to think through your logic, and a management tool you return to as the project runs.

The logframe was developed for USAID in 1969 by Leon Rosenberg and colleagues, to bring discipline to vague project plans. It spread through bilateral and UN agencies, was adapted by GTZ into the participatory ZOPP / objectives-oriented planning method, and remains a near-universal donor requirement today — the EU, DFID/FCDO, GIZ, the UN and most large NGOs all use a version.

The matrix is a summary, not a substitute for a theory of change, a work plan, a budget or a risk register. It compresses a rich design into a grid — useful for discipline and reporting, dangerous if mistaken for the full picture.

Read upward, each level is an if–then claim: if we combine these inputs, then we can run these activities; if the activities happen, then we get these outputs; and so on. Each step is a bet that can fail.

When you design, start from the impact you want and work down: what outcome would contribute to it, what outputs would produce that outcome, what activities make those outputs. When you implement, you move the other way: inputs fund activities that yield outputs.

At output level, your project is the cause. At outcome level, you are one of several forces. At impact level, you are a small contributor among many — economic conditions, government policy, other programmes. This is the attribution gap.

ImpactMojo’s The Long View includes an original diagram of the results chain and the attribution gap — the widening distance between what a project delivers and the change it hopes to see. It is the picture behind this whole section.

Inputs are the resources a project consumes: money, staff time, equipment, vehicles, training materials, partner contributions. In many logframe formats inputs sit alongside activities on the bottom row, often linked to the budget.

Activities are the actions that convert inputs into outputs: train, build, distribute, mobilise, advise. Write them as verbs. Each activity should connect clearly to an output above it.

Outputs are the direct, countable products of your activities — the goods and services in the hands of participants. They are fully within your control, so they are written as completed deliverables.

A statement with an “and” in it is usually two results hiding in one box: “farmers trained and adopting new methods” bundles an output with an outcome. Split them.

A workable logframe has one impact, one (sometimes two) outcomes, and a handful of outputs — rarely more than five or six. More than that and the matrix stops being a one-page summary and becomes an unreadable spreadsheet nobody returns to.

Once the left column is drafted, test it: at each step, ask “is this enough to plausibly produce the level above?” If outputs alone clearly will not deliver the outcome, the design has a gap — or there is an assumption you have not yet named.

Inputs are the bridge between the logframe and the budget. A well-built logframe lets a reader trace money to activity to output: this is what makes it a management tool, not just a planning artefact. Donors increasingly ask for cost per output (unit economics).

Get this half tight and countable, and the monitoring almost writes itself. Get it muddled, and no amount of indicator-crafting upstream will save the matrix.

An outcome is the change in behaviour, knowledge, relationships or condition that your outputs are meant to bring about. It is usually the purpose of the project — the single most important row in the matrix, and the hardest to write well.

Impact (or goal) is the long-term, higher-level change your project contributes to: lower mortality, higher incomes, greater equality. It is usually shared with other actors and other programmes, realised over years, and beyond any single project to deliver alone.

Classic logframe discipline insists on a single purpose / outcome. The reason is focus: a project chasing three outcomes usually does none well, and the matrix can no longer show a clean line of logic. If you genuinely have two, ask whether they are really two projects.

The leap from output to outcome is where projects most often fail — and where the assumptions matter most. Training delivered (output) does not guarantee practice changed (outcome); a clinic built does not guarantee it is used. Name what has to happen in between.

In development work, the outcome is usually that some group does something differently: farmers adopt, mothers attend, officials enforce, girls stay in school. Behaviour is influenced by far more than your project, which is exactly why outcomes sit in the sphere of influence.

Outputs land during the project; outcomes often emerge near or after its end; impact may take years. A logframe measured only at project close can miss the outcomes it was built to create — and credit impacts that have not yet had time to form.

A strong outcome statement often carries a hint of durability — “adopt and sustain”. Donors increasingly ask not just whether change happened, but whether it will hold once funding ends. That depends on systems, ownership and incentives, not just your outputs.

With the left column complete, the next job is to make each row measurable. That is the indicators column.

“Objectively verifiable” means two people measuring it independently would get the same answer — no judgement call required.

Some results — empowerment, resilience, trust — have no direct meter. A proxy indicator stands in: e.g. women’s control over household spending as a proxy for empowerment. Choose proxies carefully and state that they are proxies.

Every indicator is a data-collection commitment. One or two strong indicators per result is usually enough; a logframe with forty indicators becomes a monitoring burden that crowds out actually running the project.

Many sectors have agreed indicator sets — the SDG indicators, WHO and DHS health indicators, education access measures, IRIS+ for impact investing. Using standard definitions makes your results comparable and saves you re-inventing measurement.

An indicator with no realistic means of verification is a promise you cannot keep. The two columns must be designed together.

Filling in the MoV column is a cost test. A fancy outcome indicator that needs a 5,000-household panel survey may be unaffordable. If you cannot pay to verify it, you cannot claim it — so revise the indicator to something you can actually measure.

A good MoV entry names the method, the frequency and the responsible person: “observation checklist, quarterly, by the M&E officer”. Output data is usually continuous; outcome surveys are periodic; impact data may come once, at endline or after.

The point of the MoV column is credibility: a sceptical reader (or auditor, or evaluator) should be able to follow it to the same conclusion. That means the source must be reliable, the method consistent, and the data retained.

Columns two and three — indicators and means of verification — are, in effect, your monitoring plan. A fuller M&E plan just adds detail: tools, sampling, responsibilities, timing, analysis and use.

Assumptions are where a logframe gets honest. They name the things that could break your chain even if you do everything right.

Read vertically with the assumptions: IF we deliver the outputs AND the assumptions at that level hold, THEN we reach the outcome. The assumption column sits to the side of each step, carrying the conditions that step depends on.

For every assumption, ask two questions: how likely is it to hold? and how important is it?

A killer assumption is one that is both essential and unlikely to hold. If your whole outcome depends on a policy passing that almost certainly will not, no amount of good delivery will save you. Better to find this on paper than two years in.

Assumptions are not a place to park everything that might go wrong so you can blame them later. Anything you can influence belongs in your activities, not your assumptions. Reserve the column for genuinely external conditions — and then actively monitor them.

Flip an assumption to its negative and you have a risk: “rainfall is normal” → “drought reduces yields”. Modern donor formats often pair the logframe with a risk register that goes further: naming, scoring and assigning each risk.

Risks are usually scored on two axes — how likely they are and how big the impact would be — often on a 1–5 scale each. The product (or a colour grid) gives a rough priority so attention goes to the high–high corner.

A risk register with no owners is a list nobody acts on. Each significant risk should have a named owner responsible for monitoring it and triggering the response, plus a trigger — the sign that the risk is materialising.

Risk is not a one-time annex. New risks appear, old ones fade, scores change. A useful register is reviewed at every project board or quarterly review, with changes logged. A risk register written once and filed is theatre.

With all four columns understood, you are ready to assemble the full matrix — and to test it as a whole.

The participatory tradition (ZOPP) builds the logframe in a workshop with the people who will deliver it and, ideally, those it serves. The matrix that results is usually weaker on paper but far stronger in practice, because the team owns the logic and has stress-tested it.

Read the results column from the bottom: activities → outputs → outcome → impact. At each arrow ask whether the lower level, plus its assumptions, is genuinely enough to reach the next. Gaps mean a missing output, a missing assumption, or an over-reach.

Read each row across: result → indicator → means of verification → assumption. Does the indicator actually measure the result? Can the MoV realistically supply it? Is the assumption truly external? A row that fails this is internally inconsistent.

A logframe is a hypothesis, and hypotheses get updated. Most donors allow — and expect — revisions at review points: refined targets, corrected assumptions, dropped indicators. A frozen logframe is a sign nobody is using it.

For all its usefulness, the logframe has been criticised for decades — by practitioners, evaluators and scholars. Knowing the critiques makes you a better user: you keep the discipline while avoiding the traps.

The results chain implies a tidy, one-directional flow. Real change is messy, looping, full of feedback and unintended effects. Complex problems — governance, social norms, systems — do not move in a straight line from activity to impact.

Because the logframe rewards the measurable, teams can drift toward what is easy to count — outputs, numbers trained — and away from harder, more important changes in power, relationships or dignity. The map starts to shape the territory.

A logframe agreed at the start, then treated as a contract, can punish teams for adapting — even when learning shows the original plan was wrong. Rigidly enforced, it discourages exactly the responsiveness good development needs.

Logframes are written upward, in the donor’s language and categories. Critics note this can centre the funder’s accountability over the priorities and knowledge of the people the project serves — a power dynamic worth naming.

The logframe endures because, used well, it does something valuable: it forces a team to state its logic, commit to measurement, and name its risks, on one honest page. Its failures are mostly failures of how it is used — rigidly, upward, as compliance.

The fastest way to learn the logframe is to draft one for a real or imagined project in your own field. Start from the impact, work down to activities, then fill the other three columns. Show it to a colleague and have them attack the logic.

Built with the team, tested up and across, and revised as you learn, it is one of the most useful disciplines in development practice — as long as you remember it is a summary of reality, not reality itself.