Chapter 8: The Needs Assessment / Significance Section — Proving the Problem Is Real and Urgent

Two proposals open with the same problem. The first buries the reviewer in statistics — a dozen numbers about prevalence, cost, demographics, and trends, each cited, none connected, a wall of data that proves the writer did research but never quite says what the reviewer should conclude. The second uses three well-chosen numbers, each a link in a chain, that march the reviewer from "here is a real problem" to "here is who it harms and what it costs" to "here is why current approaches fall short" to the inescapable conclusion: "therefore, something like this project is necessary." The first proposal describes a problem. The second argues a need. The second wins, and it wins with less data, not more.

This chapter teaches you to write the second kind of section — the needs assessment (in the nonprofit and program world) or significance section (in the research world), two names for the same job: proving that the problem your project addresses is real, urgent, and important enough to fund. Your one-page pitch (Chapters 6–7) asserted a need in two sentences; this section proves it to a skeptical reader. We will build the logical chain that does the persuading, find the credible data that grounds it, analyze the gap your project fills, and learn to use statistics honestly — because a single fabricated or cherry-picked number can destroy the trust the whole section depends on.

This section carries a particular weight in the reviewer's decision. Recall from Chapter 2 that "does it matter?" is the second question a reviewer asks, right after "is it ours to fund?" — and it is the question that most often determines whether a feasible project is also a fundable one. A sound but unimportant project loses; an important one with a sound plan wins. The needs/significance section is where you win or lose the "does it matter?" question, which makes it, after the one-page pitch, among the highest-leverage sections in the proposal. Reviewers will forgive a good deal in the approach if they are convinced the problem genuinely matters; they will forgive nothing if they are not, because a project addressing a trivial or unproven need is, by definition, not worth funding. Get this section right and you have cleared the bar that most proposals fail.

8.1 Need Is an Argument, Not a Pile of Statistics

The most common failure in this section is to mistake data for argument. An anxious applicant, wanting to seem rigorous, gathers every statistic they can find and pours them onto the page, believing that more numbers mean a stronger case. The opposite is true. A reviewer confronted with an undifferentiated mass of statistics does not feel persuaded; they feel worked, and they cannot tell which numbers matter or what they are supposed to conclude. Data without argument is noise.

🚪 Threshold Concept: Need is an argument, not a pile of statistics. A reviewer is persuaded not by the quantity of data you cite but by the logical chain that leads, step by step, from a real problem to the inescapable conclusion that your project is necessary. Every statistic you include should be a link in that chain — doing a specific job in moving the reader from "there is a problem" to "this project is needed." A number that is not advancing the argument, however true and impressive, is clutter that dilutes the numbers that are. Your job is not to demonstrate that you can find data; it is to build a chain of reasoning, using the fewest, best-chosen numbers, that a reviewer cannot escape.

This reframes the whole task. You are not assembling a research report on the problem; you are constructing an argument with a conclusion ("fund this project"), and the data are your evidence, selected and arranged to compel that conclusion. The discipline is the same "so what?" test from Chapter 5: for every statistic, ask "so what — which step of my argument does this advance?" If it advances none, cut it, no matter how interesting. The strongest needs sections are often surprisingly lean: a few devastating, well-chosen numbers in a tight logical sequence, not an encyclopedia.

🗣️ From the Review Panel: When I read a needs section that is a wall of statistics, I skim it, because I cannot tell what I am supposed to take away — and skimming means the applicant's careful research washes over me without leaving a mark. When I read one built as a chain — problem, scale, consequence, why-current-efforts-fail, therefore-this — I follow it, I remember it, and I can repeat it to the panel. Three numbers I remember beat a dozen I skimmed. The applicants who think more data is safer have it exactly backwards: more data, less argument, is weaker, because it hides the few numbers that would have persuaded me inside a pile I tuned out.

