Theory of Change

When to Use

A theory of change is the right tool when you need to explain why your programme will work — not just what it will do. Use it when:

Designing a new programme — to ensure activities logically connect to intended outcomes before committing resources
Writing proposals — most donors (USAID, DFID, EU, Global Fund) now require an explicit theory of change as part of the design narrative
Selecting indicators — a well-built ToC tells you exactly what to measure at each level of the results chain
Conducting mid-term reviews — to test whether your causal assumptions still hold given implementation realities
Explaining programme logic to non-specialists — stakeholders, communities, and board members need a clear story about how change happens

A theory of change is less useful when you need a detailed operational plan (use a logframe for that) or when you're mapping emergent outcomes that weren't predicted in advance (use outcome harvesting or most significant change instead).

| Scenario | Use Theory of Change? | Better Alternative | |----------|----------------------|-------------------| | New programme design | Yes | — | | Operational planning with targets | Alongside | Logframe | | Tracking unpredicted outcomes | No | Outcome Harvesting | | Understanding causal attribution | Yes, as foundation | Contribution Analysis | | Complex adaptive programmes | Yes, but keep it living | Developmental Evaluation |

How It Works

Building a theory of change follows a structured process. The sequence matters — each stage builds on the previous one.

Analyse the context. Start with a thorough problem analysis: what is the situation, who is affected, what are the root causes, and what has already been tried? Map the stakeholders and assess their influence and interests. This stage prevents you from designing a programme that doesn't fit the reality on the ground.
Define the long-term change. Work backwards from the ultimate outcome you want to see. Be specific: "Improved maternal health outcomes in Karamoja sub-region" is actionable; "better health" is not. This becomes the top of your results chain.
Map the causal pathways. Identify the intermediate outcomes that must happen for the long-term change to occur. Ask "what has to be true for this to happen?" repeatedly until you reach the level of activities your programme can directly influence. This creates the causal chain: activities → outputs → intermediate outcomes → long-term outcomes → impact.
Make assumptions explicit. At every link in the chain, document what must be true for the causal connection to hold. "Training farmers leads to adoption of new techniques" assumes farmers have land access, input markets exist, and the techniques are appropriate for the agro-ecological zone. These assumptions become the most important things to monitor.
Identify the evidence base. For each causal link, assess how confident you are that the connection is real. Is there research evidence? Programme evidence from similar contexts? Or is it a hypothesis? Weak links in the chain are where your monitoring should focus.
Develop the visual. Create a diagram that shows the pathways, assumptions, and evidence ratings. Keep it readable — a theory of change that requires 30 minutes to explain has failed as a communication tool.
Test and revise. Treat the ToC as a living document. As implementation generates data, revisit your assumptions. Update the pathways when evidence shows your logic was wrong. This is where a ToC connects directly to adaptive management.

Key Components

A well-constructed theory of change includes these essential elements:

Problem statement — a clear, evidence-based description of the issue your programme addresses, grounded in context analysis rather than generic statements
Long-term outcome — the specific change you expect to see at the impact level, defined precisely enough to be measurable
Causal pathways — the logical chain from activities through outputs and intermediate outcomes to the long-term outcome, showing how change happens sequentially
Assumptions — the conditions that must hold true at each link in the chain, stated explicitly rather than left implicit in the design
Evidence ratings — an honest assessment of how strong the evidence is for each causal link (strong research base, programme evidence, or untested hypothesis)
External factors — contextual conditions outside programme control that could influence outcomes (political stability, market conditions, climate)
Indicators — at minimum, markers for each level of the results chain that tell you whether the expected change is occurring
Narrative — a written explanation that accompanies the visual, explaining the logic in plain language for stakeholders who won't interpret a diagram alone

Best Practices

Treat it as both a product and a process. A theory of change is not a one-time exercise completed during proposal writing and filed away. It is a living analytical tool that should be revisited as implementation generates new evidence. Schedule formal ToC review points at least annually, and after any significant context change. (MEAL Rule: EX45_R011)

Ground the design in rigorous context analysis. Strong theories of change are built on thorough context analysis, appropriate knowledge sources, specificity in defining impact pathways, and realism about what a single programme can achieve. Don't design the ToC in a headquarters office — involve field staff and community stakeholders who understand the local reality. (MEAL Rule: EX45_S004)

Follow a staged development process. Develop your theory of change in four stages: (1) analysing the context, (2) defining the results chain, (3) making assumptions and evidence explicit, and (4) selecting indicators and monitoring approaches. Skipping stages — particularly the context analysis — produces theories that sound logical but don't reflect reality. (MEAL Rule: EX45_R001)

Ensure feasibility. Test whether your theory of change is feasible by checking that selected outcomes and purposes are achievable given available resources, timeframe, and organizational capacity. Ambitious theories of change that exceed programme capacity create unrealistic expectations and set up evaluations for negative findings. (MEAL Rule: EX132_F3_R009)

