What is the difference between a theory of change and a logic model?
A theory of change explains how and why change is expected to happen in a particular context. A logic model summarizes the relationships between a program’s resources, activities and intended results. The distinction is usually one of emphasis and detail, not a strict rule about which diagram is allowed to contain assumptions.
Use a theory of change to examine the reasoning behind a program. Use a logic model to communicate how the program is organized and what it aims to achieve. A useful model of either kind can include assumptions, context and connections between outcomes. Neither proves that a program caused a result.
If you are preparing a proposal, designing an evaluation or updating a program, start with the decision the model must support. You may need one well-explained model rather than two documents that say slightly different things.
Theory of change vs logic model: a practical comparison
| Question | Theory of change | Logic model |
|---|---|---|
| What does it help explain? | Why particular activities and conditions are expected to produce change. | How resources and activities connect to outputs and intended outcomes. |
| What does it usually emphasize? | Pathways, mechanisms, assumptions and the surrounding context. | A concise, shared description of a program and its expected results. |
| What can it look like? | A narrative, an outcomes map, a diagram or a combination. | A table, flow diagram or other visual account of program relationships. |
| Can it include assumptions? | Yes. Explaining important assumptions is central to its usefulness. | Yes. Assumptions and external factors can sit within or alongside it. |
| When is it especially useful? | Questioning a strategy, designing a complex intervention or testing explanations. | Agreeing a program description, planning measurement and communicating delivery. |
| What does it establish by itself? | An explanation to investigate, not a demonstrated causal effect. | A description of intended relationships, not proof that they occurred. |
Terminology varies between funders and evaluation teams. The Center for Theory of Change emphasizes the intermediate conditions that connect activities to longer-term goals. The CDC’s program-description guidance also includes context when developing a logic model. Treat “why versus what” as a useful starting shorthand, not a complete definition.
One example, expressed in both ways
Consider a fictional employer-supported training program. Its goal is to help staff handle unfamiliar customer requests accurately. The team can deliver workshops, but it also needs to know whether staff can use the procedure during real work.
The logic model gives a compact overview
| Resources | Activities | Outputs | Near-term outcomes | Later outcomes |
|---|---|---|---|---|
| Trainer time, procedure guide, practice system and manager support. | Practice scenarios, feedback sessions and coaching at work. | Sessions delivered, practice tasks completed and staff reached. | Staff demonstrate the procedure correctly and recognize when to escalate. | More consistent handling of relevant requests, with fewer avoidable corrections. |
This overview is useful for agreeing responsibilities and planning records. It does not explain every reason the program might succeed or fail.
The theory of change opens up the reasoning
Practice may improve performance because staff encounter realistic decisions, receive specific feedback and correct errors before handling similar requests at work. Transfer may depend on access to the current guide, time to use it and managers reinforcing the same procedure. If the software changes or staff are rewarded only for speed, training alone may not lead to the intended behavior.
The evaluation therefore needs more than attendance and satisfaction. It needs observations of the skill, evidence of opportunities to apply it and information about the conditions under which staff work. An increase in accuracy might also reflect a simpler mix of requests or a software improvement. Those are explanations to examine, not details to omit.
Watch: theory of change and logic model explained
Theory of change: understand the reasoning
Start with the existing theory-of-change introduction to understand outputs, outcomes and the proposed pathway to change.
Logic model: explore its practical application
Then watch the logic-model video to consider how you can describe a program’s resources, activities and results. Return to the worked example above to compare the two formats.
These videos introduce the frameworks. Use the measurement and evidence limits below when applying them; neither diagram establishes a causal effect by itself.
Which should you use?
Start with a theory of change when the reasoning is uncertain
If partners agree on a goal but disagree on how to reach it, a compact activity list can hide the disagreement. Discuss the proposed pathways, who is expected to benefit and the conditions that matter. Include people who will deliver and experience the program. Their perspectives can reveal access barriers that a planning team has missed.
Start with a logic model when you need a shared program description
A small, established program may first need a clear account of who does what and which outcomes are in scope. A logic model can expose an activity with no clear purpose, an outcome with no supporting activity or an output that has been mistaken for a result. Add the explanation needed to make its relationships understandable.
Use both when they serve different decisions
A strategy team may need a detailed explanation while a delivery partner needs a one-page overview. Build the overview from the same agreed outcomes and assumptions. Do not create a second vocabulary or a separate set of targets just to fill another template. If a funder requests a particular format, meet that requirement while keeping the underlying reasoning consistent.
For deeper guides, see theory of change, logic models and the logic model template.
How to turn a theory of change into a logic model
- Agree the scope. Name the population, setting, period and decision. Avoid putting a whole organization’s ambitions into one small program model.
- Select the outcomes this program can reasonably influence. Keep longer-term aspirations visible, but distinguish them from outcomes you will actually measure.
- Map the activities and resources behind those outcomes. Explain missing connections rather than drawing an arrow simply because two boxes are next to each other.
- Separate delivery from change. Completing a session is an output. Demonstrating a new skill is an outcome. The distinction affects what data is needed.
- Carry the important assumptions into a short note. Include conditions such as access, staff capacity and opportunities to use the skill.
- Check the summary with the people who will use it. Ask whether it still represents the original explanation and whether responsibilities are clear.
You can also work in the other direction. Take an existing logic model and explain each connection. Where an explanation is uncertain, record it as a question for investigation rather than silently treating it as established fact.
Connect the model to a measurement plan
A model becomes operational when the team agrees what evidence to collect and how to interpret it. The following is a suggested working structure for the fictional training example.
| Model element | Evidence question | Collection and review rule |
|---|---|---|
| Practice reaches intended staff. | Who had access, participated or was missing? | Link enrollment and attendance to stable staff and cohort identifiers; explain exclusions. |
| Staff demonstrate the procedure. | Can they complete a realistic task? | Use a defined rubric and record the assessor, task version and date. |
| The skill is used at work. | Did staff have an opportunity, and what did they do? | Combine an appropriate follow-up with observations or work records where permitted. |
| The context supports the change. | What helped or blocked application? | Keep feedback alongside relevant results; review alternative explanations. |
Define the unit of analysis. A person, attendance entry and completed task are different units. State the denominator for each percentage and do not treat missing follow-up as evidence of either success or failure. If you want to describe change in the same people, preserve the link between their observations over time.
Allow local variation without losing comparability
A network of schools, chapters or delivery partners may need different questions. Agree a small core of shared fields and definitions where comparison is necessary, then allow locally useful questions. A data dictionary should specify meanings, response options, timing and permitted mappings. Collect stable registration details once and update changing information when needed. Do not impose one complete survey merely because a common report is required.
Keep the models useful after the proposal
Assign an owner and review date. Record which version informed each collection period. When delivery or context changes, ask whether the outcome definitions, assumptions or measurement plan also need revision. The CDC evaluation framework identifies changes in context, resources, knowledge and evaluation findings as reasons to revisit a logic model.
Do not rewrite an old definition silently to improve the appearance of a trend. Retain the earlier version and explain whether results remain comparable. A useful review record says what changed, why it changed, who approved it and which data the change affects.
Where connected evidence reduces repeated work
The practical burden often appears after the diagram: separate forms for each site, unclear indicator names, repeated spreadsheet joins and a report rebuilt from scratch. Sopact’s role is to bring collection, relevant context, analysis and review into a connected workflow. That can help a team inspect the records behind a result and reuse agreed definitions across reporting cycles.
When assessing that workflow, test one outcome end to end. Can you find the underlying observations, identify the instrument version, explain missing records and see who reviewed the interpretation? Can local teams collect what they need while shared measures remain comparable? Those are more useful acceptance criteria than the appearance of the diagram.
Connected records support evaluation; they do not establish causal effects automatically. The distinction between a supported explanation and a causal estimate is explored in attribution vs contribution. For the wider process, see monitoring and evaluation.
Frequently asked questions
Is a theory of change better than a logic model?
Neither is universally better. Choose the form that supports the decision and makes the important reasoning clear. A brief logic model can be sufficient for one purpose; a detailed theory of change may be needed for another.
Can a logic model include assumptions?
Yes. Assumptions, contextual factors and external influences can appear within or alongside a logic model. It is misleading to define a logic model as a diagram that cannot include them.
Is a logic model always linear?
No. Many use a simple left-to-right sequence, but the format can show several pathways, relationships and feedback. Avoid presenting a complex program as a single inevitable chain if that misrepresents how it works.
Do we need a logframe as well?
Only if it serves a reporting or planning need. A logframe commonly organizes objectives, indicators, evidence sources and assumptions. It is another way to structure information, not an automatic requirement for every program.
Does evidence matching the model prove impact?
No. Consistency with the model is useful, but alternative explanations and evidence quality still matter. A causal claim needs an evaluation approach suited to the question.
Where can our team practice building one?
Use the Academy lesson on building a theory of change to develop the reasoning, then connect it to the measurement and reporting course below.
Choose your next step
King Center
See how participant feedback supports program review and learning. This story is separate from the fictional teaching examples above.
Read the customer story →