Mid-term reviews · monival.org

What an MTR is for

Every programme instrument on this site answers a question. The mid-term review answers this one: knowing what we now know, should the second half of this programme be run the way the first half was?

That framing settles most of the design arguments before they start. The MTR is formative: it is conducted while the programme can still change course, and its value is measured entirely by the quality of the course corrections it produces. It is not a verdict on success — outcomes are usually not yet visible at midpoint, and pretending otherwise produces fake findings — and it is not the accountability moment; that weight is carried by terminal and summative evaluation at closure, deliberately, so that the MTR can be honest. A review team and a programme team who both understand that the MTR’s findings will not be used to punish are a review team and a programme team who can talk about what is actually going wrong [4, 5].

The best-institutionalised illustration is the GEF system, in which projects run a paired sequence: a mid-term review during implementation with a learning and course-correction mandate, and a terminal evaluation at completion, governed by formal guidelines and carrying the accountability weight [1, 2]. The pairing has a consequence worth internalising even outside the GEF world: the terminal evaluators will read the MTR — what it found, what it recommended, and what management did about it [3]. A programme that ignored its own mid-term findings will answer for that at closure. The MTR is therefore not a disposable interim exercise; it is the opening entry in the programme’s evaluative record.

The distinction between the two exercises, compressed:

Mid-term review versus terminal or summative evaluation
	Mid-term review	Terminal / summative evaluation
Primary purpose	Course correction	Accountability and learning for the next programme
Timing	Mid-implementation, while change is possible	At or after completion
Evidence available	Delivery and output data; early outcome signals at most	Full results data, endline measurement
Accountability weight	Deliberately low	High — findings are of record
Independence norm	Independent-minded; may be internal or hybrid	Independent, per evaluation policy
Product that matters	Management response and revised plan	Evaluation report and its use

Table 1. Same programme, different questions, different stakes. The MTR's independence bar is lower because its consequence is internal decision-making, not external judgment.

Timing: the calendar midpoint is a default, not a law

The reflex is to schedule the MTR at month 24 of 48. Two adjustments make the reflex intelligent.

Prefer the milestone midpoint to the calendar midpoint. A programme that spent a year in procurement and inception is not “half way” at the calendar midpoint in any sense that matters for review. Timing the MTR to implementation reality — roughly half the delivery accomplished, or the completion of the first full delivery cycle — reviews a programme that has actually generated evidence to review. Where a programme is badly delayed, that fact is itself the MTR’s first finding, and bringing the review forward is often right: the value of course correction is highest exactly when the course is most wrong.

Review what can be seen. At midpoint, most programmes can show delivery evidence (activities, spend, schedule position) and early output evidence; outcome evidence is usually thin to absent because results lag delivery — the through-line of this cluster’s interface page. The honest MTR states this plainly and reviews the things that are visible: whether outputs are appearing at the quality and rate the programme logic requires, whether the assumptions connecting outputs to outcomes still look credible, and whether the delivery machine can complete the plan. What an MTR must never do is dress the absence of outcome evidence as an outcome finding, in either direction [5].

Event triggers can also justify an off-cycle review with an MTR’s mandate: a major context shift, a leadership change, a budget rescope, or monitoring data crossing a pre-agreed threshold — the risk-register escalation path and the review calendar should know about each other.

Scope: the five-question core

MTR terms of reference bloat easily. The durable core is five questions; most additions are one of these in costume.

Progress against plan. What was promised by now, what has been delivered, and what explains the gaps? This question runs on the monitoring system and the delivery data — milestone achievement, indicator actuals against trajectory, burn rate. If the monitoring system cannot answer it, that is finding number one.
Continued relevance. Has the context — needs, government policy, other actors’ programmes — shifted enough that parts of the design now aim at the wrong target? Deeper treatment of evaluation criteria as such belongs to the evaluation literature and is not this page’s business; the MTR’s version of the question is narrow and practical: would we design it this way today, and if not, what changes now?
Delivery bottlenecks. Where does work queue, stall or fail — procurement, partner capacity, staffing, approvals? This is process-evaluation territory, and rapid process methods are the right tool [5].
Health of the programme logic. Are the causal assumptions connecting delivery to results still credible in the light of first-half evidence? This is a theory-of-change health check — reviewing whether the logic’s assumptions are holding, not re-teaching the artefact; for the theory of change itself see the explainer at monival.com.
Budget burn against results. Not cost-efficiency theatre — simply whether the spending pattern and the results pattern tell the same story, and what the mismatch (fast burn with slow delivery, or the reverse) implies for the second half. The earned-value page in this cluster covers the delivery-side analytics where the programme runs them.

