← All prompts

Logic Model and Theory of Change Builder for a Grant Proposal

Builds a funder-ready logic model and theory of change narrative from the program you actually run, with an indicator and a real data source behind every outcome row.

About this prompt

A logic model is usually the last thing written and the first thing a program officer reads closely. Done in a hurry, it lists activities twice and calls them outcomes, promises change nobody is set up to measure, and quietly commits the organization to reporting numbers it does not collect.

This prompt runs the build in the order that actually works. It collects the program as it operates today, asks what the organization already counts (sign-in sheets and case notes included), and only then fills the columns. Outcomes are separated from outputs on purpose, and every outcome row must name an indicator, a data source, and when the data gets collected. Anything that cannot clear that bar comes back marked NEEDS DATA instead of being written as if it were settled.

You get a six-column logic model table, a stated assumptions list, external factors, a 200 to 300 word theory of change narrative ready to paste into a proposal, a measurement gap list with the smallest fix for each gap, and three questions to put to the program director before submission.

Built for development staff at small nonprofits, program directors writing their own proposals, and consultants who need a defensible model from a first conversation rather than a second one.

Preview

You are a grants strategist who builds logic models for small nonprofits, the kind with one development staffer and no evaluation department. You produce a logic model and a short theory of change narrative that a program director recognizes as their own program, and that a program officer can read

Example output

SECTION 1. LOGIC MODEL (excerpt, adult literacy tutoring)

ACTIVITIES: Weekly 90-minute one-to-one tutoring, 30-week cycle; intake reading assessment; volunteer tutor training.

OUTPUTS: 45 learners enrolled per cycle; 1,080 tutoring hours; 24 tutors trained.
  Indicator: sessions logged in the tutor sign-in binder. Source: existing binder. Collection: ongoing.

SHORT-TERM OUTCOMES (0 to 12 months):
  Learners gain at least one reading level on the intake assessment.
  Indicator: pre and post score, same instrument. Source: intake assessment exists; no post-test yet. Collection: week 1 and week 30. STATUS: NEEDS DATA.

  Learners attend 70 percent or more of scheduled sessions.
  Indicator: attendance rate per learner. Source: sign-in binder. Collection: end of cycle.

INTERMEDIATE OUTCOMES: Learners report using reading at work or with their children.
  Indicator: 6-item exit survey. Source: none currently. STATUS: NEEDS DATA.

SECTION 5. MEASUREMENT GAPS
1. No post-assessment. Smallest fix: schedule the same intake instrument in week 30 and add a line to the tutor's final session checklist. No new tool, 20 minutes per learner.

How to use it

Run this in a single chat and answer the intake questions before asking for the table. The quality of the model tracks almost entirely with the honesty of the data answer: list what is actually collected, including the informal spreadsheet, not what the organization wishes it collected.

Have ready: the program description as it currently runs, last year's participant count, whatever intake or assessment forms exist, and the funder's logic model template if there is one. If the funder supplies a template, paste it in; the output will be mapped to those column names instead of the default six.

Where it fails: programs still in design with no delivery history, since there is nothing to anchor outputs to. Multi-site programs with different models per site should be run once per site, then merged by hand.

Before using the output, check three things. Every outcome row names a real data source, not an aspiration. Nothing in the outcome columns is a restated activity. And any row marked NEEDS DATA is either resolved or removed, because a reviewer will find it.