Site Logo
Research MethodsTheory-Based and Logic Approaches

Logical Framework Approach: the logframe, used properly

Evidano7 min read

The logical framework approach condenses a project’s design into a 4×4 matrix: rows for goal, purpose (outcome), outputs, and activities; columns for the narrative summary, objectively verifiable indicators, means of verification, and assumptions. Read vertically it states the causal logic (if activities and assumptions hold, outputs; if outputs and assumptions, purpose; and so on); read horizontally it states how each level will be measured and evidenced. Fifty years after its adoption across development agencies, the logframe is simultaneously the sector’s lingua franca and its most criticised artefact — the criticism aimed less at the matrix than at what organisations do with it: freeze it, worship the indicators, and ignore the assumptions column that was always its analytical heart.

The matrix and its two logics

Vertical logic is a chain of conditional claims. Activities plus activity-level assumptions produce outputs; outputs plus their assumptions achieve the purpose; the purpose plus its assumptions contributes to the goal. Each “if–and–then” is a hypothesis, and the assumptions column is where the project admits what it does not control.

Horizontal logic disciplines measurement: for each level, objectively verifiable indicators (with quantity, quality, and time), and means of verification naming the actual data source. An indicator without an affordable, existing verification source is a wish; the MoV column is where wishes get caught.

The approach is more than the matrix: done as designed, it begins with stakeholder, problem, and objectives analysis (the problem tree flipped into an objectives tree), from which the matrix is derived. Skipping straight to the grid — the near-universal shortcut — is how logframes end up describing projects nobody analysed.

Origins and the honest literature

The approach was developed for USAID at the end of the 1960s and spread through development agencies worldwide; European practice embedded it in project cycle management, and agency guidance (for example the Department for International Development’s logframe how-to notes) standardised the current terminology of outputs, outcome, and impact.

The critical literature is part of the method’s canon. Critiques catalogued across decades — rigidity, false precision, participation theatre — are usefully summarised in the project-management literature; Crawford and Bryce’s Project monitoring and evaluation: a method for enhancing the efficiency and effectiveness of aid project implementation00060-1) analyses the logframe’s weaknesses as an M&E backbone and proposes the time-and-data extensions most modern usage quietly adopts.

The mainstream response to the critiques has not been abandonment but loosening: logframes as versioned summaries of a living theory of change, with revision rights written into funding agreements.

Where the logframe helps, and where it hurts

  • Helps: accountability interfaces. One page tells a funder what will change, how it will be verified, and what could derail it — no rival format does this as efficiently.
  • Helps: design hygiene. Forcing indicator and verification decisions at design time exposes unmeasurable promises before they are funded.
  • Helps: assumption surfacing — when the column is filled with real risks (political, behavioural, systemic) rather than boilerplate.
  • Hurts: adaptive programmes, if the matrix is contractual and frozen — teams end up managing to indicators that no longer describe the work.
  • Hurts: complex change, when multi-actor, non-linear pathways are forced into four tidy rows; there, pair a light logframe with a fuller theory of change.

Building a logframe that survives contact with implementation

Do the analysis phase, even fast

A half-day problem-tree and stakeholder pass beats none: the matrix derived from an objectives tree inherits an actual causal analysis, and the assumptions column fills itself from the branches you chose not to address.

Write one purpose, and make it a change

The purpose row states the single outcome the project is accountable for — a change in target-group behaviour or condition, not a restated output. Multiple purposes are multiple projects sharing a budget line.

Test indicators against QQT and their MoV

Every indicator carries quantity, quality, and time (“by month 24, 70% of supported clinics stock tracer drugs continuously for 3 months”), and a means of verification that exists at a cost the budget carries. Where verification is a survey, the survey is an activity with resources.

Fill assumptions with the killers

Use the kill-test: if this assumption fails, does the level above still happen? Assumptions that fail the test are decoration; the ones that pass become the risk register and the evaluation’s qualitative agenda. An assumption important and unlikely is not an assumption — it is a redesign instruction.

Version the matrix on a schedule

Annual (or milestone) revision with the funder, changes logged and justified against evidence. The revision log is what converts the logframe from fossil to management tool — and is increasingly what enlightened donors expect.

Worked example: a water project’s assumptions column earns its keep

A rural water project’s draft logframe had the classic shape: activities (drill wells, form water committees, train mechanics), outputs (120 functioning water points, 120 trained committees), purpose (“sustained access to safe water for 60,000 people”), goal (reduced waterborne disease). The first indicator pass failed the MoV test — “sustained access” had no verification source — and produced the project’s first real design change: a functionality survey at months 12 and 30, budgeted.

The assumptions column, kill-tested, surfaced the project’s actual fragility: “committees collect sufficient user fees for repairs” and “spare parts remain available within 50km”. Both were important-and-uncertain, so both were converted into monitored assumptions with qualitative verification — committee interviews and a supplier audit — rather than left as hopes.

At the month-12 review, the matrix did its job. Functionality was 91%, but fee collection was failing in a third of committees, concentrated where seasonal incomes made monthly fees unpayable. The versioned logframe swapped the fee model (harvest-time collection), adjusted the indicator, and logged the change with its evidence. The month-30 survey read 84% functionality against a sector norm far lower — and the revision history let the funder see not a missed target but a project that had used its own matrix to steer.

Common mistakes

  • Matrix without analysis. Filling the grid directly from the proposal narrative; the vertical logic then summarises wishes.
  • Output-purpose blur. “Committees trained” at purpose level — the classic level error that makes projects accountable for nothing beyond their own activity.
  • Indicator worship. Managing to the numbers while the assumptions column — where the theory lives — goes unread after signature.
  • Boilerplate assumptions. “Political stability continues” on every project; the column should carry this project’s specific kill-risks.
  • Frozen matrices. Treating revision as failure; the funder-facing fix is a contractual revision schedule, not covert drift.
  • Verification unfunded. MoV entries naming surveys and audits no budget line supports.

Limitations

The logframe’s linearity is a modelling choice that complex, multi-actor change genuinely violates: feedback, emergence, and negotiated outcomes have no rows. Where those dominate, the matrix should summarise a richer theory rather than substitute for one.

Its accountability strength creates perverse incentives — safe indicators, deliverable outputs, assumptions phrased to be unfalsifiable — that only funding relationships tolerant of revision and honest reporting can neutralise.

And participation is structurally thin: matrices are drafted in workshops the intended beneficiaries rarely attend, encoding implementer perspectives as project logic. The analysis phase is the corrective, when actually done with the people the objectives tree is about.

Where software helps

A living logframe consumes qualitative verification continuously: committee interviews, supplier audits, field-visit reports, all mapped to specific assumptions and indicators. Evidano codes those corpora against the matrix — each assumption accumulating quote-linked supporting and contradicting evidence — and multilingual projects can transcribe and analyse verification interviews in the field languages directly, so revision meetings open with an evidence table per row.

The matrix’s content — level decisions, kill-risk judgement, revision calls — is programme management, not text analysis; the tool ensures the column that matters most stops being the one nobody reads.

Topics

  • logical framework approach
  • logframe
  • logframe matrix
  • means of verification
  • OVI indicators
  • project design
  • development projects

Other methods in theory-based and logic approaches

Written guides are linked directly; the rest have a reference entry in the methodology directory.

Keep reading

Browse all articles