There is a psychological reason applicants over-pile data, and naming it helps you resist. Statistics feel safe. Each cited number is a small shield against the fear of being challenged — "you can't say I didn't do my research." So the anxious writer keeps adding numbers, each one buying a little reassurance, until the section is armored in data and empty of argument. But the reviewer is not the threat the writer imagines; the reviewer is not looking for gaps in your data coverage, they are looking for a reason to fund you, and a reason is an argument, not a database. The shift this section asks of you is from a defensive posture (prove I did the research) to a persuasive one (lead the reviewer to a conclusion). Once you make that shift, you stop asking "what other statistics should I add?" and start asking "what is the cleanest chain of evidence that compels my conclusion?" — and the section gets shorter, sharper, and far more convincing.

8.2 The "So What?" Chain

🧩 Productive Struggle: Before reading the chain, try this. Take a problem you care about and imagine the most skeptical possible reviewer responding to each claim you make with a flat "so what?" You say "this problem exists." So what? You say "it affects a lot of people." So what? Keep going until the skeptic runs out of "so what?"s and is forced to agree your project is needed. The sequence of answers you are forced to give is the so-what chain. Doing this for your own project before reading the formal version will make the structure feel like common sense rather than a template — because it is exactly the reasoning a skeptic would demand.

The argument that proves a need follows a reliable logical sequence — call it the so-what chain — that you can build deliberately. Each link answers the "so what?" a skeptical reviewer would pose to the one before it.

1. The problem exists. State the specific problem, concretely. (So what?)
2. It affects this many people. Establish the magnitude — how many are affected, in your target population and place. (So what?)
3. It causes this harm / costs this much. Establish the severity and cost — the human and economic consequences. This is what makes the problem matter, not just exist. (So what?)
4. Current approaches are insufficient because… Establish the gap — what is being done now and why it fails to solve the problem (Section 8.4). (So what?)
5. Therefore, a new approach — like this project — is necessary. The conclusion the chain compels, setting up your solution.

Notice that the chain is not "here are facts about the problem"; it is a sequence of claims each answering the previous one's "so what?", ending at your project's doorstep. Notice too that the most-skipped link is the third (consequence/cost) and the fourth (insufficiency). Applicants often prove that a problem exists and affects many people, then jump straight to their solution — skipping the steps that establish why the problem matters and why existing efforts don't already handle it. Those two links are where weak needs sections collapse, because a reviewer who is not shown the consequence asks "but is this actually a big deal?", and one who is not shown the insufficiency asks "but isn't someone already addressing this?"

📋 Template — The so-what chain: Draft one or two sentences for each link, in order: - Problem: "[Specific problem] affects [population] in [place]." - Magnitude: "[N or %] of [population] experience this — [comparison that shows it's disproportionate or large]." - Consequence/cost: "This results in [human harm] and costs [economic figure / opportunity lost]." - Insufficiency: "Current approaches — [what exists] — are insufficient because [specific limitation: reach, cost, design, access]." - Necessity: "Therefore, [the kind of solution your project is] is needed to [close the gap]." If any link is missing or weak, that is where a reviewer's doubt will enter.

🔍 Why Does This Work?: Why does the chain persuade where a pile of data does not? Because persuasion is about inference, not information. A reviewer does not fund a problem; they fund a conclusion — that this project is necessary. The chain walks them through the inferences that lead to that conclusion, so they arrive at it themselves, which is far more convincing than being told. By the time a reviewer has accepted that the problem is real (link 1), large (link 2), harmful (link 3), and unaddressed by current efforts (link 4), the necessity of your project (link 5) feels not like your claim but like their own deduction. Data dumped on the page leaves the inference to the reader and most won't bother; the chain does the inferring for them.

To see the chain built, here is RYCC's so-what chain for its coding-program expansion (composite; figures illustrative). Problem: "Middle-schoolers in our neighborhood have almost no access to computer-science education." Magnitude: "Fewer than one in ten students at the three target schools — serving roughly 900 students total — has access to any CS coursework, compared with [higher state figure], a gap concentrated in our lowest-income census tracts." Consequence: "Without early exposure, these students are far less likely to enter high-school CS tracks or the regional tech economy, which is adding jobs faster than local schools produce qualified candidates — foreclosing a documented pathway out of poverty." Insufficiency: "The district offers CS only at two magnet schools across town, inaccessible to our students by distance and selective admission; no free, neighborhood-based option exists." Necessity: "A free, school-based coding program in these three neighborhood schools is therefore needed to close the access gap." Five links, a handful of numbers, and a reviewer arrives at RYCC's project as the obvious answer. Compare that to the same facts dumped as a paragraph of disconnected statistics, and you feel why the chain wins.