Use the ToC to drive monitoring. Collect and analyse data on key indicators as a means of monitoring progress along the theory of change pathways. Your monitoring framework should map directly to the ToC — if an assumption or causal link isn't being monitored, you won't know when it fails. (MEAL Rule: EX134_R206)

Keep it a living document. Revisit and test your logic models throughout the life of the project to ensure they remain accurate. Update them when assumptions prove wrong, when context shifts, or when implementation reveals unintended pathways. A static ToC is a wasted investment. (MEAL Rule: EX081_P016)

Common Mistakes

Building the ToC after the programme is designed. The most common failure is treating the theory of change as a retrospective justification for activities already decided, rather than a design tool that shapes which activities to include. When the ToC is written to match pre-determined activities, it cannot serve its purpose of testing causal logic.

Confusing the ToC with a logframe. A logframe is an operational management tool (activities, indicators, targets, timelines). A theory of change explains why those activities should produce results. Converting a ToC into a logframe is a valid step, but they serve different purposes and one cannot replace the other. (MEAL Rule: EX59_R002)

Leaving assumptions implicit. Many theories of change map a clean pathway from activities to outcomes without documenting the conditions that must hold true at each link. "Training leads to behaviour change" is only true if participants have the resources, motivation, and enabling environment to apply what they learned. Unexamined assumptions are the most common source of programme failure.

Making it too complex to communicate. A theory of change diagram with 47 boxes and 83 arrows may be technically comprehensive, but if field staff and community partners cannot explain the programme logic, it isn't functioning as a communication or management tool. Aim for a version that can be explained in 5 minutes.

Never revisiting it. Treating the ToC as a static document created at design stage and never updated is the second most common failure. Programmes operate in dynamic contexts — political changes, market shifts, climate events, and implementation lessons all invalidate original assumptions. A ToC that isn't updated isn't being used. (MEAL Rule: EX45_R007)

Examples

Agricultural Livelihoods — East Africa

A 5-year agricultural resilience programme in Kenya and Uganda developed a theory of change mapping the pathway from farmer training through adoption of drought-resistant varieties to improved food security and income. The key innovation was making the assumption "farmers will adopt new varieties" explicit and identifying three conditions that had to hold: seed availability, extension service capacity, and favourable land tenure arrangements. When mid-term monitoring revealed land tenure was the binding constraint (not seed availability as expected), the programme redirected resources accordingly. The ToC functioned as a diagnostic tool, not just a design artefact.

WASH — South Asia

A water and sanitation programme in Bangladesh mapped two parallel pathways in its theory of change: (1) infrastructure construction → access to safe water → reduced waterborne disease, and (2) behaviour change communication → improved hygiene practices → reduced waterborne disease. By modelling these as separate but converging pathways, the monitoring system could identify which pathway was contributing more to health outcomes. The evaluation found that the behaviour change pathway was responsible for 60% of the health improvements — a finding that would have been invisible without the dual-pathway ToC design.

Governance — West Africa

A governance programme in Sierra Leone initially designed a linear ToC: training civil society organizations → increased advocacy → policy change. After the first year, outcome harvesting revealed an unplanned pathway: trained CSOs were influencing local government through informal relationships rather than formal advocacy. The programme revised its ToC to include this emergent pathway and adjusted its indicators to capture informal influence — demonstrating that ToC revision is not a sign of failure but of learning.

Compared To

A theory of change is one of several frameworks used in programme design and evaluation. The key differences:

| Feature | Theory of Change | Logframe | Results Framework | Outcome Mapping | |---------|-----------------|------------------------------------------|-----------------------------------------------------------|--------------------------------------------------------| | Primary purpose | Explain why change happens | Manage implementation | Track results across portfolio | Map behaviour changes in boundary partners | | Level of detail | Strategic causal logic | Operational targets & activities | Aggregated indicators | Detailed behaviour markers | | Assumptions | Central feature | Listed but often ignored | Not typically included | Embedded in progress markers | | Best for | Design, evaluation, learning | Planning, reporting | Portfolio oversight | Complex, relationship-based programmes | | Flexibility | Designed to evolve | Relatively fixed | Fixed structure | Designed to evolve |

Relevant Indicators

47 indicators across 4 major donor frameworks (USAID, DFID, UNDP, Global Fund) relate to theory of change design and use:

Programme design quality — "Proportion of programme proposals with articulated and evidence-based theories of change" (USAID)
Assumption testing — "Number of theory of change assumptions tested through routine monitoring data" (DFID)
ToC revision frequency — "Frequency of theory of change review and update during programme implementation" (UNDP)
Stakeholder validation — "Percentage of programme stakeholders who can describe the programme's intended causal pathway" (Global Fund)

Related Tools

Logic Model Builder — Interactive tool for constructing visual theories of change with drag-and-drop pathway mapping
ToC Template — Guided template for developing a narrative theory of change with assumption documentation