A logic model is a one-page picture of how your program is supposed to work: what you put in, what you do, what comes out, and what changes for people as a result. Funders ask for one because it exposes fuzzy thinking faster than any essay can.
If you can fill in the five columns below, you can write the goals, objectives, methods and evaluation sections of a proposal almost directly from it.
The five columns
1. Inputs
What you have to work with.
- Staff and their time.
- Funding, including this grant and any match.
- Facilities, vehicles, equipment.
- Partners and volunteers.
- Existing relationships in the community.
2. Activities
What you actually do. Use verbs.
- Recruit and enroll participants.
- Run weekly cooking classes.
- Deliver meal boxes twice a month.
- Train volunteers.
- Convene the partner coalition quarterly.
3. Outputs
The countable product of the activities. Outputs are about your effort, not about change.
- 120 participants enrolled.
- 48 cooking classes delivered.
- 24,000 meals distributed.
- 30 volunteers trained.
A useful test: an output can be counted even if it changed nothing for anyone.
4. Outcomes
What is different for participants, the organization, or the community. Outcomes are about change, and they come in three time frames.
- Short term (0-6 months): knowledge, attitude, skills. "Participants can name three affordable protein sources."
- Medium term (6-18 months): behavior. "Participants cook at home four or more nights a week."
- Long term (18 months and beyond): condition. "Household food insecurity scores fall."
5. Impact
The mission-level change your organization exists to create. You will rarely be able to attribute this to one grant, and funders know that. State it honestly as the direction of travel.
A worked example
Take a small nonprofit running a senior meal program. Laid out, it looks like this.
Inputs: two part-time staff, one delivery van, a commercial kitchen partnership, $85,000 including this request, 40 volunteers.
Activities: enroll seniors through the area agency on aging; cook and pack meals twice weekly; deliver along four routes; conduct a quarterly wellness check at the door.
Outputs: 1,200 seniors enrolled; 24,000 meals delivered; 160 wellness checks completed.
Short-term outcomes: participants report knowing where their next meal is coming from; volunteers flag health concerns that reach a case manager.
Medium-term outcomes: participants report eating two or more balanced meals daily; self-reported isolation scores improve.
Long-term outcomes: emergency room visits for dehydration and malnutrition decline among enrolled seniors.
Impact: older adults in the county live independently at home for longer.
Notice that the outputs are things the program did, and the outcomes are things that changed. That distinction is where most logic models fall apart.
Turning the model into proposal language
The columns map onto the proposal almost one to one.
- Statement of need comes from the problem the outcomes address, plus your local data.
- Goals and objectives are the outcome columns, written with a number and a date attached.
- Methods is the activities column, expanded into prose.
- Timeline is the activities column, arranged in sequence.
- Evaluation is the measures you attach to each outcome, and how you collect them.
If your logic model and your proposal disagree, a careful reviewer will notice.
Common mistakes
- Confusing outputs with outcomes. "Served 24,000 meals" is an output. It is not a result.
- Too many outcomes. Six outcomes you can actually measure beat twenty you cannot. Reviewers count.
- Outcomes you cannot measure. If there is no existing tool, survey, or administrative record that produces the number, you cannot report it later.
- A model with no inputs from partners. If the partnership is real, show it in the model.
- Building the model after the proposal. It is a planning tool. Building it first makes the writing dramatically easier, and it usually surfaces a gap in the program design while there is still time to fix it.
A note on numbers
Whatever figures end up in your logic model will end up in your proposal, and from there in front of a reviewer who may check them. Pull them from your own records: enrollment logs, attendance sheets, intake forms, prior year reports. Never estimate a number you could look up, and never let a writing tool supply one you did not give it.