Theory of Change Diagram: How to Map a Clear Pathway to Impact

A theory of change diagram is the most common way organisations present project logic. It shows — visually — how activities connect to outcomes, and how outcomes contribute to impact.

It is also one of the most commonly misused tools in NGO project design.

The problem is not the diagram itself. It is what the diagram is asked to do. Most theory of change diagrams are designed to communicate. They are not designed to test.

When a diagram is used to communicate — to present project logic to a funder, board, or stakeholder — it can afford to be simplified. Arrows are drawn. Boxes are connected. The pathway looks clear.

But when a diagram is used to test whether the project logic actually holds, a different standard applies. The arrows must represent genuine causal claims. The boxes must represent distinct, measurable conditions. The pathway must make sense if read critically by someone who does not already believe in the project.

This guide explains what a theory of change diagram is, what distinguishes a functional diagram from a presentational one, how to map the pathway correctly, and what the most common structural failures look like — so they can be avoided before submission.

What This Guide Covers

• What a theory of change diagram is and what it is intended to show
• The difference between a diagram that communicates and one that holds up under scrutiny
• Core elements every diagram must include
• Common mapping errors and how to identify them
• Step-by-step guidance for building a coherent pathway diagram
• How the diagram connects to the logframe and M&E framework
• Examples across different project types

To build a theory of change and generate a structured pathway from your project design:

What Is a Theory of Change Diagram?

A theory of change diagram is a visual representation of the causal logic of a project — showing how inputs and activities lead through outputs and outcomes to long-term impact.

It differs from a flowchart or project timeline because it represents causal claims, not process steps. Each connection in the diagram asserts that one condition leads to another — and that claim can be evaluated for plausibility.

The diagram is typically presented as a horizontal or vertical flow:

Activities → Outputs → Outcomes → Impact

With assumptions shown alongside each transition:

Activities → [Assumption A] → Outputs → [Assumption B] → Outcomes → [Assumption C] → Impact

In more complex projects, multiple output streams may converge into a single outcome, or a primary outcome may lead to secondary outcomes before reaching impact level.

What the Diagram Shows (and Does Not Show)

A theory of change diagram shows:

• The results chain from activity to impact
• The causal connections between levels
• The assumptions required at each transition
• The scope of change the project is claiming

A theory of change diagram does not show:

• Operational detail (timelines, budgets, staff)
• How indicators will be measured (that belongs in the M&E plan)
• Every activity (only those relevant to the causal chain)
• Internal processes

The diagram is a strategic map of causal logic. It should be readable in under a minute. The narrative beneath it provides the explanation.

Key Insight: A theory of change diagram that requires three minutes to follow has not clarified the logic. It has illustrated the confusion.

Core Elements of a Theory of Change Diagram

A complete theory of change diagram includes six elements. Each has a specific function.

1. Problem Statement

The starting point of the diagram. What problem does the project address? Why does it exist?

The problem statement is typically shown to the left of the causal chain (or at the top of a vertical diagram). It anchors the entire pathway: without a clear problem, the rationale for activities is unclear.

A weak problem statement: "Environmental degradation is a growing challenge."

A strong problem statement: "Mangrove cover in coastal zones X and Y has declined by 40% over 15 years, reducing shoreline protection and biodiversity. Restoration is not occurring due to lack of technical capacity and funding."

The stronger version is specific, evidenced, and directly connected to the project's proposed response.

2. Inputs

Resources required to deliver the project: funding, staff, partnerships, expertise, equipment.

Inputs are sometimes shown explicitly in diagrams for donor accountability, but they are not the causal core of the theory. Many diagrams omit them or summarise them as a single box.

3. Activities

The actions the project takes. These should be summarised at the level of strategic themes rather than operational tasks.

Strong activity description: "Deliver participatory training in coastal restoration techniques to community groups" Weak activity description: "Hold workshops" (too vague to be tested)

Each activity should connect to a specific output. If an activity does not connect to any output in the diagram, it should not be in the theory of change.

4. Outputs

The direct, tangible results of activities. Outputs are fully within the project's control.

In the diagram, outputs should be distinct from activities (they describe what is produced, not what is done) and distinct from outcomes (they describe delivery, not change).

Standard output framing: "[Number] of [target group] [trained/equipped/connected/produced]"

5. Outcomes

The changes that occur because of the outputs. This is where most theory of change diagrams fail.

Outcomes must describe observable changes in the behaviour, condition, knowledge, or practice of people or systems — not the delivery of services.

Strong outcome: "Community members apply coastal restoration techniques on 50 ha of degraded shoreline" Weak outcome: "Community members receive training in coastal restoration" (this is an output)

Outcomes may be short-term, medium-term, or long-term depending on the project timeline.

6. Impact

The long-term contribution the project makes to broader change. The project cannot achieve impact alone — it contributes to it alongside other factors and over a longer time horizon.

Impact should be:

• Described at a level above what the project can directly claim
• Plausibly connected to the outcomes
• Relevant to the funder's strategic objectives

7. Assumptions

Assumptions are the conditions that must be true for each causal transition to hold.

