The Needs Statement and the Logic Model

The needs statement establishes that a problem exists, using evidence, before you propose doing anything about it. It is the section most often written badly, and it fails in one predictable way: it describes the applicant's shortage of money rather than the community's condition.

"We lack funding to run our after-school program" is not a need. It is a budget gap. The need is whatever is true about the children who have nowhere to go at four in the afternoon — and that is true whether or not your organization exists.

The needs statement shows that a problem exists, with evidence, before you propose doing anything about it. It's the section people most often get wrong, and it fails the same way every time: it describes the applicant's lack of money instead of the community's situation.

"We don't have funding for our after-school program" isn't a need. It's a budget gap. The need is whatever is true about the kids with nowhere to go at four in the afternoon — and that's true whether or not your group exists.

Before you ask for money to fix something, you have to show that the something is real.

Here's the mistake almost everyone makes: they describe not having enough money as the problem.

Not having money isn't the problem. The problem is whatever is happening to real people — and that would still be happening even if you'd never come along.

It is about them, not you. The condition exists independently of your funding situation.

It uses evidence, and says where the evidence came from. Public data, your own service records, documented local studies. Never a statistic you half-remember — an invented number is the fastest way to lose a reader who happens to know the real one.

It is specific to your geography and population. National figures establish that a problem category exists. They do not establish that it exists on your street, and reviewers reading a stack of proposals have seen the same national statistic five times that morning.

It stops before the solution. The needs statement establishes the problem. Proposing is the next section's job, and mixing them makes both weaker.

Good ones talk about the people, not about you.

They use real facts, and say where the facts came from. Never make a number up — someone reading might know the real one.

They're about your actual place, not the whole country. "This happens everywhere" doesn't prove it happens here.

And they stop before the solution. First show the problem is real. Explaining your idea comes next.

A logic model is a one-page map of how your work turns money into change. It runs left to right in four steps: what you put in, what you do with it, what that produces, and what changes as a result.

The value is not the diagram. It is that the chain has to hold together, and building one exposes the gaps you had been stepping over — an activity that produces nothing measurable, an outcome with no activity leading to it, a resource nobody accounted for.

A logic model is a one-page map of how your work turns money into change. Four steps, left to right: what you put in, what you do, what that produces, and what's different afterward.

The point isn't the diagram. It's that the chain has to actually connect, and drawing it exposes gaps you'd been stepping over — something you do that produces nothing you can count, or a result with nothing leading to it.

A logic model is one page showing how money turns into change.

It goes in four steps: what you start with, what you do, what that makes, and what's different afterward.

The useful part isn't the drawing. It's that each step has to actually lead to the next one — and when you try, you find the places where it doesn't.

This distinction decides more applications than any other single thing in a proposal.

Outputs are what the work produces, counted. Meals served, students enrolled, sessions held. Easy to measure, entirely within your control, and — on their own — not what anyone is funding.

Outcomes are what is different because the work happened. Harder to measure, only partly within your control, and the actual reason the money exists.

Serving two hundred meals is an output. Whether those people were less food-insecure afterward is an outcome. A proposal that promises only outputs is promising activity, and activity is not what a funder is buying.

Two honest cautions. Do not promise an outcome you cannot measure — you will be reporting against it. And do not claim an outcome your project cannot plausibly cause on its own; overreaching here reads as inexperience to anyone who has run a program.

This distinction decides more applications than anything else in a proposal.

Outputs are what the work produces, counted: meals served, students signed up, sessions held. Easy to count, completely up to you, and on their own not what anyone is paying for.

Outcomes are what's different because it happened. Harder to measure, only partly up to you, and the actual reason the money exists.

Serving two hundred meals is an output. Whether those people were less hungry afterward is an outcome. Promising only outputs is promising activity, and activity isn't what's being bought.

Two warnings. Don't promise an outcome you can't measure — you'll have to report on it. And don't claim one your project couldn't plausibly cause by itself.

This is the idea that decides more proposals than any other.

There's what you did — how many meals you handed out, how many kids came. That's easy to count.

And there's what changed — whether those people were actually better off. That's harder to measure, and it's the thing people are really paying for.

Handing out two hundred meals is the first kind. Whether those people were less hungry is the second.

And be careful: don't promise a change so big your project couldn't really have caused it by itself.