Strengthening the organization

Program Design

What you should build and why: the need, who it serves, how it is meant to work, and whether the design is sound enough to approve.

2 min readOpen it in the app →Included from Core

On this page

Design and Impact are two tools
The unit of work is a version, not a program
Working through a design

Design and Impact are two tools

They share one program record and never duplicate it, but they answer different questions, and running them together is how organizations end up unable to say what they originally intended.

The Program Design workspace showing design versions with their statuses and the sections of a design — The Program Design workspace, where a version holds the whole design rather than each artifact separately.

Program Design: What should we build, for whom, why is it needed, and is the design sound. Everything before the program runs.
Program Impact: What actually happened, what changed, and what to do about it. Everything after.

The unit of work is a version, not a program

A design version is a snapshot of the entire design moving together: the need, the population, the theory of change, the logic model, the outcomes, the measurement plan, and the approvals.

That matters because of the question a funder or a board actually asks, which is what did we approve. A system that versions each piece separately can tell you what the logic model said in March without being able to answer that.

Status	Means
Draft	Being worked on. Change anything.
In review	Submitted for approval. Stop editing.
Approved	This is the design of record.
Rejected	Not approved, and the reason is recorded.
Superseded	A later version replaced it. Kept, because it is what was approved at the time.
Withdrawn	Pulled before a decision.

What a version's status means.

Working through a design

Start with the need, not the program.
The need is a statement about the community, evidenced. If you cannot evidence it, that is the finding, and it is better found now than in a declined application.
Define who it serves, specifically enough to know whether somebody qualifies.
Write the theory of change: why you believe this activity produces that result.
This is the part reviewers read hardest, because it is where wishful thinking lives.
Build the logic model: inputs, activities, outputs, outcomes.
Outputs are what you did. Outcomes are what changed. Confusing them is the commonest weakness in nonprofit reporting.
Set the measurement plan, then submit the version for approval.
The measurement plan is the promise Impact will hold you to, so decide it before results exist to be flattered by.