Stephen T’s Blog Spot

Almost every federal program and grant proposal asks for a logic model or theory of change. And most of the time, one gets drawn, made to look tidy, approved, and never opened again. It becomes paperwork, a diagram that satisfied a reviewer. That is a waste, because used as intended, a theory of change is the most useful analytic tool in evaluation. The trick is to stop treating it as a picture and start treating it as a hypothesis.

First, what it is. A theory of change maps the causal chain of a program: the inputs and activities, what you put in and do; the outputs, what those activities produce; and the outcomes you expect to follow, in the short, intermediate, and long term. A logic model is the schematic version, a sequence of if-then steps; a theory of change goes further, spelling out the mechanism and why each link should hold. In both, the meaning lives in the arrows, not the boxes: the arrows are claims that doing this will cause that.

And that is the reframe. A theory of change is a falsifiable hypothesis about how change happens. Every arrow is an assertion that could turn out to be false. Its worth is not that it looks complete or comprehensive. Its worth is that it is explicit enough to be wrong, and therefore explicit enough to test. Evaluation researchers have even argued for building a deliberately falsifiable logic model, with measurable benchmarks at each intermediate step. A theory of change you could never disprove is not a theory. It is decoration.

Here is where it pays off, and it is the heart of the matter. Suppose the final outcome does not move. With only a before-and-after number, that is a dead end: it did not work, and you cannot say why. But with an explicit theory of change, a disappointing result splits into two very different diagnoses. The first is implementation failure: you never actually delivered the activities, or they did not produce the intended outputs, so the theory was never really tested. The second is theory failure: you delivered everything as planned, the outputs appeared, and the expected change still did not follow, which means a causal assumption was simply wrong.

This distinction, which goes back to Edward Suchman and Carol Weiss in the field’s foundations, matters because the two failures demand opposite responses. Implementation failure says the idea may be fine, fix the delivery. Theory failure says the delivery was fine, rethink the idea. Confuse them and you will scrap a sound program for being poorly run, or pour resources into faithfully delivering something that was never going to work. Without a theory of change you cannot tell them apart; with one, a null result becomes a map of where the program broke.

The most valuable parts of the model are the assumptions hiding between the boxes. If we train the staff, they will use the training. If clients show up, their behavior will change. If the report is delivered, someone will act on it. Those unstated links are where programs quietly die, and the discipline of a theory of change is dragging them into the open where they can be examined and measured.

A caution: a clean diagram can mislead as easily as it clarifies. It can imply a tidy, linear world when reality has feedback loops, context, and surprises, and it can lend false confidence just by looking organized. The model is a hypothesis to hold loosely and revise as evidence arrives, not a promise to defend.

So build it as a working tool, not a grant ornament. Let it tell you what to measure, the intermediate links and not only the final outcome, and let it commit you in advance to what success and failure would look like.

So here is my question: When a program underdelivers, how do you tell implementation failure from theory failure, and does your logic model actually let you measure the steps in between?