Writing a Logic Model That Survives a Real Budget

Most Logic Models are written in the wrong order. A team drafts the outcomes a funder wants to see, works backward to outputs that would plausibly produce them, and only then checks whether the activities implied by those outputs fit inside the budget that was actually approved. By the time anyone runs that check, the document has already been submitted, and the gap between what was promised and what the budget can fund becomes someone else's problem to solve mid-delivery.

What a Logic Model actually has to do

A Logic Model connects five things: the inputs a program has to work with, the activities those inputs pay for, the outputs those activities produce, the outcomes those outputs are expected to cause, and the longer-term impact the outcomes are meant to add up to. The OECD-DAC criteria of relevance and effectiveness sit underneath that chain: relevance asks whether the activities address the right problem, effectiveness asks whether they are likely to produce the outcomes claimed.

The part most drafts skip is the assumption sitting between each link. An output does not become an outcome automatically. It becomes one if a stated assumption holds, for example that the target population can access the service, or that a partner organization delivers its side of a referral pathway on schedule. A Logic Model that states its assumptions can be tested later. One that doesn't just becomes a set of claims nobody can evaluate against reality.

Where they usually break

Three failure patterns show up repeatedly. The first is activities sized to an aspirational budget rather than the one that was actually approved, so the plan requires a second funding round that was never guaranteed. The second is outcomes claimed that the stated activities cannot plausibly produce, often because the outcome language was pulled from the funder's strategic priorities rather than derived from the program's own theory of change. The third is a chain with no stated assumptions at all, which means an evaluator arriving eighteen months later has no way to tell whether a disappointing outcome reflects a bad theory or a broken assumption.

What holds up

A Logic Model that survives implementation is built against the real budget from the start, not adjusted to fit it afterward. It states its assumptions in plain language, so the monitoring plan can track whether they held. And it stays short enough that a program officer could redraw the core chain from memory without the original document in front of them. Complexity that has to live in a slide deck to be understood is complexity the delivery team will not carry consistently into the field.

The test we apply before a design goes to a funder is simple: could the person running the program in year two explain, without notes, why activity A is expected to produce outcome B. If the answer requires reopening the proposal document, the logic has not been internalized, and it will not hold up once the program hits its first real obstacle.