Every arrow in a theory of change diagram represents an assumption: that under defined conditions, outputs will lead to outcomes, and outcomes will lead to impact.

Assumptions should be shown in the diagram — either embedded in the arrow labels or listed alongside each transition. They should not be relegated to a footnote.

Why assumptions matter in the diagram:

If an assumption is unstated, it cannot be monitored. If it cannot be monitored, when it fails, the project does not respond. Assumptions visible in the diagram are assumptions that the project team must actively watch.

Common Mapping Errors in Theory of Change Diagrams

Error 1: Combining Activities and Outputs in the Same Box

When activities and outputs appear in the same box — or are not clearly differentiated — the diagram shows what the project does but not what it produces.

This conflation is common and immediately signals underdeveloped logic.

Incorrect: Activities → Outcomes (skipping outputs) Correct: Activities → Outputs → Outcomes

Error 2: Assuming Arrows Represent Causation

In many diagrams, arrows are drawn to show sequence or connection — not causation.

The arrow from "training delivered" to "farmers change practices" only represents a causal claim if there is a mechanism that makes it plausible. What is it about this training — its content, its method, its follow-up support, the economic incentive — that causes behaviour change?

If the arrow cannot be explained with a sentence beginning "because...", it is not a causal claim. It is an optimistic assumption.

Error 3: Outcomes That Are Still Outputs

The most common single error in theory of change diagrams.

Test every element labelled "Outcome" with this question: Does this describe something the project delivers, or something that changes in the world as a result of what the project delivers?

Compare with genuine outcomes:

• "3,000 practitioners apply evidence from published research in their work"
• "Parliamentary committee incorporates NGO recommendations into policy draft"
• "200 women demonstrate competency in improved agricultural techniques"
• "Community leaders take protective action when flood warnings are issued"

Error 4: Diagrams That Are Too Complex

A theory of change diagram should be understood at a glance. When a diagram requires extensive explanation — when every box needs a footnote and every arrow has a qualifier — the logic has not been clarified. It has been hidden in complexity.

Common signs of over-complexity:

• More than 4–5 levels in the causal chain
• More than 5–6 outputs feeding into a single outcome
• Multiple impact-level boxes
• Arrows going in both directions (feedback loops should be in the narrative, not the core chain)

Key Insight: Complexity in a theory of change diagram usually means complexity in the thinking. The solution is not a bigger diagram. It is clearer thinking.

Error 5: Diagram Inconsistent with the Logframe

If the theory of change shows one causal pathway and the logframe presents a different outcome or indicator structure, evaluators will flag the inconsistency immediately.

The diagram and the logframe must describe the same project. The same outcome appears in both. The same outputs are listed in both. The assumptions in the diagram match the assumptions column of the logframe.

How to Map a Theory of Change Diagram: Step by Step

Step 1: Start With the Impact

What broader change does this project contribute to? Write it in a single sentence. It should describe a condition in the world, not a project achievement.

Examples:

• "Improved resilience of smallholder farming systems to climate variability"
• "Recovery of freshwater biodiversity in the target catchment"
• "Increased capacity of national regulators to enforce environmental standards"

Step 2: Define the Outcome(s)

What specific, measurable change will the project directly produce? This is what the project is accountable for.

The outcome should be:

• Observable within the project period
• Attributable to the project's activities
• One level more specific than the impact

For every outcome, ask: Who changes? What changes? By how much? By when?

Step 3: Map the Outputs

What does the project need to deliver for the outcome to occur? List each output separately.

Test each output by asking: If we delivered this output but the outcome did not occur, what went wrong?

That question identifies the mechanism — and the assumption.

Step 4: Connect Activities to Outputs

What activities produce each output? Each activity should connect to at least one specific output.

Activities without a connected output are either:

• Missing an output that should be on the diagram
• Activities that should not be in the project

Step 5: Insert Assumptions at Each Transition

For each arrow in the diagram — activity to output, output to outcome, outcome to impact — identify the condition that must hold for the connection to be valid.

Frame assumptions as: "This step works if/provided that..."

Examples:

• Activity → Output: "Provided that training materials are appropriate for local literacy levels"
• Output → Outcome: "If demonstration plots produce visible results that are economically replicable"
• Outcome → Impact: "If other actors in the system also adopt improved practices at scale"

Step 6: Review the Complete Pathway

Read the completed diagram as a story: We do X, which produces Y, which leads to Z, provided that A, B, and C hold, ultimately contributing to Q.

If the story does not flow — if any step requires a large leap of faith — revise that step.

Theory of Change Diagram: Format Options

There is no single correct format for a theory of change diagram. Different organisations use different visual conventions. The most commonly used formats:

Linear Flow Format (Horizontal)

[Problem] → [Activities] → [Outputs] → [Outcome] → [Impact]
                              ↑
                         [Assumptions]

Best for simple, single-pathway projects with one primary outcome.

Logic Model Format

Inputs → Activities → Outputs → Outcomes (Short-term) → Outcomes (Long-term) → Impact

Best for projects with distinct short-term and long-term outcome levels.

Convergence Format

