Building a stronger project description

Many drafts open with what the organization wants to do. Reviewers are usually assessing whether it should be done. Describe the situation first: who is affected, where, and what the consequence is if nothing changes.

• State the problem in specific, local terms
• Identify who experiences it
• Show scale, using whatever data you legitimately hold
• Explain what currently exists and why it is insufficient

Vague activity descriptions are among the most common weaknesses. A reviewer should be able to picture the work happening.

• What will be delivered, in plain terms
• How often, and for how long
• Where it will take place
• Who will deliver it, and with what qualifications or experience
• How many participants are expected, and how they will be reached

Compare "we will offer employment supports" with "we will run twelve two-hour workshops over six months at our east-end site, for an expected forty participants referred through three partner agencies." The second can be assessed; the first cannot.

Outputs are what you produce: sessions delivered, people served, materials distributed. Outcomes are what changes as a result: skills gained, access improved, isolation reduced.

Applications often list outputs and label them outcomes. State both, keep the outcome claims proportionate to the size of the project, and avoid implying results the project cannot reasonably produce on its own.

An outcome claim invites an obvious question: how will you measure it?

• What will be measured
• How the data will be collected, and by whom
• When it will be collected
• How results will be reported

A modest evaluation approach that the organization can genuinely deliver is stronger than an ambitious framework that will not survive contact with staff capacity.

Reviewers frequently read the budget against the description. Every significant activity in the narrative should be visible in the budget, and every significant budget line should be explained by the narrative. Staffing levels, participant numbers and timelines should match across both.

Where an application provides numbered questions, answer them in order and in the funder's own terms. Reuse the vocabulary of the guidelines. Respect word limits, and use headings that mirror the assessment criteria where the form allows it.

Repurposed text from a previous application is a common source of mismatch. If you reuse material, reread it against the current questions before submitting.

• Prefer short sentences and concrete nouns
• Expand acronyms on first use
• Remove sector jargon that a non-specialist reviewer may not share
• Cut adjectives that make a claim without evidence — innovative, transformative, unprecedented
• Read the draft aloud once; sentences that are hard to say are usually hard to follow

• Can a reader unfamiliar with your organization follow the logic from need to outcome?
• Is every claim supported by something you could produce if asked?
• Do the numbers agree across narrative, budget and attachments?
• Have all questions been answered within their limits?
• Has someone outside the project team read it?