Definition

A theory of change is an explicit model of how and why a desired change is expected to happen in a particular context. It is built by working backwards from the long-term outcome to the preconditions that must be in place for that outcome to occur, and then to the preconditions for those, until the chain reaches something the intervention can actually do.

Three things distinguish it from a plan:

1. It is causal, not sequential. Each link asserts that one thing brings about another, and is expected to say why.
2. It makes assumptions explicit. The beliefs connecting each precondition to the next — about context, about how people behave, about what other actors will do — are written down and are open to challenge.
3. It is falsifiable in principle. A theory of change that could not turn out to be wrong is not a theory.

The full articulation usually has four parts: an outcomes pathway (the map of preconditions), the assumptions attached to each link, indicators for the outcomes on the pathway, and a narrative that explains the logic in prose for readers who will not decode a diagram.

Origin

The approach emerged in the 1990s out of evaluation practice at the Aspen Institute’s Roundtable on Comprehensive Community Initiatives, which was grappling with how to evaluate complex, multi-strand community programmes that a conventional experimental design could not handle. Carol Weiss gave the idea its influential statement in 1995, arguing that these initiatives failed to be evaluable because the theories underlying them were never made explicit — so nobody could say which link in the chain had broken.

That origin matters for how it should be used. Theory of change was invented as an evaluability device, to make complex programmes assessable. It was not invented as a fundraising graphic.

Backwards mapping in practice

The order of the work is the method, and doing it forwards produces something else entirely.

1. Agree the long-term outcome. One statement, specific about who changes and how. “Improved livelihoods” is not an outcome; it is a category.
2. Ask what must be true immediately beforehand. These are the preconditions — necessary conditions, not activities. Keep asking of each precondition: what must be in place for this to occur?
3. Continue until you reach preconditions the intervention can influence directly. That boundary is important: everything below it is your work, everything above it depends on others.
4. Surface the assumptions on each link. Why should this precondition produce the next one? What has to be true about the context, the actors, the timing?
5. Identify the ceiling of accountability. The point on the pathway above which you contribute but cannot be held responsible. Naming it protects both you and the funder.
6. Write the narrative. If the logic cannot be stated in a few clear paragraphs, the diagram is hiding a gap rather than expressing a theory.

Who asks for one

• FCDO — a theory of change is a standard component of a UK business case, and the quality of it is assessed.
• Bill & Melinda Gates Foundation — expected in investment documentation.
• Comic Relief — requires applicants to articulate a theory of change.
• Ford Foundation and the William and Flora Hewlett Foundation — both use theory of change as a core strategy instrument, and Hewlett has published extensively on its own practice.
• Global Affairs Canada (GAC) — theory of change accompanies its results-based management documentation.

The pattern is that foundations and bilateral strategy processes want the theory of change, while institutional grant compliance wants the logframe. Most organisations working across both need both, which is exactly why they should be built in the right order.

Artefacts it produces

• The outcomes pathway diagram.
• An assumptions register, link by link — the most useful and least maintained artefact of the set.
• A narrative document explaining the pathway.
• Outcome indicators at the pathway levels, which frequently become the outcome rows of the project logframe.
• Optionally, an explicit statement of rival explanations — other reasons the outcome might occur — which is what makes the eventual evaluation contribution-capable.

How it relates to the other frameworks

• The logframe is the compression. A theory of change explains the mechanism; the logframe summarises the accountable slice of it in a submittable format. Build the theory first, derive the logframe from it, and the logframe’s assumptions column stops being an afterthought.
• The results framework is structurally similar but institutional in scope and hierarchical rather than causal — it organises objectives, where a theory of change explains them.
• Outcome harvesting starts from the opposite end: it observes what changed and works back to whether the intervention contributed. It is the natural companion when the pathway is genuinely unpredictable, and the two are often used together — theory of change to frame, outcome harvesting to find out what actually happened.
• The OECD-DAC criteria interrogate a theory of change at evaluation: relevance tests whether the long-term outcome was the right one, effectiveness tests whether the pathway delivered.

Common mistakes

1. Drawing a logframe with arrows on it. If the boxes are your outputs and activities in a slightly nicer layout, you have produced a diagram, not a theory. The test: does any box represent something other people must do, or something about the world that must be true? If not, it is a workplan.
2. Assumptions written as risks. “Risk: government does not adopt the policy” belongs in a risk register. The assumption is the positive claim you are relying on — “we assume the technical working group has enough standing that its recommendation reaches the cabinet” — and it should be specific enough to monitor.
3. Building it forwards. Starting from activities and asking “what will this achieve?” produces a chain that justifies the work you already planned. Backwards mapping frequently reveals that a planned activity contributes to nothing on the pathway, which is the point.
4. Confusing necessary with sufficient. A precondition can be genuinely required and still not enough on its own. Pathways that treat every link as sufficient are the ones that fail quietly.
5. Building it once. A theory of change that has not been revised after two years of implementation has not been used. Revision under a documented process is evidence of learning, not of poor design.
6. Building it in a workshop of staff only. The people whose behaviour the theory predicts are the best available reviewers of whether it is plausible.
7. Treating it as a communications asset. The one-page graphic is a by-product. The value is in the assumptions and the narrative, which is exactly what gets cut when the diagram goes to the design team.

How Monival supports this

Direct and important: Monival does not currently ship a theory of change builder. The framework switcher in the results module lists theory of change alongside logic model, outcome mapping and results framework, and those views are not yet enabled. The only framework view live in the product today is the grouped logframe matrix. Anyone claiming otherwise about our product is wrong, and we would rather say so than have you discover it in a trial.

What the product does carry is the substrate a theory of change eventually resolves into: result nodes at impact, outcome, output and activity level, each with its own assumptions list, and indicators with baselines, targets, means of verification and collection frequency. When you convert a pathway into an accountable logframe, that is where it lands, and the assumptions travel with it rather than being lost in the compression.

Facilitating the theory of change itself — the backwards mapping, the assumption elicitation, the stakeholder sessions — is delivered by Sibasi as consulting, not as a feature. Where an organisation wants the pathway rendered and tracked as a system, we build it as an implemented solution on Microsoft Power Platform, which is an established Sibasi delivery mode with live client references. It is a project, not a plan upgrade, and we will scope it as one.