Your Logframe Is Lying to You: How to Run a Proper Mid-Term Review Before It's Too Late

Here is a pattern I see constantly across humanitarian and development programs: a logframe is drafted carefully during the proposal phase, shaped by the donor's template, cleared by the project team, and then quietly filed. The next time anyone opens it is at the mid-term review, when an external evaluator is already in-country and the findings are already uncomfortable.

By that point, the project has usually spent roughly half its budget. Activities have run. Staff have rotated. The context has shifted. And the logframe, frozen in amber since Year 0, is describing a theory of change that may no longer match reality.

This is the core problem: a logframe is not supposed to be a proposal artifact. As Better Evaluation puts it, the Logical Framework Approach is "a systematic, visual approach to designing, executing and assessing projects" intended to guide implementation through the entire project lifecycle [1]. The matrix should function as a living management instrument, not a document you recover from a shared drive six months before your final evaluation.

But knowing that in principle and acting on it in practice are two very different things. So let me walk you through what a meaningful mid-term logframe stress-test actually looks like in practice.

Why Logframes Go Stale (and Why It Matters)

The 4x4 logframe matrix connects your project's goal, purpose, outputs, and activities to measurable indicators, means of verification, and assumptions [2]. Every cell in that matrix rested on judgments made before implementation began: judgments about what your beneficiaries needed, what your partners could deliver, what the enabling environment would look like.

Those judgments age. Communities shift priorities. Government counterparts change. A conflict flare or a drought reshapes access. And the assumptions column, which most teams fill in quickly and rarely revisit, starts silently failing.

The trouble is that a logframe can look fine on paper while lying to you in the field. Outputs are being counted, indicator tracking sheets are being filled, quarterly reports are going out on time. But underneath, the causal chain is broken: your outputs are no longer producing the outcomes they were designed to produce, and nobody has formally named that yet.

A mid-term review is your last real intervention point before results are locked in. As EvalCommunity notes, an MTR provides stakeholders with the opportunity to "evaluate progress, assess challenges, and adjust strategies to ensure the project meets its objectives", and critically, to do this while course correction is still possible [3].

⚠️ Warning: If your mid-term review only measures output delivery rates against targets, you are measuring activity, not progress. You need to interrogate the logic connecting those outputs to intended outcomes.

Step 1: Audit Your Assumptions Column First

Most teams open the logframe at the mid-term and go straight to the indicators. I'd encourage you to start somewhere different: the assumptions column.

Assumptions are the conditions outside your control that your theory of change depends on. In the Enhanced IF Tier 2 guidance for project evaluations, one of the core purposes of the mid-term process is to surface whether the conditions under which the project was designed still hold [4]. If your assumptions have eroded, your outputs can be perfectly delivered and your outcomes can still fail.

Run through each assumption at every level of the matrix and ask three questions:

1. Is this assumption still valid? Has anything changed in the context that undermines it?
2. Was it ever realistic? Sometimes assumptions are written to satisfy the funder, not to reflect the actual operating environment.
3. What monitoring is in place for it? If the answer is "nothing formal," that is a gap to fix immediately.

Flag each assumption as: Holding / At Risk / Failed. This alone will tell you more about your project's trajectory than any output count.

Step 2: Stress-Test the Causal Logic, Level by Level

Once you have clarity on your assumptions, work your way up the results chain. The logframe's vertical logic claims that if activities are delivered, outputs will result; if outputs are achieved, the purpose-level outcome will follow; and if the outcome is achieved, it will contribute to the goal [2]. Stress-test each of those "if-then" links explicitly.

Here is a simple framework I find useful:

💡 Tip: Run this as a structured workshop with your field team, not just the MEL officer. Programme staff often hold tacit knowledge about broken causal links that never makes it into formal reporting.

Step 3: Revisit Indicators for Measurability and Relevance

A mid-term review is also the right moment to ask whether your indicators are still telling you what you need to know. Some indicators look good in a logframe but turn out to be too expensive to measure, too difficult to disaggregate, or simply not sensitive enough to capture real change at the pace of your project.

Look for indicators that:

• Have never produced data (no data = not being measured = not managing)
• Produce data but are never discussed in team review meetings
• Were set with targets that no longer reflect realistic ambition given what you now know
• Lack a clear means of verification in practice, even if one was written in the matrix

📝 Note: Revising indicators at the mid-term is not cheating, it is good MEL practice. What matters is that revisions are documented, justified, and approved by the relevant stakeholders, including your donor if contractually required.

Step 4: Structure the Mid-Term Review Process Properly

Running a rigorous logframe stress-test inside your mid-term review requires some process discipline. The EIF Guidance Note lays out a solid sequence [4]: define the evaluation questions and target audience first; then develop terms of reference; then engage an independent evaluator if required; then ensure proper stakeholder involvement throughout.

Even if your MTR is internal rather than externally commissioned, the sequencing matters. Too many mid-term reviews start with data collection and only frame the questions afterward, which means you find answers to questions nobody actually prioritized.

Here is a simplified process sequence I recommend:

1. Frame your key evaluation questions (What do we most need to know? What decisions hinge on the findings?)
2. Map the data you already have vs. what you need to collect
3. Conduct field-level triangulation (staff interviews, beneficiary FGDs, partner consultations)
4. Analyze the logframe row by row using the assumptions audit and causal logic stress-test above
5. Produce findings with a management response: not just what is wrong, but what you will do about it

💡 Tip: Build a simple assumption-monitoring tracker into your next work plan cycle. Even a shared spreadsheet reviewed monthly is infinitely better than leaving assumptions to chance until the final evaluation.

Step 5: Document the Revision, Not Just the Finding

This is the step most teams skip. They run a decent mid-term, identify the gaps, maybe adjust some activities, and then move on without formally updating the logframe itself. The original matrix stays in the files, unchanged, and the gap between what the logframe says and what the project is actually doing quietly widens again.

If the mid-term reveals that a causal link is broken, revise the logframe. If an assumption has failed, remove it or add a mitigation strategy. If an indicator needs to change, change it, document why, and update your IPTT accordingly. A logframe that reflects what you learned at the mid-term is more valuable to your final evaluation, your learning agenda, and your next project design than one that preserves a fiction.

The Datalab.Africa framing for practical logframe development captures this well: the framework is meant to be a working tool for your M&E journey, not a static document [5]. Treat it that way.

The Bigger Point

Your logframe is only lying to you if you let it. The matrix itself, when properly maintained and questioned, is one of the most useful project management instruments in development work. Six decades of donor practice built on it for good reason [2]. The failure mode is not the tool: it is the habit of treating the logframe as a deliverable to submit rather than a system to run.

A mid-term review is not a compliance checkpoint. It is your team's best opportunity to look honestly at the theory of change you bet your project on, test whether it is still holding, and make the adjustments that will determine whether your final evaluation tells a success story or a cautionary tale.

If you want help turning this process into a structured review template, a logframe revision worksheet, or a mid-term TOR for your next project, that is exactly the kind of work I can do with you at vera.ignex.io.

Sources are listed below. All citations refer to the numbered research sources used in this article.