Definition

A logical framework — universally shortened to logframe — is a matrix that summarises the intervention logic of a project on a single page. In its most common form it has four rows and four columns.

The rows are the levels of objective, ascending from what the project does to what it is ultimately for. The columns are, for each level: the narrative summary, the indicators by which achievement will be verified, the means of verification for those indicators, and the assumptions that must hold for the next level up to follow.

	Narrative summary	Indicators	Means of verification	Assumptions
Goal / Impact	The long-term change the project contributes to
Purpose / Outcome	The change in the target group the project is accountable for
Outputs	The deliverables the project produces
Activities	The work undertaken to produce the outputs

Row labels vary by funder. The European Commission’s format uses Overall Objective / Specific Objective(s) / Outputs / Activities; older USAID and UK usage says Goal / Purpose / Outputs / Activities; many agencies now use the OECD-DAC results vocabulary of Impact / Outcome / Output / Activity. These are the same four levels under different names, and mixing vocabularies within one matrix is the fastest way to make a logframe unreadable to an appraiser.

Origin

The logframe was developed in 1969 by Leon Rosenberg at Practical Concepts Incorporated, under contract to USAID, which wanted a way to make project design assumptions explicit enough to be evaluated later. It spread to the German and British agencies in the 1970s and 1980s and is now the oldest continuously used planning instrument in development practice.

The two logics

A logframe is read in two directions, and both must hold.

Vertical logic (the causal chain). If the activities are carried out and the activity-level assumptions hold, the outputs will be delivered. If the outputs are delivered and the output-level assumptions hold, the outcome will be achieved. And so on up. Each step is a conditional claim, not a promise — the assumptions column is what makes it conditional. A logframe whose assumptions column is empty is asserting that nothing outside the project can affect it, which is never true.

Horizontal logic (verifiability). Each row must be checkable on its own terms: this is the claim, this is how you would know whether it happened, this is where that evidence comes from, this is what has to be true anyway. If the means of verification names a data source the project will not have access to or cannot afford to collect, the indicator is decorative.

The Approach is not the matrix

This distinction is worth stating plainly, because collapsing it is the most common conceptual error in the field.

The Logical Framework Approach (LFA) is a structured, participatory analysis process: stakeholder analysis, problem analysis (the problem tree), objectives analysis (the objectives tree), and analysis of alternative strategies. It is deliberative and takes days, sometimes weeks, and usually involves the people the project is meant to serve.

The logframe matrix is the one-page artefact that the Approach produces. It is a summary, not a method.

Teams that download a blank matrix and fill it in have skipped the Approach. The result reliably looks like a logframe and reliably fails to survive contact with implementation, because the causal claims in it were never tested against a problem analysis and the assumptions were never elicited from anyone who knows the context.

Who requires it

• European Commission — a logframe is required as an annex to most EuropeAid / DG INTPA grant applications and is the standard reporting spine for the resulting contracts.
• GIZ — long-standing user; the German agency was an early adopter and built its ZOPP planning method around the Approach.
• UN agencies, the African Development Bank, and IFAD all use logframes as the standard project design annex.
• Kenya — the national Monitoring and Evaluation guidance under CIMES ships a logframe template as Annex A10, which makes it the expected planning artefact for county and national programmes, not only donor-funded ones.

If your organisation applies to European institutional funders or works with county government in Kenya, the logframe is not a stylistic choice. It is a submission requirement.

Artefacts it produces

• The matrix itself, as a project annex and a reporting template.
• An indicator set with, for each indicator, a baseline, a target, a means of verification, a collection frequency, and a responsible party.
• An assumptions register — the assumptions column, extracted and tracked, becomes a live risk instrument rather than a box filled in once.
• In the full Approach, an activity schedule and a resource schedule derived from the activities row.

How it relates to the other frameworks

• A theory of change is the explanatory model that should sit behind a logframe. The logframe states that outputs lead to an outcome; the theory of change explains why anyone believes that, and under what conditions. The two are complements, not alternatives — the honest sequence is theory of change first, logframe as the summary you submit.
• A results framework operates one level up. The logframe is a project artefact; the results framework is a strategy artefact covering a portfolio, a country programme or an agency objective.
• The OECD-DAC evaluation criteria are applied to a logframe after the fact, at evaluation. They structure judgement, never the plan.
• Outcome harvesting is the method to reach for when the logframe’s core requirement — that results can be specified in advance — does not hold.
• Value for money interrogates the resource side that the logframe’s activities row largely takes for granted.

Common mistakes

1. Treating the matrix as the method. Covered above, and worth repeating because it is the root of most of the others.
2. Empty or platitudinous assumptions. “Political situation remains stable” is not an assumption; it is a shrug. A usable assumption is specific enough that you could check it quarterly and act when it fails.
3. Indicators at the wrong level. Counting people trained is an output indicator. Placing it in the outcome row does not make it one, and an evaluator will say so. The outcome row needs evidence of changed behaviour, status or capability in the target group.
4. Means of verification that do not exist. Naming “national health information system” as an MoV for an indicator that system does not disaggregate the way you need is a design failure that only surfaces at the first report.
5. Freezing it at inception. Assumptions fail, contexts move. A logframe revised through a documented change process is a healthy one. A logframe untouched for four years is either fiction or a project that learned nothing.
6. Confusing “objectively verifiable” with “easy to count”. Verifiability is about whether two independent observers would agree on the value, not about whether the number is cheap to obtain.
7. Over-stuffing. A logframe with forty indicators is a data collection burden nobody will meet. Institutional funders generally expect one to three indicators per result, and the discipline of choosing is part of the value.

How Monival supports this

Monival’s results module is built around the logframe levels directly. You define result nodes at impact, outcome, output and activity level, each carrying its narrative and its own list of assumptions, and attach indicators that hold a baseline, a target, a collection frequency, a data source and a stated means of verification — the four things the matrix’s right-hand columns ask for.

Indicators can be fed from field data rather than typed in: an indicator can be linked to a question on a form so that submissions aggregate into it as a count, a sum or a distinct count, against a target and a unit, with disaggregation by other questions on the same form.

Two honest limits. The framework view Monival ships is a grouped logframe matrix — result nodes grouped and displayed by level, which is exactly what the matrix is. It is not an interactive tree or cascade view; parent relationships are stored on each node but the shipped view does not render them as a hierarchy. And the other framework views in the interface — results framework, logic model, theory of change, outcome mapping — are present as options but not yet enabled.

Where an organisation needs results management beyond that — portfolio-level rollup, integration with finance, or bespoke framework views — Sibasi delivers it as an implemented solution on Microsoft Power Platform and Dynamics 365 Business Central, which is a separate engagement rather than a switch inside the SaaS.