How to Write a Strategic Term of Reference in 2026

Your program lead wants one version of the youth mentoring project. Your development director needs another for the grant narrative. Your board chair keeps asking who approves changes. Then a funder asks how you'll measure outcomes, over what timeline, and for which participants.

At that point, most nonprofits don't have a writing problem. They have a clarity problem.

A strong term of reference fixes that before the proposal draft starts. It gives your team one agreed version of the work: what the project is, what it is not, who owns which decisions, what success looks like, and what must be delivered. For small nonprofits, that kind of clarity isn't bureaucracy. It's protection. It keeps a good idea from turning into a vague promise you can't staff, measure, or defend in a grant application.

What Is a Term of Reference and Why Nonprofits Need One

A project can drift long before anyone notices. Staff use different language for the same program. A grant writer promises outcomes the program team never approved. A funder asks for a reporting plan, and everyone realizes there isn't one.

That's where a term of reference earns its keep.

A term of reference is the document that defines the purpose, scope, structure, and operating rules for a project, committee, initiative, or shared piece of work. In the United Nations system, Terms of Reference are used to establish the mandates of committees and coordination bodies. The UN also describes a ToR as “a documented basis for making future decisions and for confirming or developing a common understanding of the scope among stakeholders” in its UN Terms of Reference guidance.

Why this matters in grant seeking

Most nonprofit teams first encounter the term of reference in consulting or evaluation settings. That's too narrow. In practice, an internal ToR is often the missing bridge between program design and grant readiness.

When a nonprofit has a working ToR before proposal writing starts, several things get easier:

• Program definitions stay consistent across the executive director, program staff, finance lead, and grant writer.
• Scope stays under control because the team can point to what is included and what is explicitly out of scope.
• Decisions move faster because approvals, roles, and escalation paths are already named.
• Grant narratives get sharper because objectives, beneficiaries, timelines, and deliverables are already agreed.

Many teams already utilize planning tools without labeling them a ToR. They might rely on a strategy memo, kickoff notes, or a plan of record for internal alignment. A term of reference is more disciplined. It transforms loose planning into a single operational document people can use.

Practical rule: If two people on your team would describe the same project differently, you need a ToR.

What a ToR is not

It's not a grant proposal. It's not a board policy. It's not a logic model, although it should align with one. And it's not a long technical report that sits untouched in a folder.

For nonprofits, the best ToR is usually plain language, decision-ready, and specific enough that a new staff member could read it and understand how the project works. If your team can't use it to settle a disagreement about scope, reporting, or responsibilities, it's too vague.

The Core Components of an Effective ToR

A useful term of reference has structure. Without that structure, teams produce one of two bad documents: a vague concept note or a bloated planning file nobody reads.

The easiest way to think about a ToR is this: it answers the operational questions a funder will eventually ask, but it answers them first for your own team.

Start with purpose and background

Open with the short version of why this work exists. Name the problem, the population, and the organizational reason this initiative matters now.

If you're drafting a ToR for a youth literacy program, don't write “to improve educational outcomes.” That's too broad. Write what the project exists to do in your setting. Keep it grounded in the service model your staff can deliver.

A strong background section usually includes:

• The need: What problem the program addresses
• The organizational context: Which team owns the work
• The trigger: New funding opportunity, pilot launch, expansion, partnership, or compliance need

Define objectives and scope

Weak ToRs usually fail at this point. Objectives tell people what you're trying to achieve. Scope tells them where the boundaries are.

A nonprofit team often writes objectives and stops there. That leaves too much room for drift. Scope needs to answer practical questions such as who is served, where services happen, what activities are included, and what the team will not do under this project.

A good scope section prevents “while we're at it” planning, which is how manageable programs become impossible ones.

Try a simple split:

Clarify roles, authority, and deliverables

This section keeps your team out of avoidable conflict. Name the project owner, decision-makers, contributors, reviewers, and any outside partners. If a consultant or evaluator is involved, define what they control and what stays internal.

For specialized projects, detail matters. The European Commission's guidance on evaluation ToRs shows just how specific these documents can become. It notes that ToRs may require evaluator qualifications such as a PhD in econometrics and 5+ years of experience, and can weight selection criteria 70% technical and 30% financial to protect methodological rigor in this guide to evaluation Terms of Reference. Most nonprofits won't need that level of technical screening for every project, but the lesson is useful: when the work is complex, your ToR should be exact.

Add method, timeline, and budget assumptions