🔄 Check Your Understanding: Which two links of the so-what chain are most often skipped, and what reviewer doubt does skipping each one invite?

Answer

The consequence/cost link (link 3) and the insufficiency/gap link (link 4). Skipping consequence invites "but is this actually a big deal?" — the problem is shown to exist but not to matter. Skipping insufficiency invites "but isn't someone already addressing this?" — leaving your project looking potentially redundant. Both are where weak needs sections collapse.

8.3 Finding Credible Data

A chain is only as strong as its evidence, and credible evidence comes from credible sources. Part of the skill of this section is knowing where to find authoritative data — and citing it, so a reviewer can trust and verify it. Here are the workhorses, by type.

📋 Data sources for needs/significance (U.S.-focused; verify current access): | Source | What it gives you | |---|---| | U.S. Census Bureau / American Community Survey (ACS) | Population, demographics, income, education, housing — by geography down to neighborhoods | | CDC WONDER, BRFSS, and CDC data portals | Health conditions, mortality, risk behaviors — national to county level | | Bureau of Labor Statistics (BLS) | Employment, wages, occupational data and projections | | NIH RePORTER / PubMed / peer-reviewed literature | Scientific evidence of the problem and prior work (essential for research significance) | | Federal/state agency data (ED, HUD, DOJ, SAMHSA, etc.) | Sector-specific statistics tied to the relevant funder's domain | | Local sources — community needs assessments, school/district data, hospital community-health needs assessments, local government reports | The local face of the problem, often the most persuasive of all | | Reputable nonprofits and research orgs (e.g., Pew, KFF, Annie E. Casey, Urban Institute) | Synthesized data and analysis (cite carefully; note their methods) |

The single most persuasive move in a needs section is to pair national context with local specificity: a national or state statistic establishes that the problem is real and recognized, and a local statistic shows that it is acute in your community, where your project will act. "Nationally, X% of adults face this; in our county, the figure is Y%, well above the state average" is far more compelling than either number alone — the national figure gives credibility, the local figure gives urgency and shows you know your community. For research significance, the equivalent move pairs the broad importance of the problem with the specific gap in current knowledge (Section 8.4).

The national-plus-local move also protects you from a common reviewer objection: that your sense of the problem is anecdotal or parochial. An applicant who cites only their own observations ("we see this every day in our work") may be entirely right but sounds unverifiable; an applicant who cites only national figures may be describing a problem that does not actually apply to their community. Pairing the two — authoritative national/state data to establish the problem is real and recognized, then local data to show it is acute here — answers both objections at once. It says, in effect: "this is a documented problem the field takes seriously, and it is hitting my specific community hard." When local data is genuinely unavailable (small communities sometimes lack it), be honest: lead with the national/state figure, then supply the local picture with attributed, qualitative evidence (Tier 2: "local providers and our own intake data indicate…"), clearly labeled as such. A reviewer respects an honest "here is the national number and here is what we observe locally" far more than a fabricated local statistic.

✅ Best Practice: Cite every statistic, with enough specificity that a reviewer could find it (source, year, and ideally the specific table or report). This does three things: it lets a skeptical reviewer verify your claim, it signals rigor and honesty, and it protects you from the appearance of having invented a number. Uncited statistics read as either careless or fabricated, and both destroy trust. A well-cited need section quietly tells the reviewer "everything here is real and checkable" — which is exactly the impression you want when you are asking them to believe your problem is worth their money.

⚠️ Common Pitfall: Using outdated or mismatched data. A statistic from fifteen years ago may no longer hold; a national figure presented as if it were local may mislead; a statistic about a broad population presented as if about your specific target group is a subtle misrepresentation. Reviewers who know the area will catch these, and a caught data error contaminates trust in your whole section. Use current data, match the geography and population to your claim, and when you must use an older or broader figure, say so honestly ("the most recent available data, from [year]…").

