01 · What breaks
Design for the failure modes, not only the happy path.
Most Theory of Change diagrams are drawn for proposals. Turning one into a database exposes boxes nobody can observe, arrows nobody can test and indicators nobody owns.
One table for every diagram box
A box such as "improved confidence" is a claim, not an entity. A table per box produces forms nobody fills in. Model the things that exist (learners, sessions, assessments) and calculate the boxes from them.
Proxy indicators treated as outcomes
Attendance, kits distributed and trainings held are outputs. When they sit under "outcomes" on a dashboard, the funder report overstates change. Tag every indicator with its level in the results chain so the difference stays visible.
Context and assumptions omitted
Assumptions such as "families allow girls to keep attending" are usually where programmes break. Give the riskiest two or three a light record, for example a dropout reason code or a monthly check, so the team sees when one stops holding.
Collecting fields nobody reviews
Every field is a tax on a field worker standing in the sun with a low-battery phone. If no meeting, report or service decision uses a field, drop it. "We might need it later" is not a purpose, and for personal data it is hard to defend under India's data protection law.
02 · Minimum viable model
Map the results chain onto units, events and follow-ups.
A working rule from EdZola's How Nonprofits Operate field guide: the Theory of Change is the story, the logframe is the contract and the indicators are the data model. These six records usually carry a programme from activity to outcome.
| Results level | What the system stores | Typical source | Example indicator |
|---|---|---|---|
| Activity | A dated event per unit | Session attendance or home-visit form | Sessions held per centre per month |
| Output | A count calculated from events | Formula on activity records | Learners attending at least 80% of sessions |
| Outcome | A repeat observation of the same unit | Baseline and endline assessment, follow-up call | Share of learners who moved up at least one level |
| Assumption | Reason codes and periodic checks | Dropout reason list, monthly review note | Dropouts citing family objection |
| Impact | Usually nothing in the MIS | External evaluation or public data | Reported separately, with its method |
03 · Implementation sequence
Move through reviewable gates.
Work backwards from decisions to records. Each step ends with something the programme team can sign off, not another diagram.
Mark the decisions the theory should inform
List the five to ten decisions the team makes every month or quarter: which centres need support, which learners need remediation, whether a partner is renewed. Highlight the boxes in the theory that inform them. Everything else stays in the proposal.
Identify units and relationships
Name the unit for each outcome and how units relate: a learner belongs to a batch, a batch to a centre, a centre to a project and a grant. A person enrolled in two projects is one record with two links, not two rows in two donors' sheets.
Map outcomes to observable evidence
For each outcome, write the observation that would show it, when it is taken and by whom. If the honest answer is that nobody sees the person again after the programme ends, add a follow-up event or demote the outcome to a narrative claim.
Define timing and attribution limits
Fix baseline, midline and endline windows and what counts as late. Note what else could explain the change, such as another scheme or the school calendar. These notes travel with the indicator into every report.
Design the minimum source workflow
Write each indicator spec: name, definition, formula, numerator and denominator source, disaggregation only where it changes a decision, frequency, owner and target. Ask two people to calculate it separately; the numbers should match. Then draft the forms that feed it, using the MIS requirements template.
Test whether teams can maintain it
Run one real reporting cycle on the draft model with field staff entering data. Count the minutes per visit and the fields left blank, and cut before anything is built. In EdZola's method the data model is signed off before a single screen is configured, because that is when changes are cheap.
04 · Evidence
Measure whether the work became clearer.
A good translation shows up in the first funder report: outcomes come straight from records, and nobody spends a week reconciling three versions of the same number. Feed these checks into your M&E software reviews.
05 · Responsible automation
Let systems prepare. Keep consequence with people.
Systems can support
- Drafting entity and field lists from a logframe
- Calculating output and outcome indicators by formula
- Flagging outcomes that have no follow-up record
- Listing fields that no report or decision uses
People should decide
- Accepting an outcome claim
- Interpreting contribution
- Changing the programme theory
- Deciding what not to collect
06 · Common questions
Practical questions teams ask.
Questions MEL leads and programme managers ask when a diagram has to become a database.
How do you turn a Theory of Change into a data model?
Start from the decisions the programme makes, not from the diagram. For each outcome, name the unit that changes (a learner, a household, a group), the event that shows the change (an assessment, a follow-up call) and when it happens. Model those units and events as records, calculate outputs and indicators from them, and keep untestable boxes as narrative.
What is the difference between a Theory of Change, a logframe and a data model?
The Theory of Change explains why the programme should work. The logframe commits to specific indicators, targets and means of verification, often for one funder. The data model is the set of records and fields that produces those indicators. A short way to hold it: the theory is the story, the logframe is the contract and the indicators are the data model.
Which records does a programme need to report outcomes, not just outputs?
It needs a stable record for each participant or unit, dated service events linked to that record, and a repeat observation of the same unit later, such as an endline assessment, a 90-day follow-up or a placement check. Without the follow-up record the system can count activity but cannot show change.
Who should own the move from Theory of Change to data model?
The MEL lead usually owns indicator definitions, the programme manager owns the workflows that generate the data, and an internal administrator or technology partner owns the structure. Field staff should test the draft forms before build. Leadership decides which outcomes the organisation will publicly claim.
How many indicators should a small nonprofit track?
Fewer than most logframes list. Keep a short set where each indicator informs a named decision or a funder commitment, with a small number of outcome measures taken on the same people at baseline and endline. Retire any indicator that nobody has used in two reporting cycles.