This is the operational spine. How will the work happen? What are the milestones? What budget assumptions shape delivery?

For a direct-service nonprofit, this may include outreach methods, intake process, service cadence, reporting checkpoints, and staffing assumptions. For a planning or evaluation project, it may include data access, review stages, and draft approval windows.

A solid closing section should cover:

• Method or approach: How the work will be carried out
• Deliverables: What documents, reports, or outputs must be produced
• Timeline: Key stages and approval points
• Constraints: Capacity limits, grant restrictions, or dependencies
• Review process: Who signs off on revisions

If any one of those is missing, your proposal team will end up guessing later. That guesswork is expensive.

Drafting Your Term of Reference from Scratch

Teams frequently don't struggle because they lack intelligence. They struggle because they open a blank document and try to write a polished ToR alone.

Don't do that. Drafting a term of reference works better as a short working session followed by one writer turning group decisions into text.

Gather the right people before you draft

You don't need a large meeting. You need the people who can answer the essential questions.

Usually that means:

• Program lead: Owns delivery reality
• Development lead or grant writer: Knows how funders frame requirements
• Finance or operations lead: Flags staffing, procurement, and budget constraints
• Executive sponsor: Settles trade-offs when the group disagrees

If governance questions are fuzzy, it helps to look at adjacent documents too. For board and authority language, Alignmint's template for board bylaws is a useful reference because it shows how to name responsibilities, approvals, and oversight in plain English.

Draft by answering questions, not by chasing perfect prose

The first draft should come from a working outline. Ask the team direct questions and capture the answers.

Use prompts like these:

1. What problem are we solving?
2. Who is the project for?
3. What will we do?
4. What will we not do under this project?
5. Who approves changes?
6. What evidence will show the work is on track?
7. What must be delivered, and by whom?

That process is much faster than asking someone to “write the ToR.”

Use sentence starters to break the blank page

Plain language works best. You're not trying to impress a procurement office. You're trying to create shared clarity.

Here are sample starters that work:

• Purpose: “This project exists to…”
• Objective: “The initiative will deliver…”
• Target population: “The program is intended for…”
• Scope: “Activities included in this project are…”
• Exclusions: “This ToR does not cover…”
• Roles: “The program manager is responsible for…”
• Success indicators: “Progress will be assessed through…”
• Decision authority: “Any material change to timeline, staffing, or outputs must be approved by…”

If your team also needs to connect the ToR to outcomes and measurement, a logic model for program evaluation can help translate activities into outputs and intended results.

Write the hard boundaries first. Objectives are easy to agree on. Exclusions are where real alignment happens.

A quick training video can also help teams see how Terms of Reference are typically structured before they adapt the format to nonprofit work:

Build version one, then tighten it

Your first complete ToR doesn't need to be elegant. It needs to be usable.

Review it for three things:

Once those are in place, tighten the wording. Cut broad promises. Replace internal jargon. If a sentence could mean two different things, rewrite it until it can't.

Aligning Your ToR with Funder Requirements

A term of reference becomes strategically valuable when it stops being only an internal planning tool and starts acting as prewritten grant infrastructure.

That matters because funders rarely reward improvisation. They reward organizations that can show they know what they're doing, who they're serving, how they'll measure progress, and how they'll manage delivery.

Reverse-engineer the ToR from the grant opportunity

When you review an RFP or application guide, read it as a planning brief before you read it as a writing task. The strongest grant teams pull out the funder's hidden ToR requirements.

Look for language tied to:

• Eligible populations
• Required activities
• Expected outcomes
• Reporting and compliance
• Partnership expectations
• Time period and geographic limits

Then compare that against your internal ToR. Any mismatch is useful. It tells you whether the opportunity fits the program as designed or whether your team is about to force the program into a narrative it cannot naturally support.

Use the ToR to prove readiness

Funders want confidence that your organization can execute. A clean ToR helps because it shows the project isn't just an idea assembled for one deadline.

Research on scope and statistical reference values makes the same basic point in a different setting: “the criteria adopted in the study of reference values have a great influence on the statistical analysis of the data” and “to avoid a poor statistical treatment of the data, the scope of the study must be well defined.” That broader principle of clear scope carries into nonprofit operations, where Terms of Reference define the purpose and structures of people working toward a shared goal, as discussed in this PubMed record on scope definition and organizational clarity.

For grant seeking, that means your ToR should already answer questions such as:

• What outcomes are measurable
• Which population the program serves
• What geographic area is covered
• Who is accountable for delivery
• How changes are approved
• What evidence will support reporting

Funders can feel the difference between a project your team designed and a proposal your team assembled.

Turn one internal document into multiple proposal assets

A strong ToR shortens the path to draftable content. Parts of it can feed directly into your application package.

For example:

• Need and context can inform the program overview
• Objectives and scope can support the project description
• Roles and governance can strengthen the capacity section
• Deliverables and reporting expectations can support implementation and evaluation narratives

Small nonprofits gain a significant advantage through this approach. You don't need separate reinvention for every application. You need one disciplined internal document that your grant writer can adapt without distorting the program.

When the ToR is solid, proposals become translation work. When the ToR is weak, proposals become guesswork.

Common ToR Pitfalls and How to Avoid Them

Most bad Terms of Reference aren't bad because the team didn't care. They're bad because the team tried to stay flexible, polite, or fast. That usually produces ambiguity.

Ambiguity feels harmless in a draft. It becomes expensive once staff start working from it.

Vague language is not flexibility

If your ToR says the team will “support community outcomes,” nobody knows what must be delivered. If it says the project will “engage stakeholders as needed,” nobody knows who must be consulted or when.

In Monitoring and Evaluation work, vague language is tied to real downstream damage. Eval Community's guide to Terms of Reference notes that vague language can cause scope creep in 40% of cases, and misaligned evaluation questions can reduce the usability of the final report by 25%.

For nonprofits, the pattern is familiar even outside formal evaluation. Vague wording invites extra tasks, blurred ownership, and weak reporting.

The most common mistakes

Here's where nonprofit teams usually get into trouble:

• Undefined scope: The project sounds ambitious, but nobody has stated what is out of scope.
• Soft ownership: Multiple people are “supporting” the work, but no one is accountable for final decisions.
• Aspirational outcomes: The ToR promises results that the staffing model or timeline can't support.
• No change control: The team adds partners, outputs, or reporting demands without documenting who approved the shift.
• Copy-pasted language: Old grant language gets reused even when the program model has changed.

One overlooked cause is governance confusion. If approvals, recusals, or oversight expectations are muddy, project conflicts escalate faster. That's why it helps to keep related governance tools current, including a conflict of interest policy for nonprofits, so decision-making authority is cleaner when a project gets politically sensitive.

If your ToR avoids hard choices, your staff will make those choices later under deadline pressure.

What works better

Use a tougher editing standard. Read each section and ask whether an outsider could act on it without a follow-up meeting.

A practical quality screen looks like this:

Another fix is to test the document against live scenarios. Ask: What happens if staffing changes? What if a partner stops participating? What if the funder asks for a revised output schedule? If the ToR doesn't help the team answer those questions, it isn't finished.

The Final ToR Review and Approval Checklist

Before a term of reference gets used for project launch or grant development, run one final review. This step catches the gaps that create confusion later.

Use these questions as a hard gate, not a courtesy review.

Questions about clarity and scope

• Does the document state the project purpose in plain language?
• Are the objectives specific enough that staff would interpret them the same way?
• Is the target population clearly defined?
• Does the scope say what is included and what is excluded?
• Are geographic, timeline, and service boundaries named?

Questions about delivery and accountability

• Have roles been assigned to actual functions or positions, not vague groups?
• Does the ToR identify who can approve material changes?
• Are deliverables named clearly, with expected formats where relevant?
• Does the timeline include meaningful checkpoints, not just an end date?
• Do budget assumptions or capacity constraints appear anywhere they need to?

Questions about grant readiness and evidence

• Can the grant writer lift language from this document without rewriting the program from scratch?
• Are success indicators or reporting expectations defined clearly enough to support future funder reporting?
• Does the ToR align with related planning documents, including workplans and evaluation tools?
• Have legal, governance, or board-level implications been checked if the project involves partners or restricted funds?

For teams that want to strengthen documentation discipline before submission or audit season, this guide to effective evidence management is useful because it shows how to organize supporting records so decisions, approvals, and compliance evidence don't disappear after the proposal is filed.

A final review should answer one question: if the original project lead left tomorrow, could the next person run this project from the ToR?

If the answer is no, revise it before you submit the grant or launch the work.

A clear term of reference makes grant writing faster, cleaner, and less risky. Fundsprout helps nonprofits turn program plans into funder-ready proposals, stay on top of deadlines, and keep the documentation trail needed for compliance and renewals.