Program Theory: Map How a Program Should Work
Build a program theory with a worked tutoring example. Link actions to short and long-term outcomes, name key assumptions, and plan what to test next.
- Byline

Summary
A program theory explains how an intervention is expected to lead from its activities to outcomes, and under what conditions.
Start with the people and result, then trace actions, early changes, later changes, assumptions, and outside influences.
A logic model can show the path at a glance; a short narrative makes the links and uncertainties easier to examine.
Program theory is a proposed account of how a program should lead to change. It connects what a team does to what people may do next, then to a result the team hopes to see.
Suppose a tutoring team offers free sessions. Its plan may assume that students can attend, practice new skills, and use those skills in school. A timetable shows that sessions were planned. The rest of that path needs its own checks.
The CDC evaluation framework calls for a short model and a written account of its links and context. Atlas can help compare selected plans and records with citations. The team and evaluator decide whether the model fits.
Check your program sources in Atlas
Compare selected plans and reports, check citations, and save a model note.
What program theory means
A program theory explains how and why a program is expected to bring about a result. It names the actions, the people or systems expected to change, and the conditions needed along the way. The theory can describe intended gains and possible harms.
BetterEvaluation's program-theory guide treats the theory as an account of how an effort may contribute to a chain of results. Other actors and the setting can also shape those results. That makes the model a proposal to examine, rather than a record of what happened.
Teams often draw the path as a logic model or theory-of-change diagram. The CDC action guide pairs the graphic with a short narrative about the need, resources, actions, results, and context. The terms overlap across evaluation fields; spell out what your team means by each.
Name the parts of the model
The CDC action guide starts with actions and outcomes. A useful written model also says who the work is for and what might help or block change. Keep evidence or an open test beside each proposed link.
- Need and people: What problem is the program addressing, and who faces it?
- Inputs and actions: What staff, funds, partners, and activities does the program use?
- Outputs: What does the team deliver, such as sessions or calls?
- Early and later outcomes: What changes for participants first, and what longer-term result is sought?
- Assumptions and context: What must be true for each step to lead to the next, and what outside forces may change the path?
The parts are connected by claims. “Tutoring session → stronger reading skill” assumes students attend, can practice, and receive teaching suited to their needs. The arrow does not explain itself.
The CDC framework recommends a one-page road map with a narrative. The page helps people see the whole path. The text gives room for missing steps, different views, and the setting in which the work runs.
Keep outputs and outcomes apart
A delivered session is an output. A student using a new reading skill is an outcome. A later school result may depend on many other things. If a team counts sessions as proof of learning, the model hides the very link an evaluation needs to check.
Draft the path backward from change
Start with the decision the model should inform. Is the team planning delivery, choosing what to measure, or asking why a result changed? Pick a target group and a result precise enough to discuss.
Then work backward. For a tutoring program, stronger reading at school may require skills gained in sessions. Gaining skills requires regular attendance and practice. Attendance requires a schedule students can use, a place they can reach, and a clear way to sign up.
Write “if” and “then” for each link. If the team offers sessions at usable times, invited students may attend. If they attend and practice, they may gain skills.
The CDC guide suggests asking “so what?” from actions toward results, or “how?” from the result back to actions.
Ask people who know the program
Staff may know what was delivered. Students may know what made it usable. Ask both groups which link seems weak or missing.
The CDC framework recommends working with affected people to describe the program and expose gaps in the planned path.
Write down points where the team and students disagree. A staff member may expect tutoring to improve skills; a student may say travel and work hours decide whether they can attend. A model that shows both views gives an evaluation a better starting point.
Work a program theory example
This tutoring program, its records, and its numbers are fictional. Imagine a community group offering two after-school reading sessions each week. The stated goal is to help invited students read with more confidence in class by term's end.
The first model runs from invitation to attendance, practice, skill, and class use. A team could draw those boxes quickly. The harder task is to name what must be true between them and which record could test it.
The table is a work note for that question. Its T-01 to T-04 IDs are invented labels. In a real project, each row would point to an exact plan, log, interview passage, or other source.
| Proposed link | Assumption to check | Fictional record or gap | Possible revision |
|---|---|---|---|
| Invitation → sign-up | Families receive and understand the offer. | T-01 draft flyer exists; no distribution log. | Confirm where and when invitations went out. |
| Sign-up → attendance | Session times and travel allow students to come. | T-02 log shows many signed-up students miss weekday sessions. | Add transport or a second time slot to the model. |
| Attendance → skill practice | Sessions give students enough guided reading. | T-03 lesson plan lists exercises; no record of practice completed. | Track practice and ask students about the tasks. |
| Practice → class use | Skills transfer to class reading tasks. | T-04 teacher note mentions progress for a few students. | Check the measure and other support students received. |
Table 1: The attendance row changes the story. The program can deliver sessions and still fail to reach students who signed up. The first model skipped a barrier between interest and participation.
The revised path adds access: offer a usable session time and route → students attend → students practice → skills may improve → students may use them in class. That is a better hypothesis to test. It does not claim a transport change would work before the team tries it.
The teacher note is another limit. A few students' progress may be worth following up, but it cannot stand for the full group. The team should define what class use means and check the same measure across students before claiming a broad result.
Check assumptions and revise the model
For each arrow, ask what would need to happen, what could stop it, and what record would reveal the difference.
The CDC framework treats logic models as living documents. Changes in resources, setting, research, or delivery can call for revision.
In the fictional example, the T-02 attendance log calls for a new access step. Staff could also speak with students who missed sessions. The interviews may show that time, travel, competing care work, or a different barrier matters.
Do not fill a gap with the program's desired result. A lesson plan shows intended teaching. A session log shows who came. Each tells only part of the story.
Choose a measure that matches the outcome, and keep the source and date beside it. Our operationalization guide shows how to turn a broad outcome into something that can be checked.
Keep context in the written account
The diagram may show a single arrow from tutoring to learning. The written account can note a school reading campaign, staff turnover, or a new attendance rule.
The UK process evaluation guide treats delivery, mechanisms, and context as questions that help explain results.
Context can change a link without making the whole model useless. Update the assumption and record why. A dated version of the model lets the team see what it believed before the new record arrived.
Compare program records in Atlas
Atlas can help review selected text behind a model. Add the plan, delivery logs, permitted interview notes, and reports to a project. Mention the chosen files with @ so the question stays tied to those items.
Ask: “For each proposed link, cite passages that describe the action, an early change, or a barrier. Mark links with no source support.” Open each citation and check the record.
The Atlas synthesis guide describes cross-source comparison. The source-checking guide helps with passage review.

Save a corrected model note with source IDs, assumptions, open gaps, and questions for students or staff. The screenshot shows a supplied source beside an answer.
Atlas cannot observe missed sessions or settle disagreements about the program's purpose. The team owns the model and its next tests.
Use the theory in evaluation
A program theory gives an evaluation a map of questions. It can guide which records to collect, whom to ask, and where a proposed link is weak.
The CDC action guide places the program description before choosing the evaluation's focus and design.
If the team later asks whether tutoring helped produce a result, contribution analysis offers a way to test the proposed path against what happened and against other causes. If it works with partner groups, outcome mapping can track their own actions over time. The theory is the starting claim; each next method needs observed data and a design fit for the question.
Keep one sentence beside the model: “We expect these actions to help these people reach this result if these conditions hold.” Then list the conditions and the records that could challenge them. That small note makes a polished diagram useful to the people who must test and revise it.
Check your program sources in Atlas
Compare selected plans and reports, check citations, and save a model note.
Frequently Asked Questions
It explains how and why a program's actions are expected to lead to results, including the assumptions and conditions needed for the proposed change to happen.

