Many South African NPOs create a Theory of Change for a funding proposal, strategic plan, evaluation process or board workshop. The problem is that the diagram often gets filed away once the document is approved.
It does not always shape the data the team collects, the indicators they track, the assumptions they test, or the evidence they use in reports.
A Theory of Change should not be a decorative strategy diagram. It should help an organisation explain how its activities are expected to contribute to change, what needs to be monitored, what evidence should be collected, and how progress should be reported.
This guide explains how South African NPOs, donor-funded teams, programme managers and implementation partners can build a Theory of Change that is practical enough to use in programme design, evidence review, monitoring, evaluation, learning and funder reporting.
Quick answer
Many South African NPOs create a Theory of Change for a funding proposal, strategic plan, evaluation process or board workshop.
Who this guide is for
South African NPOs, donor-funded teams, programme managers and implementation partners that need a Theory of Change linked to evidence and reporting
What a Theory of Change actually does
A Theory of Change explains how and why a programme is expected to contribute to change.
It should answer practical questions:
- What problem are we trying to address?
- What long-term change are we working towards?
- What outcomes need to happen first?
- What activities or interventions are meant to support those outcomes?
- What assumptions need to hold true?
- What evidence will show whether the pathway is working?
The World Health Organization describes a Theory of Change as a systematic and visual representation of how a programme or intervention is expected to achieve its intended outcomes. WHO’s technical guidance also says ToCs can support intervention design, implementation, monitoring and evaluation, transparency, policy transfer, scaling and institutional strategy. (World Health Organization)
A good Theory of Change does not prove impact by itself. It gives the team a testable logic for what should be monitored, reviewed and improved.
Why many Theories of Change fail in practice
Many Theories of Change fail because they are treated as proposal documents instead of working systems.
The workshop happens. The diagram is approved. The final version goes into a proposal, strategy pack or board document. Then the programme starts running, and the ToC sits separately from the tools the team uses every week.
Common problems include:
- the ToC is created once and never used again
- outcomes are vague
- assumptions are not tested
- indicators are added later as an afterthought
- programme data is not linked to the outcome pathway
- funder reports do not map back to the ToC
- qualitative evidence is not coded against outcome areas
- the team cannot explain which evidence supports which claim
- the ToC is too complicated for staff to use
- no one owns updates, version control or learning loops
The ToC is not the system. The system is what happens after the ToC is built.
For a Theory of Change to be useful, it needs to connect to indicators, data collection, source records, qualitative evidence, reporting templates and review routines. Without that, the organisation may have a strong diagram but a weak evidence base.
Theory of Change vs logic model
A Theory of Change and a logic model are closely related, but they do different jobs.
Theory of Change
A Theory of Change explains the why and how.
It shows:
- the problem
- long-term change
- outcomes or preconditions
- causal links
- assumptions
- risks
- evidence gaps
- context
- change mechanisms
It is most useful when the team needs to understand the thinking behind the programme, test whether the logic still holds, and explain why certain activities are expected to lead to certain outcomes.
Logic model
A logic model explains the what.
It usually follows a simpler chain:
Inputs → Activities → Outputs → Outcomes → Impact
A logic model helps the team organise delivery and reporting. It is useful for showing what resources go into the programme, what activities are delivered, what outputs are produced, and what outcomes are expected.
| Question | Theory of Change | Logic model |
|---|---|---|
| Main purpose | Explains how and why change is expected | Summarises programme delivery |
| Shape | Often visual and narrative | Usually more linear |
| Best used for | Strategy, assumptions, evaluation design and learning | Planning, monitoring and reporting |
| Risk if weak | Strategy becomes untested | Data collection becomes mechanical |
The Theory of Change explains the logic. The logic model helps turn that logic into a manageable monitoring and reporting structure.
Start with the problem, not the programme
A useful Theory of Change starts with the problem. Not the activities. Not the funder template. Not the organisation’s preferred intervention.
A weak problem statement might read:
Youth unemployment is high.
That may be true, but it is too broad to guide a programme.
A stronger problem statement would be more specific:
Young people in a specific community are leaving school without the support, networks, information and pathways needed to enter further study, training or work.
This gives the team something clearer to work with. It identifies the affected group, the context, the barriers, and the type of change the programme may be able to influence.
When defining the problem, the team should ask:
- Who is affected?
- Where is this happening?
- What immediate problem are we trying to address?
- What root causes sit behind it?
- What system barriers make the problem harder to solve?
- What can the organisation realistically influence?
- What sits outside the organisation’s control?
WHO’s evidence-informed ToC guidance sets out a six-stage process that starts with defining the problem, then moves to expected outcomes, interventions, change mechanisms, validation and revision. (World Health Organization)
This matters because a vague problem leads to vague outcomes. Vague outcomes lead to weak indicators. Weak indicators make reporting harder.
Map the pathway backwards from long-term change
Once the problem is clear, the team can map the pathway backwards.
Start with the long-term change. Then ask what must happen before that change is possible. Break those preconditions into intermediate and short-term outcomes. Only then should the team connect activities to the pathway.
A simple structure might look like this:
Long-term change ↑ Intermediate outcomes ↑ Short-term outcomes ↑ Outputs ↑ Activities ↑ Inputs
For example, a youth development NPO might map the pathway like this:
Long-term change: Young people have stronger pathways into further education, training or work.
Intermediate outcome: Participants complete school with better support, confidence and information about next steps.
Short-term outcomes: Participants attend support sessions, understand available pathways, receive mentoring and improve study routines.
Outputs: Tutoring sessions delivered, mentoring sessions completed, applications submitted, referral records created.
Activities: After-school tutoring, mentoring, career guidance, parent engagement and referral support.
This does not guarantee change. It gives the organisation a working theory that can be tested with evidence.
Make assumptions visible
Assumptions are often where programmes struggle.
A programme might assume that participants will attend regularly, families will support participation, schools will cooperate, referral partners will have capacity, staff will have enough time to collect data, or funder reporting templates will align with internal indicators.
Some of these assumptions may hold. Others may not.
UNEP explains that a Theory of Change depicts causal pathways from outputs through outcomes towards impact, and that it should define the external factors that influence whether one result can lead to the next. UNEP distinguishes between drivers, which the project may influence to some extent, and assumptions, which are external conditions outside the project’s control. (UNEP - UN Environment Programme)
A simple assumption-testing table can help:
| Causal link | Assumption | Evidence we have | Risk if wrong | How we test it |
|---|---|---|---|---|
| If learners attend weekly tutoring, then academic confidence improves | Learners can attend consistently | Attendance records and interviews | Low attendance weakens the pathway | Track attendance and interview non-attenders |
| If referrals are made, then families access support | Referral partners have capacity | Referral logs and partner feedback | Referrals do not lead to support | Track referral completion and partner response time |
| If staff collect field notes, then reports include richer evidence | Staff have time and a clear template | Fieldworker feedback | Notes are too thin to use | Review field notes monthly |
Assumptions should not stay in the workshop notes. They should become part of the monitoring and learning plan.
Turn the ToC into indicators
Every major outcome in the Theory of Change should have at least one way to observe progress.
This does not mean every outcome needs a complex measurement system. It means the team should be able to say what evidence would show whether that part of the pathway is working.
Output indicators
Output indicators measure delivery.
Examples include:
- number of workshops held
- number of participants reached
- number of home visits completed
- number of referrals made
- number of training sessions delivered
These indicators help the team show what was done.
Outcome indicators
Outcome indicators measure change.
Examples include:
- change in knowledge
- change in confidence
- change in behaviour
- improved access to services
- improved retention
- improved completion rates
- increased uptake of support services
These indicators help the team show what changed, or what appears to be changing.
Assumption indicators
Assumption indicators test whether the logic still holds.
Examples include:
- attendance rate
- partner response time
- referral completion rate
- staff data submission rate
- participant feedback on barriers
These indicators help the team see whether the conditions behind the programme logic are still realistic.
Qualitative evidence
Qualitative evidence explains what the numbers do not show.
This might include:
- interviews
- case studies
- focus group notes
- fieldworker observations
- beneficiary stories
- open-ended survey responses
- partner feedback
DPME’s impact evaluation guidance notes that impact evaluation requires information about inputs, activities, outputs and outcomes, and also cautions that an impact evaluation is not needed or advisable in all cases. Other evaluation types may be more suitable depending on the question, purpose and stage of the intervention.
A ToC without indicators is hard to test. Indicators without a ToC are easy to collect but hard to interpret.
Build a ToC evidence database
This is where the Theory of Change becomes useful for reporting, learning and decision-making.
A basic ToC matrix can link outcomes to indicators, evidence sources, data owners and reporting use. But for larger programmes, especially where there are interviews, case studies, field notes, partner feedback and key informant interviews, a simple table may not be enough.
In those cases, the ToC can become a structured evidence database.
The purpose of the database is to keep the programme logic connected to the source material. Each piece of evidence should be traceable back to where it came from, while still protecting confidentiality and anonymity.
A practical ToC evidence database might include fields such as:
| Field | Purpose |
|---|---|
| ToC ID | Links the evidence point to the Theory of Change database |
| Evidence ID | Identifies the specific extracted evidence point |
| Source ID | Links back to the original interview, document, case note or source record |
| Geography | Shows where the evidence applies |
| Sector | Groups evidence by programme, service area or system area |
| Stakeholder type | Distinguishes between rights holders, duty bearers, partners or other respondent groups |
| ToC domain | Links the evidence to a coded Theory of Change domain |
| Evidence statement | Summarises the relevant finding or extracted insight |
| Implication | Explains what the evidence suggests should be done |
| Notes | Adds context, limitations or review comments |
This structure is useful because it separates the source material from the reporting output.
The team can protect identities, anonymise respondents, and still maintain a clear evidence trail. Instead of copying raw interview material into reports, the team works with reviewed evidence statements, coded domains, source IDs and implications.
This also allows qualitative evidence to become easier to analyse. A codebook can group evidence under consistent themes such as accessibility, inclusive services, accountability, participation, service quality, referral pathways, assistive technology, governance, rights, or other programme-relevant domains.
That does not make the qualitative data statistically representative by itself. But it does allow the team to count, compare and review coded evidence across locations, sectors, stakeholder groups and outcome areas. This makes it easier to see where evidence is concentrated, where gaps remain, and where action may be needed.
A ToC database helps avoid a common reporting problem: the Theory of Change, M&E framework, interview notes, evidence statements, recommendations and final report all sitting in separate places.
A stronger setup connects them:
Raw source material → extracted data points → coded ToC evidence → implications → report sections → learning questions
This is where teams can turn programme evidence into themes, findings and reporting outputs, rather than trying to write reports from disconnected files and notes.
How a ToC evidence database supports learning
A source-linked ToC database is not only useful for reporting. It can also support learning.
In a UNICEF Palestine disability situation analysis project, this kind of structure was useful because the analysis involved sensitive qualitative evidence from multiple source types. The database came near the end of the analysis process, after raw material had already been reviewed, broken down into evidence points, anonymised and coded.
No identifying details need to sit in the reporting layer. Each source can receive a source ID. Each extracted insight can receive an evidence ID. Each item can then be linked to a ToC ID, coded against a domain, and connected to a sector, geography, stakeholder type, evidence statement, implication and review note.
The workflow looks like this:
1. Raw interviews and source material are anonymised. 2. Each source receives a source ID. 3. Relevant evidence points are extracted from the source material. 4. Each evidence point receives an evidence ID. 5. Each evidence point is linked to a ToC ID. 6. The evidence is coded by geography, sector, stakeholder type and ToC domain. 7. The evidence statement is written in a clear, report-ready form. 8. The implication is added, showing what the evidence suggests should happen next. 9. Notes are used for context, limitations or review decisions. 10. The coded database is used to support findings, recommendations, reporting and learning.
This creates a much stronger evidence trail than a normal narrative report.
It also makes learning easier because the organisation can ask better questions:
- Which ToC domains have the strongest evidence?
- Where are the biggest evidence gaps?
- Which barriers appear across multiple sources?
- Which sectors show repeated implementation issues?
- Which findings are linked to specific locations or stakeholder groups?
- Which implications should inform planning, advocacy or service improvement?
- Which assumptions in the Theory of Change need to be reviewed?
For larger evidence bases, the reviewed ToC database can also become the foundation for an AI-supported knowledge base.
The AI layer should not sit on top of messy raw data. It should sit on top of structured, anonymised, source-linked and reviewed evidence. That kind of system can help a team retrieve past findings, compare themes, summarise evidence by domain, prepare learning notes, and draft report sections.
Human review still matters, especially where evidence is sensitive or used to support recommendations.
This is the difference between using AI to summarise documents and using AI inside a properly structured evidence workflow.
For an example of this kind of work, you can see how theory-of-change evidence was structured in a delayed situation analysis.
Connect the ToC to reporting
A good Theory of Change should make reporting easier.
Each report section can map back to the outcome pathway:
1. What we planned to change 2. What we delivered 3. What changed 4. What evidence supports that claim 5. What assumptions held or failed 6. What we learned 7. What we will adapt next
This structure can support donor reporting, board reporting, annual narrative reports, funding proposals, evaluation readiness, internal learning and programme adaptation.
It also reduces the amount of reporting that depends on memory, scattered files or last-minute writing.
For example, a donor report does not need to start with a blank page. It can start with the ToC evidence database:
- output figures from the delivery tracker
- outcome signals from surveys and interviews
- coded quotes from case studies
- assumption notes from review meetings
- risks and adaptations from programme logs
- source links for key claims
- implications linked to reviewed evidence statements
Once the evidence is structured, the team can turn structured evidence into report-ready sections with less manual reconstruction.
Use the ToC as a living evidence system
A Theory of Change should change when the evidence changes.
It should be reviewed when:
- the programme expands
- the context changes
- monitoring data shows weak progress
- assumptions prove wrong
- funder requirements change
- the programme reaches a new phase
- evaluation findings challenge the original logic
WHO’s guidance focuses on developing and updating evidence-informed ToCs, and includes revision as one of the six stages in the process. (World Health Organization)
A practical review rhythm might look like this:
Monthly: check outputs and immediate activity data. Quarterly: review outcome signals and assumptions. Annually: revise the ToC based on evidence and strategic learning. Before evaluation: check whether the ToC is testable and evidence-backed. Before proposal renewal: update the ToC and evidence matrix.
This turns the ToC from a static document into a working evidence system.
For larger programmes, that may mean building an evidence database, tagging qualitative material by outcome area, linking findings to sources, and using reviewed material to support reporting and planning. Teams that need this structure can build a structured evidence database around their ToC.
Practical ToC templates for South African NPOs
The templates below are not meant to make the process complicated. They are meant to make the ToC usable after the workshop.
Template 1: One-page ToC canvas
Use this to keep the core logic visible.
| Field | Notes |
|---|---|
| Problem | What specific problem are we addressing? |
| Target group | Who is affected? |
| Long-term change | What change are we working towards? |
| Short-term outcomes | What early changes should happen first? |
| Intermediate outcomes | What changes should follow? |
| Activities | What will we do? |
| Outputs | What will be delivered? |
| Assumptions | What needs to hold true? |
| Risks | What could weaken the pathway? |
| Evidence sources | Where will evidence come from? |
| Indicators | How will progress be observed? |
| Reporting use | Where will this evidence be used? |
The key additions are evidence sources and reporting use. Without those, the ToC may remain strategy-only.
Template 2: Stakeholder and evidence map
Use this to connect people, roles and source material.
| Stakeholder | Role in the change pathway | What they influence | What evidence they can provide | How they should be involved | Risks or sensitivities |
|---|---|---|---|---|---|
| Participants | Experience the programme directly | Attendance, feedback, outcomes | Surveys, interviews, stories | Feedback sessions | Consent and privacy |
| Fieldworkers | Deliver and observe activities | Data quality, implementation notes | Field notes, issue logs | Monthly review | Time pressure |
| Partners | Support referrals or services | Follow-through after referral | Referral feedback | Partner check-ins | Capacity limits |
| Funders | Use evidence for accountability | Reporting priorities | Report feedback | Reporting review | Template misalignment |
Template 3: Assumption-testing table
Use this to stop assumptions from disappearing after the workshop.
| Causal link | Assumption | Confidence level | Evidence available | Evidence needed | How we will test it | Review date |
|---|---|---|---|---|---|---|
| If participants attend mentoring, confidence improves | Participants can attend consistently | Medium | Attendance records | Reasons for missed sessions | Interview non-attenders | Quarterly |
| If referrals are made, families access support | Partners have capacity | Low | Referral records | Completion feedback | Track referral outcomes | Monthly |
Template 4: ToC evidence database structure
Use this when the programme has enough qualitative or mixed-methods evidence to need a proper evidence trail.
| Field | What it captures |
|---|---|
| ToC ID | The Theory of Change evidence record |
| Evidence ID | The extracted evidence point |
| Source ID | The anonymised source record |
| Geography | Where the evidence applies |
| Sector | The service, system or programme area |
| Stakeholder type | The broad respondent or actor category |
| ToC domain | The coded Theory of Change theme |
| Evidence statement | The reviewed evidence or insight |
| Implication | What the evidence suggests should happen next |
| Notes | Context, limitations or review comments |
This structure is especially useful when a programme has a large qualitative evidence base. It allows the team to protect anonymity, keep findings linked to sources, code evidence consistently, quantify recurring themes, and turn analysis into report-ready recommendations.
UNICEF’s own child protection Theory of Change resources also show how ToCs can be linked to monitoring frameworks and organised around outcome pillars to support planning, implementation, monitoring and improvement. (UNICEF)
Common mistakes to avoid
Building the ToC around activities instead of outcomes
Many teams start with what they already do. The ToC should start with the change the programme is trying to support.
Using vague impact statements
Broad statements may sound good, but they are hard to test. Be specific about the group, context and type of change.
Ignoring assumptions
Assumptions explain where the programme logic may fail. They need to be monitored, not hidden.
Adding indicators too late
Indicators should be designed while the ToC is being built. If they are added after implementation starts, the team may miss baseline or early evidence.
Treating qualitative evidence as informal
Stories, interviews, field notes and open-ended responses can be valuable evidence when they are captured, tagged, reviewed and linked to outcomes.
Creating a diagram no one can understand
A ToC is only useful if staff can explain it and use it. If the diagram needs a specialist to interpret it, it may be too complicated.
Failing to assign data owners
Every indicator and evidence source needs an owner. Without ownership, data collection becomes inconsistent.
Using the ToC in proposals but not in reporting
The ToC should shape reports. If funder reports do not connect back to the ToC, the organisation loses a chance to show its logic clearly.
Letting AI summarise programme evidence without source structure
AI can help with summaries, comparison and first-pass synthesis, but only when the evidence is structured and human review is built into the workflow. Otherwise, the team may get confident-sounding outputs that are hard to verify.
Before using AI or preparing a major report, teams can check whether their evidence trail is strong enough.
When to get external help
External support can be useful when:
- the ToC exists but is not linked to indicators
- the team has too much evidence spread across files and spreadsheets
- donor reporting is slow
- qualitative evidence is hard to use
- findings are not clearly linked to source material
- the programme is preparing for evaluation
- a funder wants stronger evidence of change
- the team wants to use AI but does not have source structure or review controls
- the organisation needs a ToC, M&E framework, evidence matrix and report workflow to work together
I do not help teams create diagrams for the sake of diagrams. I help turn programme logic into evidence structures, indicators, source-linked findings and reporting workflows that teams can actually use.
Teams can also use evidence to identify priorities, risks and decisions when a ToC review needs to feed into strategy, planning or programme adaptation.
FAQ
What is a Theory of Change?
A Theory of Change explains how and why a programme is expected to contribute to change. It connects the problem, outcomes, activities, assumptions and evidence that should be monitored over time.
What is the difference between a Theory of Change and a logic model?
A Theory of Change explains the reasoning and assumptions behind change. A logic model usually summarises inputs, activities, outputs, outcomes and impact in a more linear format.
Why do South African NPOs need a Theory of Change?
A ToC helps NPOs clarify their strategy, design better indicators, collect relevant evidence, communicate with funders and review whether the programme logic is working.
How often should a Theory of Change be updated?
Review it at least once a year. It should also be updated when the programme changes, evidence shows that assumptions are weak, the context shifts, or a new funding or evaluation cycle starts.
Can a Theory of Change help with donor reporting?
Yes. A useful ToC can help structure donor reports by linking activities, outputs, outcomes, assumptions, evidence and learning.
Can AI help with a Theory of Change?
AI can help summarise source material, compare evidence and draft first-pass notes, but only when the source material is organised and human review is built into the workflow.
A Theory of Change should become usable evidence
A Theory of Change is not only a diagram for a proposal. It should become the working bridge between programme design, indicators, evidence collection, monitoring, evaluation, learning and reporting.
For South African NPOs, the value is practical. A usable ToC helps teams explain what they are trying to change, what evidence they need, what assumptions they must test, and how programme information should feed into reports.
The strongest ToCs do not sit separately from the work. They shape what the team collects, how evidence is reviewed, and how findings are reported.
Need to turn a Theory of Change into a working evidence and reporting system?
I help NPOs, donor-funded teams, research teams and public-sector projects move from programme logic to structured evidence, source-linked findings, indicators, reporting tables and clearer outputs.
Send a short project brief, or start by checking whether your current evidence trail is strong enough.
Database Architecture
Design practical database systems so information can be captured, organised, and used more effectively.
