The problem is not that programme teams do not know how to fill in a logframe. Most can. The problem is that the logframe is routinely designed as a compliance document built to satisfy a donor's programme design requirements rather than as a management tool designed around the actual decisions programme leaders need to make.
When the logframe is a compliance document, it is filed and forgotten. When it is a management tool, it sits at the centre of every quarterly review, every workplan revision, and every resource reallocation decision. Designing the latter requires a different starting point entirely.
What a Logframe Actually Is
A logical framework is a matrix that presents a programme's logic in a structured, testable format. The standard four-by-four matrix contains:
- A project description column the hierarchy of results from activities through outputs, outcomes, and impact
- An indicators column the measurable evidence that will show whether each level of results has been achieved
- A means of verification column the data sources from which indicator values will be collected
- An assumptions column the conditions outside the programme's control that must hold for the results chain to work
The logic embedded in the matrix is vertical and horizontal. Vertical logic: if activities are completed, outputs are produced; if outputs are produced and assumptions hold, outcomes are achieved; if outcomes are achieved and assumptions hold, impact results. Horizontal logic: each result level has specific, measurable indicators with defined data sources and verification methods.
Both dimensions must be sound for the logframe to be a useful tool. A logframe with a plausible vertical logic but unmeasurable indicators is decorative. A logframe with measurable indicators but a broken vertical logic produces data that cannot be linked to results.
The Results Hierarchy: Understanding Each Level
Activities
Activities are what the programme does. Training of community health workers. Configuration of DHIS2 Tracker for disease surveillance. Distribution of insecticide-treated nets. Conducting household surveys.
Activities are the input of the results chain, not the result. A common and costly logframe design error is placing activities at the outcome level reporting training sessions conducted as though they were the change the programme was designed to produce. Training is an activity. Change in health worker practice is an outcome. The distance between the two is where most programme evaluations find their gap.
Outputs
Outputs are the direct, tangible products of activities the things the programme delivers. Number of health workers trained. Number of surveillance reports generated. Number of communities reached. Number of data collection tools deployed.
Outputs are under the programme's direct control and are typically straightforward to measure. They are necessary for outcomes but not sufficient. A programme that delivers all its planned outputs and produces no change in the target population has not failed at implementation it has failed at theory of change design.
Outcomes
Outcomes are changes in knowledge, skills, behaviours, practices, or systems that result from programme outputs. Health workers who apply case definitions correctly at the point of care. Surveillance data that reaches the state epidemiologist within 48 hours. LGA health officers who use dashboard data in weekly briefings.
Outcomes are harder to measure than outputs, take longer to materialise, and are more difficult to attribute to a single programme. These are precisely the reasons they matter more. A programme measured only on outputs can succeed on paper while producing no change in the world. A programme measured on outcomes cannot.
For a full treatment of outcome indicators and how to design them, see How to Design M&E Indicators.
Impact
Impact is the long-term, population-level change that the programme contributes to typically measured in health burden terms: morbidity rates, mortality rates, disease incidence, disability-adjusted life years. Impact is rarely attributable to a single programme and operates on a timescale that exceeds most programme funding cycles.
In logframe design, this creates a practical tension: impact is what ultimately matters, but it is not what a three-year programme can demonstrate with certainty. The solution is to design the logframe with impact as the directional goal while measuring outcomes rigorously. If the theory of change is sound and outcomes are achieved, impact will follow though demonstrating causality at population level typically requires a separate evaluation design.
Designing the Assumptions Column The Most Neglected Column
The assumptions column is where logframe design reveals its analytical quality. Most logframes I review list assumptions that are either trivially true ("government remains committed to the programme"), demonstrably false ("communities will actively seek health services"), or generic enough to apply to any programme in any context.
A useful assumption is a specific, testable condition that is genuinely uncertain, that the programme cannot control, and that matters to the results chain. For a disease surveillance programme in West Africa, real assumptions include:
- Laboratory capacity at the state reference laboratory maintains sufficient throughput to process specimens within five business days
- Mobile network coverage in target LGAs is sufficient for DHIS2 synchronisation at least once per week
- State health ministry retains trained surveillance officers in post for the duration of the programme cycle
- Community health workers complete monthly reports consistently without additional financial incentive
These are assumptions because they are uncertain. Some of them will prove false in some contexts. When an assumption fails, it breaks the causal chain at the point where it sits. Identifying that failure early through systematic monitoring of key assumptions, not just programme indicators is what allows the programme to adapt before the results chain collapses.
Build assumption monitoring into your M&E plan. Assign responsibility for tracking each critical assumption. Review assumption status at quarterly programme reviews alongside indicator data.
Selecting Indicators: The Horizontal Logic Test
For each level of the results hierarchy, the indicator must pass a three-part test:
- Does it actually measure the result it is assigned to? An indicator that measures output delivery against an outcome result produces output data and calls it outcome evidence.
- Can it be collected through the stated means of verification? An indicator without a plausible, affordable data source is not an indicator it is an aspiration.
- Is it sensitive enough to detect change within the programme's timeframe? Population-level disease incidence rates will not show detectable change in a two-year programme. An intermediate indicator surveillance sensitivity, investigation timeliness, reporting completeness will.
The third criterion is the one most frequently violated. Programme designers select impact-level indicators for outcome rows because they sound impressive. The programme then produces no measurable change against those indicators not because the programme failed, but because the indicators were not sensitive to the level of change the programme was designed to produce.
For detailed guidance on indicator selection, see the M&E Glossary and How to Design M&E Indicators.
The Logframe in Programme Reviews
A logframe that is not opened at programme review meetings has failed as a management tool, regardless of how well-designed it is technically.
In the WHO polio and surveillance programmes I have supported, the logframe is the first document reviewed at every quarterly programme review. The review structure follows the matrix:
- Indicator status review: For each outcome and output indicator, what is the current value against the target? Red, amber, or green? What is the trend?
- Assumption status review: Which critical assumptions are still holding? Which have changed? What are the implications for the results chain?
- Workplan adjustment: Based on indicator status and assumption changes, what adjustments are needed to the workplan for the next quarter?
- Resource reallocation decisions: Are resources allocated to the activities most likely to move the lagging indicators? If not, what changes are needed?
This structure turns the logframe into what it was designed to be: the analytical backbone of adaptive programme management, not a static planning document.
Common Logframe Design Mistakes
Too many indicators
A logframe with forty indicators for a three-year programme will either produce a data collection burden that consumes programme resources, or will be populated with estimated values. Discipline the matrix to the ten to fifteen indicators that are genuinely essential for management decisions. For the rest, use a separate monitoring plan with lower-frequency measurement.
Confusing outputs and outcomes
The most common error in logframe design. Training sessions completed is an output. Change in practice among trained health workers is an outcome. Health workers trained is an output. Health workers who apply correct case definitions at the point of care is an outcome. These distinctions matter because they determine what the programme is accountable for and what evidence it must produce.
Baselines set after the programme starts
A baseline measured after programme activities have begun is not a baseline. It is a mid-point. Without a true pre-programme baseline, it is impossible to measure change only to describe current status. Baseline data collection must be completed before any programmatic activities that could affect the indicators begin.
Targets set without reference to evidence
Targets set arbitrarily "increase coverage by 20%" because 20% sounds ambitious produce systematic target failure in challenging contexts and systematic under-ambition in high-performing ones. Set targets based on historical programme performance, population size, resource levels, and comparator programmes. See Results-Based Management for a target-setting framework grounded in evidence.
The Logframe Is a Theory, Not a Guarantee
Every logframe embeds a theory about how the world works how activities produce outputs, how outputs produce outcomes, how outcomes contribute to impact. That theory may be right or wrong. The purpose of monitoring is to test the theory in real conditions and to adjust when the evidence shows it is not holding.
A programme that rigorously implements a flawed theory of change will produce outputs faithfully and outcomes that diverge from the results chain. The logframe is the tool that makes that divergence visible early enough to respond.
This is what the Data-to-Decision model demands: not just that data is collected against a plan, but that it informs a real-time feedback loop between evidence and action.