>
Program Development

Writing a theory of change your field team recognizes

Most theories of change are written for funders and ignored by staff. A good one changes what people do on Tuesday.

If your field team cannot describe your theory of change without reading it, it is a fundraising document rather than a program tool. That distinction determines whether it is worth the effort.

What it actually is

A theory of change is a chain of reasoning: if we do these things, with these people, in this context, then these changes occur, because of these assumptions. The value lives in the last clause. Most documents skip it — and the assumptions are exactly where programs fail.

The five elements

  1. The problem, defined precisely. Not "poverty" but the specific mechanism you believe is producing the outcome you want to change. Vague problems produce vague programs.
  2. The people. Who specifically, in what context, at what stage. "Vulnerable children" is a category, not a population.
  3. The intervention. What you do, in what sequence, at what intensity, for how long.
  4. The outcomes. What changes, for whom, over what timeframe — connected to your graduation criteria.
  5. The assumptions. What must be true for the chain to hold. This is the section that makes the document useful and the one most often omitted.

Write the assumptions honestly. "We assume caregivers will attend if childcare is provided." "We assume the local school has capacity to absorb enrolled children." Each assumption is a testable claim, and each is a place your program can quietly break without anyone noticing why.

Build it with the people closest to the work

A theory of change written at headquarters and distributed to the field will be technically coherent and practically wrong. The people implementing know which assumptions are shaky — they have watched them fail. Writing it without them wastes the most valuable input available.

This is the same argument as the 2:1 rule applied to program design: those closest to the problem should hold the loudest voice in describing how it gets solved.

Keeping it alive

  • Review it annually against what actually happened. Which assumptions held? Which didn't?
  • Use it in program design decisions. Any new activity should be traceable to a link in the chain, or it should not be funded.
  • Keep it to two pages. Longer documents get filed rather than used.
  • Connect it to your indicators. Your outcome measures should follow directly from the outcomes named here.

Your first 90 days

  1. Draft the five elements in two pages. Do not aim for elegance yet.
  2. Take it to your field teams and ask specifically which assumptions they think are wrong.
  3. Revise honestly — including deleting things you like.
  4. Map your outcome indicators against it and fix the gaps.

Where this sits. Program Development work only holds when the layer beneath it is solid. The free Flourishing Index shows you which layer is actually constraining you — in six minutes. Take the Index →

Sources
  1. W.K. Kellogg Foundation Logic Model Development Guide — foundational logic-model and theory-of-change practice.
Read next

Choosing outcome indicators you can actually collect →

Defining graduation: how to know when your work is done →

If you want it facilitated

A theory of change written alone tends to confirm what leadership already believed. We run it as a workshop — and as the opening movement of Directional Discernment, where the assumptions get tested against what the field actually reports.

See the process →