📊 From the Field — finding the local number: The local statistic that makes a needs section vivid is often hiding in a document you did not know existed. Every nonprofit hospital must publish a Community Health Needs Assessment (CHNA) every three years — a goldmine of local health and social data, free online. School districts publish enrollment, demographic, and performance data. City and county governments, United Ways, and community foundations commission community needs assessments. State agencies publish county-level data dashboards. And the Census Bureau's tools (data.census.gov) let you pull demographic and economic figures down to the census-tract level — often more local than your project's service area. The work of a strong needs section is frequently not statistical analysis but document archaeology: finding the report where someone has already assembled the local data you need, and citing it. Budget time early (Chapter 4) to dig these up; the local number that makes a reviewer feel the problem in your community is worth the search.

For a research significance section, the "data" is largely the peer-reviewed literature, and using it well is its own skill. You are not just citing papers to show you have read them; you are constructing the state of knowledge — what is established, what is contested, and precisely what is not yet known — so that your gap (Section 8.4) appears as the natural next question the field must answer. This means citing the right literature: the foundational work that establishes the problem's importance, the recent work that defines the current frontier, and, crucially, the work closest to your own that a reviewer will expect you to know (omitting a key recent paper in your exact area signals you are not current, a serious credibility hit). Reviewers in your field are the authors of much of this literature, so cite generously and accurately — and frame the gap not as "no one has studied this" (almost always false and easily refuted) but as "despite [what is known], [specific question] remains unresolved," which credits the field while carving out your contribution. The significance section is, in part, a demonstration that you command your literature; a thin or dated bibliography undermines it regardless of how good the argument is.

8.4 The Gap Analysis

The fourth link in the so-what chain — why current approaches are insufficient — deserves its own treatment, because it is where applicants most often fall short and where reviewers most often probe. This is the gap analysis: a clear-eyed account of what is already being done about the problem, what those efforts achieve, and what they miss — the gap your project fills.

The gap analysis matters because every reviewer silently asks, "if this problem is so real and important, why isn't it already solved? What makes this project necessary rather than redundant?" If you do not answer, you invite the most deflating of all critiques: "this duplicates existing efforts." A strong gap analysis preempts it by showing that you know the landscape and that there is a real, specific hole in it.

The shape of the gap analysis varies by world:

• For research (significance): the gap is in knowledge. You review what is known and established, then name precisely what is not known — the specific question current science cannot answer — and show that filling it matters. "Despite [established findings], it remains unknown whether [specific gap], a gap that limits [progress/treatment]." This is the significance section's version of the aims-page gap (Chapter 6), developed at length and grounded in the literature.
• For programs (needs assessment): the gap is in services or outcomes. You describe what services or efforts currently exist for the problem, then show where they fall short — in reach (not enough people served), access (barriers exclude your population), design (existing approaches don't fit the need), or results (current efforts aren't working). "While [existing services] serve [some], they reach only [fraction], leaving [your population] without [what they need]."

The four kinds of program gap are worth knowing by name, because naming yours precisely strengthens the analysis. A reach gap means the right service exists but serves too few — there is a waiting list, or capacity covers a fraction of need. An access gap means the service exists but barriers (distance, cost, language, eligibility, stigma, hours) exclude your population even though they technically qualify. A design gap means existing services do not fit this population's actual needs — a program designed for one group fails another, or addresses a symptom rather than a cause. A results gap means services exist and are used but are not working — outcomes are poor despite effort. Each implies a different project: a reach gap calls for expansion, an access gap for removing barriers, a design gap for a better-fitted approach, a results gap for innovation. Identifying which gap yours is does double duty: it sharpens the needs argument and it justifies the specific shape of your project (which must, per Section 8.7, be the thing that fills that exact gap).