Method: proportionate, monitoring-data-first

An MTR is a rapid exercise — typically weeks of evaluator time, not months — and its methods should be chosen by the proportionality logic that runs through good evaluation guidance: the effort spent answering a question should match the stakes of the decision it feeds [4, 5]. The practical sequence:

Exhaust existing data first. Monitoring data, routine reports, financial data, the risk register, previous reviews. A large fraction of MTR findings are already sitting in the programme’s own systems, unread across silo boundaries. An MTR that commissions a survey to learn what the HMIS already records has wasted its budget — and has told you something about the programme’s data use.
Rapid mixed methods for the gaps. Key-informant interviews across the delivery chain (not just headquarters), focus groups with participants, site visits structured by a checklist rather than itinerary convenience, and light analysis of administrative records. Triangulation discipline applies at MTR speed too: a claim that survives interviews, records and observation is a finding; a claim from one workshop is a hypothesis.
New primary data collection only on demonstrated need — a specific question, material to a second-half decision, answerable no other way. The default answer to “should the MTR run a mini-survey?” is no.

Team composition follows the same proportionality: full external independence is not the MTR norm the way it is for terminal evaluation [4]. A strong pattern is a small external lead (for fresh eyes and licence to say awkward things) working with internal M&E staff (for context and data access) — provided the ToR protects the lead’s right to report what they find.

The management response is the product

The pathology every MTR guideline warns against is the review that ends at the report. The report is an input. The product is the management response: a documented decision, per recommendation, to accept, partially accept or reject — with reasons — and, for accepted items, a named owner, a deadline and a follow-up mechanism. Agency evaluation systems make this mandatory for evaluative exercises, and tracking implementation of the response is part of the machinery, not a courtesy [4]. The reporting cluster’s page on use and management response covers the mechanics; three MTR-specific points belong here:

Re-planning is the point. Accepted recommendations should land in a revised work plan and budget for the second half — a real revision through the programme’s governance, not margin notes on the old plan.
Target revision needs governance, not guilt. Where the MTR shows targets were mis-set — baselines that turned out wrong, assumptions that failed — revising them is legitimate and often overdue. It must be done through an explicit, documented change process (the baselines-and-targets page sets out the discipline), never by quiet edits. An unexplained target change discovered at terminal evaluation reads as manipulation even when it was sense [2, 3].
Refresh the risk register. An MTR is the best risk-identification exercise most programmes will ever run: every bottleneck finding and every shaky assumption is a register candidate with an owner and a review date waiting to be assigned.

Figure 1. The MTR in the programme arc. At the midpoint lens, the review reads the first half's evidence and opens three paths for the second half — stay the course, adjust delivery, or restructure targets. Below, the document chain that makes the review real: monitoring data and the MTR report feed a management response, which feeds the revised plan the second half actually runs on.

Commissioning: the ToR skeleton and quality checks

A serviceable MTR terms of reference fits on a few pages and contains, in order: programme background and current status (one page, honest about delays); the review’s purpose and intended users — which decisions, taken by whom, the MTR will feed; the question set (the five-question core, tailored, and ruthlessly capped — every added question costs depth on the others); scope boundaries (period, geography, components); method expectations, including the monitoring-data-first instruction and any mandatory site or stakeholder coverage; team profile and independence arrangements; deliverables and dates, with the management-response step and its owner named in the ToR; and the budget. Two structural checks before signing it off:

The decision test. For each question, name the second-half decision its answer feeds. A question feeding no decision is dropped, however interesting.
The calendar test. The report must land before the re-planning and budget moment it is supposed to inform — evaluative work exists to feed decisions, not to follow them [5]. An MTR reporting three weeks after the annual work plan is approved has chosen decoration.

Quality assurance for the review itself borrows the standard evaluation report checks in proportionate form — evidence traceable to sources, findings distinguished from opinions, recommendations that are specific, addressed and feasible; the standards cluster’s page on evaluation quality assessment carries the fuller apparatus [4].

Checklist for an MTR that changes the second half

Timed to the milestone midpoint (or an event trigger), and early enough to feed the next planning and budget cycle.
Scope built on the five-question core, each question tied to a named second-half decision.
Method proportionate: existing monitoring data exhausted first; new primary collection only on demonstrated need.
No fake outcome findings: what cannot yet be seen is stated as not yet visible.
Management response with owners and deadlines; accepted recommendations landed in a governed plan and target revision.
Risk register refreshed from the findings — and the whole record filed where the terminal evaluators will look for it.