Activity Stream 1 → Output 1 ↘
                              → [Outcome] → [Impact]
Activity Stream 2 → Output 2 ↗

Best for projects where multiple delivery streams contribute to a single outcome.

Divergence Format

[Output] → Outcome 1 → Impact 1
         ↘ Outcome 2 → Impact 2

Best for projects with a single primary output that produces multiple distinct outcomes.

In all formats, assumptions should appear — either inline or in a dedicated column.

Theory of Change Diagram and the Logframe

The theory of change diagram and the logframe serve different functions but must describe the same project logic.

The sequence typically runs:

1. Build the theory of change diagram (test the logic)
2. Develop the logframe (operationalise the logic)
3. Build the M&E framework (track the logic in implementation)

When the diagram changes — when outcomes are revised, assumptions are updated, or outputs are restructured — the logframe must be updated to match.

What EU Funders Assess in Theory of Change Diagrams

EU funding programmes increasingly require a theory of change at the proposal stage. For LIFE and Horizon Europe, the pathway to impact must be clearly articulated.

What evaluators look for:

• A traceable causal chain from activities to impact
• Outcomes that are specific and measurable (not vague aspirations)
• Assumptions that are acknowledged and monitored
• Consistency between the diagram and the logframe / performance indicators

Common reasons for low scores on theory of change sections:

• Outcomes described as outputs (delivery instead of change)
• Assumptions omitted or listed as generic statements
• Impact described at the level of the project rather than the broader system
• Diagram inconsistent with the results framework or indicators

Key Insight: In EU proposals, the theory of change diagram is not a communication tool — it is an evaluation criterion. It must hold up under scrutiny, not just look clear.

Building Your Theory of Change Diagram

The diagram is the product of clear thinking. It does not create clarity — it reveals whether clarity already exists.

The best approach:

1. Draft the pathway in plain language first: "We will do X, which will produce Y, which will change Z, leading to Q, provided that A and B hold."
2. Once that sentence is clear and defensible, translate it into the diagram.
3. Test the diagram against the questions: Is every arrow a genuine causal claim? Are all outputs genuinely different from outcomes? Are assumptions named and monitorable?
4. Align the diagram with the logframe.

Build a theory of change diagram where every element has a clear function, every connection is causally grounded, and every assumption is explicitly named and tracked.

Related pages: Theory of change template · Theory of change example · Theory of change for NGOs · Logframe template

Theory of Change Diagram: Frequently Asked Questions

What software do NGOs use to create theory of change diagrams?

Common tools include:

• Miro — collaborative online whiteboard, good for team-built ToC development
• Lucidchart / Mermaid — structured diagram tools
• Microsoft PowerPoint or Google Slides — widely available, sufficient for standard linear diagrams
• Draw.io (diagrams.net) — free browser-based diagramming
• Canva — good for communication-quality output

For proposals, the format matters less than the logical quality. A clear diagram built in PowerPoint is more valuable than a visually polished one that misrepresents the causal chain.

How many boxes should a theory of change diagram have?

There is no universal rule, but a practical guide: if the diagram takes more than two minutes to understand, it probably has too many boxes. Most project-level theories of change can be represented in 8–15 boxes. More than 20 boxes in a single diagram typically signals either an overly broad project scope or insufficient simplification.

Should the diagram show feedback loops?

For complex systems interventions, feedback loops may be relevant — for example, when improved community livelihoods (outcome) increase community investment in conservation (feeding back to an earlier output). However, feedback loops significantly increase diagram complexity. For most NGO proposals, reserve them for the narrative description, not the core diagram. Evaluators reading quickly will not easily follow bidirectional arrows.

Does the theory of change diagram need to include all project activities?

No. The diagram should show strategic-level activities — broad categories of work — not operational tasks. If there are six training sessions planned, the diagram should show "training in X practice" as a single activity box, not six boxes. The workplan contains operational detail; the diagram contains causal logic.

From Diagram to Implementation: Keeping the Theory of Change Live

A theory of change diagram built at the proposal stage should not be filed away after submission.

During implementation, it serves three practical functions:

1. Decision-making anchor

When the team faces a decision about whether to add, remove, or modify an activity, the theory of change provides the reference point: does this proposed change affect the causal chain? If an activity is being removed, which output does it support, and is there an alternative route to that output?

2. Risk signal

When an assumption is being tested — when community participation is lower than expected, or a policy window closes — the diagram shows immediately where the pathway is affected. This allows adaptive management decisions to be made before the problem compounds.

3. Communication tool

The diagram provides a consistent reference point for communicating with partners, funders, and stakeholders about the project's purpose. Over a three-to-five-year project, staff changes, and new partners need to understand the project's logic quickly. A clear diagram enables this.

Theory of Change Diagram: Alignment With Reporting

At reporting time, the theory of change diagram provides the structure for explaining progress:

• What outputs were achieved this period?
• What outcomes is the project on track to achieve?
• Have any assumptions changed that affect the pathway?
• What adaptive management actions were taken?

When the reporting structure mirrors the theory of change diagram, both the project team and the funder can assess whether the project is on the path it intended from the start.