📋 Template — The gap analysis: (1) What exists: name the current efforts/knowledge addressing this problem (showing you know the landscape). (2) What they achieve: credit what they do well (this builds your credibility — you're not dismissing others). (3) What they miss: name the specific gap — in reach, access, design, results, or knowledge. (4) Why it matters: show that the gap is consequential and that your project is positioned to fill it. Crediting existing efforts before naming the gap is important: it signals fairness and expertise, and it makes your gap claim more credible than a dismissive "nothing is being done" (which is rarely true and easy to refute).

A worked example shows the difference crediting makes. Weak (dismissive): "Nothing is currently being done to address food insecurity in our area, so our program is desperately needed." A reviewer who knows the area immediately distrusts this — there is always something being done (a food bank, SNAP, a church pantry) — and the overclaim makes the applicant look uninformed. Strong (gap analysis): "Our county is served by a regional food bank and federal nutrition programs, which together provide [credit: emergency food to thousands monthly]. However, these address acute hunger, not the underlying lack of affordable fresh food in our neighborhood, which has no grocery store within two miles [the specific gap]; emergency boxes and shelf-stable goods do not change the daily food environment that drives diet-related disease [why the gap matters]. Our project fills this specific gap by [your solution]." The strong version credits real efforts (building credibility), names a precise gap those efforts leave (not "nothing," but a specific missing piece), and shows the gap is exactly what the project addresses. A reviewer trusts this applicant because they clearly know the landscape and are claiming something specific and true, not something sweeping and false.

🔄 Check Your Understanding: An applicant's needs section proves a problem is widespread and harmful, then jumps to "our program will address this." A reviewer writes in the margin, "Isn't the county already funding three programs for this?" Which link of the so-what chain did the applicant skip, and how should they fix it?

Answer

They skipped link 4 — the insufficiency / gap analysis. They proved the problem exists, is large, and is harmful, but never addressed what current efforts do and why they fall short, leaving the "isn't someone already doing this?" question open. Fix: add a gap analysis crediting the existing three programs, then showing the specific gap they leave (e.g., they serve a different age group, or reach only a fraction, or lack a component your project provides) — establishing that your project is necessary, not redundant.

🗣️ From the Review Panel: The gap analysis is where I separate applicants who know their field from those who do not. When someone writes "nothing is being done about this," I know they either haven't looked or are overclaiming — because something is always being done — and my trust drops. When someone credits the existing efforts accurately and then names a specific, real gap those efforts leave, I think "this person knows the landscape, and they've found a genuine hole in it." That impression carries forward: an applicant who clearly understands the existing ecosystem is one I trust to execute within it. The gap analysis is not just an argument for your project; it is a demonstration of your expertise. Skipping it, or faking it with "nothing is being done," forfeits both.

8.5 Using Statistics Honestly

A needs section lives or dies on trust, and trust is destroyed instantly by the misuse of data. The book's citation-honesty system (introduced in CONTRIBUTING and Chapter 3) applies here with full force, because this is the section most tempted toward dishonesty — the temptation to make the problem look worse, or your solution more necessary, than the evidence supports.

Three abuses to avoid absolutely:

• Fabrication. Never invent a statistic, or state a number with precision you do not have. "73% of residents lack access" when you do not have that figure is a fabrication, and if a reviewer who knows the area senses it is invented, your entire proposal is suspect. When you do not have a precise number, use an honest qualitative claim or an attributed estimate (Tier 2: "community providers report that access is severely limited").
• Cherry-picking. Selecting only the statistics that support your case while ignoring those that complicate it is a subtler dishonesty, and reviewers who know the field notice the omissions. If the data are genuinely mixed, acknowledge it and make your case on the balance — a reviewer trusts an applicant who engages the complexity far more than one who pretends it away.
• False precision and misleading framing. "Crime increased 100%" sounds alarming until the reviewer learns it went from one incident to two. Percentages without base rates, scary-sounding framings of small absolute numbers, and national figures dressed as local all mislead, and all corrode trust when caught. State numbers in the framing that is honest, even when a more alarming framing is available.

📜 How We Got Here: Why are reviewers so unforgiving of data dishonesty? Because the entire grant system runs on trust they cannot fully verify. A reviewer cannot check every claim in every proposal; they extend a baseline of trust and look for signals that it is warranted or betrayed. A single caught exaggeration is a powerful betrayal signal — it tells the reviewer "this applicant will shade the truth to get funded," which casts doubt on every other claim, including the ones in your approach and budget they cannot check. This is why honesty in the needs section is not just ethics but strategy: your credibility is a single asset spent across the whole proposal, and the needs section, dense with checkable claims, is where it is most easily lost. Guard it.

Watch how the same true facts can be framed honestly or misleadingly. Suppose youth arrests in your area rose from 8 to 12 last year. Misleading: "Youth crime surged 50% in a single year" — technically true, but the percentage on a small base manufactures alarm a reviewer will resent once they see the absolute numbers. Honest: "Youth arrests rose from 8 to 12 last year, part of a three-year upward trend, and our service providers report rising demand they cannot meet" — the real numbers, in context, plus an honest attributed claim (Tier 2) where precise data run out. The honest version is more persuasive to a sophisticated reviewer, because it reads as trustworthy rather than manipulative, and it does not hand a skeptic the easy refutation ("12 arrests is hardly a surge"). The lesson generalizes: whenever you feel the pull toward the more alarming framing, reach instead for the honest one stated as compellingly as the truth allows. Real problems are serious enough; inflating them only gives a reviewer a reason to distrust you.

🔄 Check Your Understanding: You want to claim a local need but the only precise data you can find is national. What are your honest options, and which is not acceptable?

Answer

Honest options: (a) cite the national/state figure to establish the problem and pair it with attributed, qualitative local evidence clearly labeled as such (Tier 2: "local providers report…", "our intake data suggest…"); (b) present the national figure and state honestly that local data is unavailable; (c) gather local data yourself (a small survey, intake records) and cite it. Not acceptable: inventing a precise local statistic, or presenting the national figure as if it were local. Fabrication and misrepresentation destroy the trust the whole proposal depends on.

🪞 Learning Check-In: As you write your needs section, you will feel a pull to make the problem sound as dire as possible — to reach for the scariest number, the most alarming framing, the statistic that omits the inconvenient context. Notice the pull, because it is the pull toward the abuses above, and it is self-defeating. The reviewer is not moved by alarm; they are moved by a credible, well-reasoned case, and they are repelled by the sense of being manipulated. The discipline is to make the honest case as compellingly as possible — which, done well, is plenty compelling, because real problems are genuinely serious and do not need inflating.

8.6 Significance vs. Needs Assessment: Same Logic, Two Worlds

The research significance section and the program needs assessment are the same argument in different dialects, and seeing the parallel lets you move between worlds. Both establish that the problem matters and that current efforts/knowledge leave a gap your project fills. The differences are of emphasis:

• A significance section (research) emphasizes the importance of the scientific question and the gap in knowledge. Its magnitude is often the scope of the scientific or clinical problem; its consequence is what we cannot do or treat without the knowledge; its gap is what current science does not yet know; its conclusion is that answering the question would meaningfully advance the field or improve health. It leans heavily on the peer-reviewed literature.
• A needs assessment (program) emphasizes the human problem and the gap in services or outcomes. Its magnitude is the number of people affected; its consequence is the human and economic harm; its gap is what current services miss; its conclusion is that the proposed program is needed. It leans on demographic, health, and local community data.

💡 Key Insight: Whichever you are writing, the underlying chain is identical — problem, magnitude, consequence, insufficiency, necessity — and the threshold concept holds: it is an argument, not a data pile. A researcher writing significance and a nonprofit writing a needs assessment are doing the same intellectual work, aimed at the same goal: making the reviewer conclude, through a chain of evidence, that the problem is real and important and that this project is the necessary response. Learn the chain once and you can write either.

Here is Dr. Hernandez's significance chain, to show the research dialect (composite; figures illustrative). Problem: "Medication nonadherence is a leading, modifiable driver of poor outcomes in Type 2 diabetes." Magnitude: "Roughly half of patients are nonadherent, and adherence-related complications account for a large share of diabetes morbidity and cost [cited]." Consequence: "Nonadherence drives avoidable hospitalizations, complications, and billions in cost — and, critically for the field, undermines otherwise-effective therapies." Insufficiency (knowledge gap): "Numerous adherence interventions have shown efficacy, but the literature shows they are largely too costly or staff-intensive to scale, and it remains unknown whether a low-cost, fully automated text-message approach can achieve comparable adherence gains in routine care." Necessity: "Determining whether a scalable digital intervention improves adherence and glycemic control would fill this gap and provide a deployable tool — significant for both science and practice." Notice it is the same chain as RYCC's, but the magnitude and consequence are framed around the scientific/clinical problem and the gap is a gap in knowledge (grounded in the literature) rather than in services. Same architecture, research clothes.

🔄 Check Your Understanding: A nonprofit grant writer is asked to write a research significance section for a university partner, and a researcher is asked to write a needs assessment for a community program. What transfers directly between the two tasks, and what must each learn anew?

Answer

What transfers: the so-what chain (problem → magnitude → consequence → insufficiency → necessity), the threshold concept (argument, not data pile), the honesty discipline, and the requirement that the gap match the project. What each must learn anew: the data sources and dialect — the researcher must ground a community need in demographic/health/local data and service gaps; the nonprofit writer must ground significance in the peer-reviewed literature and a knowledge gap, and command the relevant scholarship. The architecture is shared; the evidence base and vocabulary differ.

8.7 Connecting the Need to Your Project

A final discipline, and a surprisingly common failure: the need you establish must be the need your project actually addresses. It is possible to write a brilliant, devastating needs section that proves a problem your project does not solve — and a reviewer who notices the mismatch is left worse off than if you had argued a smaller need that fit. This is the coherence principle from Chapter 5 applied to the needs section: the need sets up the solution, and the solution must answer this need.

Concretely, the gap you name in your gap analysis should be precisely the gap your project fills. If your needs section proves a gap in access but your project improves quality, the section is arguing for a different project than the one you are proposing. Before you finalize the needs section, check it against your aims or executive summary: does the need I have proven lead specifically to the project I am proposing? Does my gap analysis name the gap my project fills? If not, either reshape the need to fit the project or reconsider whether your project actually addresses the need you most care about. The need and the project must be two ends of one argument.

A concrete mismatch makes the danger vivid. Suppose a nonprofit's needs section brilliantly documents that their community is a food desert — no grocery store for miles, residents dependent on convenience stores, measurable diet-related disease. It is a devastating, well-evidenced case. But their proposed project is a nutrition-education program — cooking classes and healthy-eating workshops. A sharp reviewer sees the mismatch immediately: the need proven is a food-access problem (there is no fresh food to buy), but the project addresses a knowledge problem (how to eat well) — and you cannot cook fresh vegetables you cannot obtain. The needs section, however strong, argues for a different project (a grocery co-op, a mobile market) than the one proposed. The fix is one of two: either reshape the need to match the project (document a knowledge/skills gap that education addresses — perhaps residents do have some access but lack the skills or habits to use it), or reconsider whether the project actually addresses the community's most pressing need. Either way, the need and the project must point at the same gap. A needs section that proves the wrong need is worse than a modest one that proves the right need, because the mismatch makes the reviewer doubt that the applicant understands their own problem.

Step back and see how this section fits the proposal as a whole. The needs/significance section is the second beat of your argument's spine: the one-page pitch (Chapters 6–7) named the need; this section proves it; and the approach (Chapter 9) will answer it. Each must agree with the others — the need you prove here must be the need your pitch asserted and the need your approach addresses. Written well, this section does three things at once: it wins the reviewer's "does it matter?" question, it demonstrates your command of the problem and its landscape, and it sets up your project as the necessary response. Written as a data dump, it does none of them — it merely proves you can find statistics, which is not a question anyone is asking. The discipline of this chapter, in one line: build the fewest-best-numbers chain that marches a skeptic from "there is a problem" to "this project is necessary," keep every link honest, and make sure the gap you prove is the gap your project fills.

📐 Project Checkpoint — Draft your needs/significance section: For your project and funder, draft the needs (or significance) section. (1) Build the so-what chain: write the problem, magnitude, consequence/cost, insufficiency, and necessity links in order, each as a claim answering the previous "so what?". (2) Ground it with at least three cited data points from credible sources (Section 8.3), pairing national/context data with local/specific data where you can. (3) Write a gap analysis that credits existing efforts and names the specific gap your project fills. (4) Run the honesty check: is every number cited, current, correctly framed, and matched to its population/geography? (5) Run the coherence check: does the need I proved lead specifically to my project, and does my gap match the gap my project fills? Save it in your "My Proposal" document — it is the evidence base your whole proposal stands on.

Spaced Review

Retrieve these from earlier chapters without looking back.

1. (From Chapter 7) Your executive summary stated a need in a sentence or two. How does this chapter's section relate to that statement, and what does each require?
2. (From Chapter 6) The aims page had a "gap." How does this chapter's gap analysis relate to it, and how does the research significance section develop it?
3. (From Chapter 3 / CONTRIBUTING) What is the three-tier citation system, and how does it apply to using statistics in a needs section?

Answers

1. The summary asserted the need briefly to a busy reader; this section proves it to a skeptical one with a logical chain and cited evidence. The summary requires compression and persuasion; the needs section requires argument and evidence — and they must be consistent (the summary's need is this section's conclusion). 2. The aims-page gap is the same gap, stated in one sentence; the significance section develops it at length, grounded in the literature — reviewing what is known and naming precisely what is not. 3. Tier 1 = verified sources you cite (use for real statistics); Tier 2 = attributed claims ("providers report…") when you lack a precise figure; Tier 3 = illustrative/composite examples, clearly labeled. In a needs section, cite real data (Tier 1), attribute honestly when you lack precision (Tier 2), and never fabricate or present a composite as real data.

Chapter Summary

Key Takeaways

• Need is an argument, not a pile of statistics (threshold concept). Reviewers are persuaded by a logical chain, not by data quantity. Every statistic should be a link in the chain; cut the rest.
• The so-what chain: problem exists → magnitude → consequence/cost → current approaches insufficient → therefore this project is necessary. The most-skipped links are consequence and insufficiency — where weak sections collapse.
• Ground the chain in credible, cited data (Census/ACS, CDC, BLS, peer-reviewed literature, agency and local sources). Pair national context with local specificity. Cite everything so a reviewer can verify it.
• The gap analysis answers "why isn't this already solved?" Credit existing efforts, then name the specific gap — in knowledge (research) or reach/access/design/results (programs) — that your project fills.
• Use statistics honestly. Never fabricate, cherry-pick, or use false precision/misleading framing. Trust is a single asset spent across the whole proposal; the needs section is where it is most easily lost.
• Significance (research) and needs assessment (program) are the same chain in different dialects. Learn it once.
• Connect the need to your project: the gap you prove must be the gap your project fills (coherence, Chapter 5).

Action Items

• Build your so-what chain, link by link.
• Gather at least three cited data points (national + local).
• Write a gap analysis that credits others and names your specific gap.
• Run the honesty and coherence checks.

Common Mistakes to Avoid

• A wall of statistics with no argument.
• Skipping the consequence/cost and insufficiency links.
• Uncited, outdated, mismatched, or cherry-picked data.
• Proving a need your project doesn't actually address.

Decision Framework: Is your needs section ready?

Ask: (1) Can a reader follow a chain from problem to "this project is necessary"? (2) Are the consequence and insufficiency links present and strong? (3) Is every statistic cited, current, and honestly framed? (4) Does the gap analysis credit others and name your specific gap? (5) Does the need lead specifically to your project? Any "no" is your next revision.

Looking Ahead

You have proven the problem is real and that a gap exists. Now you must prove you can fill it. Chapter 9: The Project Narrative / Research Approach is the longest and most detailed section of the proposal — the plan that makes a reviewer believe you can actually do the work. You will learn to present methods and activities credibly without losing the reader, to show preliminary data effectively, to address weaknesses before the reviewer raises them (the "pitfalls and alternatives" strategy), and to make clear what is innovative about your approach. The need you established here sets the stage; the approach is where you prove you can answer it.

Continue to the Exercises, the Quiz, and the two Case Studies (1, 2). The Key Takeaways card is your quick-review anchor.

Next: Chapter 9 — The Project Narrative / Research Approach: The Detailed Plan That Proves You Can Do This.