How to write a grant proposal that actually gets funded (template included)

The difference between a funded grant proposal and a rejected one usually isn't the quality of the idea — it's the quality of the writing. Grant reviewers evaluate hundreds of proposals per cycle, and most are eliminated for avoidable mistakes: vague objectives, misaligned scope, unrealistic budgets, or simply not following instructions. This guide walks you through every section of a grant proposal with a reusable template, real examples of strong and weak language, and specific advice from people who've sat on review panels. Whether you're applying for a $5,000 private foundation grant or a $275,000 SBIR award, the principles are the same. For a list of programs to apply to, see our best small business grants in 2026 roundup.

Before you write: the preparation that matters most

The most important work in grant writing happens before you type a single word. Skipping the preparation phase is the number one reason proposals get rejected — not because the writing is bad, but because the proposal doesn't match what the funder is looking for.

Read the entire solicitation document

This sounds obvious, but at least 30% of rejected proposals fail because the applicant didn't fully read or understand the solicitation. Every grant program publishes a solicitation (also called an RFP, RFA, or NOFO) that specifies: what they're funding, who's eligible, how proposals will be evaluated, what format to use, and what the deadline is. Read the entire document. Then read it again. Highlight the evaluation criteria — these are the exact rubric reviewers will use to score your proposal.

Understand the funder's priorities

Every grant-making organization has a mission. The NSF wants to advance science. The SBA wants to strengthen small businesses. The Eileen Fisher Foundation wants to support women-owned businesses focused on sustainability. Your proposal must demonstrate how your project advances the funder's mission — not just your business goals. Before writing, answer this question: "Why would this funder, specifically, want to fund my project?"

Contact the program officer

For federal grants, most solicitations list a program officer or point of contact. Email them a 2-3 paragraph summary of your idea and ask: "Does this align with the topics you're looking to fund?" This five-minute interaction can save you weeks of writing a proposal that doesn't fit. Program officers are not adversaries — they want to fund good projects and are happy to steer you toward the right solicitation.

Research previous winners

Many grant programs publish lists of past winners, including project abstracts. Study them. Note the language they use, the scope of their projects, and the types of organizations that win. For SBIR, the SBIR Award Database contains every award ever made — search by agency and keyword to find projects similar to yours.

Grant proposal template: section by section

The following template covers the standard sections found in most grant proposals. Federal grants (SBIR, NIH, NSF) have strict section requirements — follow their specific guidelines exactly. Private and corporate grants may use different formats, but the underlying content is the same. Adapt this template to match the specific requirements of your target program.

Section 1: Executive summary / project abstract

What it is: A one-page (typically 200–300 word) overview of your entire proposal. This is the first thing reviewers read, and often the only thing decision-makers who aren't on the review panel will see.

What to include: The problem you're solving, your proposed solution, why your approach is innovative, the expected outcomes, and the funding amount requested. Think of it as your elevator pitch in written form.

Template language:

Common mistake: Writing a vague summary that could describe any company. "We are an innovative company developing cutting-edge solutions for the healthcare industry" tells the reviewer nothing. Every word of your executive summary should be specific to your project.

Section 2: Statement of need / problem statement

What it is: A clear description of the problem your project addresses, supported by data and evidence. This section answers: "Why does this project need to exist?"

What to include: The scope and severity of the problem, who is affected, current solutions and their limitations, the gap your project fills, and citations to credible sources (peer-reviewed literature, government statistics, industry reports).

Template language:

Common mistake: Making the problem statement too broad. "Healthcare is expensive and inefficient" is true but useless. Narrow it down: "Rural hospitals with fewer than 25 beds spend an average of $2.3 million annually on manual patient transfer coordination, resulting in a mean delay of 4.2 hours."

Section 3: Project description / technical approach

What it is: The core of your proposal. This section describes exactly what you'll do, how you'll do it, and why your approach will work. For SBIR proposals, this is typically 10–15 pages.

What to include: Your technical approach (methodology, technology, process), how it differs from existing approaches, preliminary data or proof-of-concept results if available, risk mitigation strategies, and a timeline of activities.

Structure it clearly: Use subsections with descriptive headers. A good structure might be: Background and Innovation → Technical Approach → Specific Tasks → Expected Results → Risk Mitigation. Use figures, diagrams, and tables where they clarify complex concepts — a well-designed figure is worth 500 words of text.

Common mistake: Describing what you'll build but not how you'll build it or why your approach is better than alternatives. Reviewers want to see technical depth and a clear understanding of the challenges involved.

Section 4: Goals, objectives, and milestones

What it is: A structured breakdown of what you'll accomplish, when, and how you'll measure success. This section demonstrates that you've thought carefully about the project's execution.

What to include: Clear, measurable objectives using the SMART framework (Specific, Measurable, Achievable, Relevant, Time-bound). Break the project into milestones with specific deliverables and timelines.

Template language:

Common mistake: Vague objectives like "improve the product" or "increase efficiency." If a reviewer can't objectively determine whether you achieved the objective at the end of the project, it's not specific enough.

Section 5: Methods and evaluation plan

What it is: A description of the specific methods you'll use to execute the project and evaluate its success. This section proves you have a credible plan, not just an idea.

What to include: Detailed methods for each objective, data collection procedures, analysis approaches, success criteria (how you'll know the project worked), and contingency plans if things don't go as expected.

Common mistake: Omitting the evaluation plan entirely. Funders need to know how you'll measure success. For research grants, this means experimental design and statistical analysis plans. For business grants, this means KPIs and measurement methodologies.

Section 6: Budget and budget justification

What it is: A detailed financial plan showing exactly how you'll spend the grant funds, with a narrative justification explaining why each expense is necessary.

Standard budget categories:

Personnel: Salaries and fringe benefits for each team member. List each person by name (or role if TBD), their hourly rate or annual salary, the percentage of time dedicated to the project, and the total cost. Fringe benefits typically include health insurance, retirement contributions, and payroll taxes — use your actual rate or estimate 25–35% of salary.

Equipment: Items costing $5,000 or more per unit. Include make/model, unit cost, and justification for why you need it versus leasing or using existing equipment.

Travel: Conference attendance, customer visits, field work. Include destination, purpose, number of trips, and estimated costs for airfare, lodging, and per diem.

Materials and supplies: Lab consumables, software licenses, raw materials. Be specific — "miscellaneous supplies: $5,000" will be questioned.

Consultants and subawards: External expertise or subcontracted work. For STTR proposals, your research institution partner budget goes here.

Indirect costs: Overhead (rent, utilities, administrative support). Use your negotiated indirect cost rate if you have one; otherwise, use the de minimis rate of 10% of modified total direct costs.

Common mistake: A budget that doesn't match the scope of work. If your proposal describes building a complex prototype, but your budget only includes one engineer at 10% effort, reviewers will question feasibility. Conversely, a budget where 80% goes to salaries and 0% to materials for a hardware project is a red flag.

Section 7: Organizational background and key personnel

What it is: Proof that your team has the expertise and infrastructure to execute the project. This section answers: "Why should we trust this team to deliver?"

What to include: Brief organizational history and capabilities, biographical sketches of key personnel (education, relevant experience, publications, patents), description of facilities and equipment, and any previous grant awards or relevant project experience.

Common mistake: Generic biographical sketches that list every job someone has ever had. Focus on experience directly relevant to the proposed project. If your PI published papers on the exact topic of the proposal, highlight those specifically.

Section 8: Commercialization plan (for SBIR/business grants)

What it is: A description of how you'll turn grant-funded work into a sustainable business. This is increasingly important — funders want to invest in projects that will have lasting impact beyond the grant period.

What to include: Target market size and segmentation, competitive landscape analysis, pricing strategy, go-to-market plan, revenue projections (realistic, not hockey-stick), intellectual property strategy, and any existing customer interest or letters of support.

Common mistake: Presenting a TAM (Total Addressable Market) of $50 billion without explaining how a small business will capture even 0.01% of it. Reviewers want to see a credible path from your Phase I results to actual revenue — ideally including specific companies or organizations that have expressed interest.

Common mistakes that get proposals rejected

After reviewing hundreds of funded and rejected proposals, these are the patterns that consistently lead to rejection:

1. Not addressing the solicitation criteria. This is the number one rejection reason across all grant programs. If the solicitation lists five evaluation criteria, your proposal must address all five — ideally with section headers that mirror the criteria language. Don't make reviewers search for relevance.

2. Writing for yourself instead of the reviewer. You know your technology inside and out. The reviewer may have adjacent expertise but not deep domain knowledge. Define terms, explain why your approach is novel, and connect every claim to evidence. Don't assume the reviewer has read your papers or understands your jargon.

3. Vague goals and unmeasurable outcomes. "We will develop an innovative platform" is not a specific aim. Every goal must have a measurable success criterion. What specific performance metric will you achieve? By when? Compared to what baseline?

4. Unrealistic budgets. Budgets that are either too low (suggesting you don't understand the work) or too high (suggesting you're padding) both raise red flags. Every line item should be justifiable, and the total should be proportional to the proposed work.

5. Missing or incomplete required documents. Expired SAM.gov registration, missing letters of support, wrong file format, exceeding page limits, incorrect font size. These are automatic disqualifications in many programs. Use a compliance checklist before submitting.

6. Last-minute submissions. Proposals submitted hours before the deadline almost always have errors — formatting issues, missing sections, typos. Submit at least 48 hours early. Grants.gov and other submission systems can have technical issues at peak times.

7. No preliminary data. For research grants, preliminary data dramatically improves your chances. Even a simple proof-of-concept experiment, a simulation, or a literature analysis showing the feasibility of your approach gives reviewers confidence that your proposal is grounded in reality, not speculation.

8. Weak letters of support. A generic letter saying "we support this project" adds no value. Strong letters describe the specific relationship between the supporter and the project, the supporter's expertise or customer interest, and a concrete commitment (testing the product, purchasing if successful, providing access to facilities, etc.).

Tips from grant reviewers

These tips come from conversations with current and former reviewers for NIH, NSF, DOD SBIR, and several private foundation programs:

"Make it easy to score you." Reviewers read dozens of proposals in a review cycle. Use clear section headers that match the evaluation criteria. Bold your key claims. Use numbered lists and tables. If I'm looking for your evaluation plan and can't find it in 30 seconds, that's a problem.

"Show me you know the field." A competitive analysis isn't optional. I need to see that you understand what exists, why it's insufficient, and why your approach is different. A comparison table showing your solution vs. alternatives on 4-5 key metrics is extremely effective.

"Be honest about risks." Every project has risks. Proposals that acknowledge risks and present mitigation strategies are more credible than proposals that pretend everything will work perfectly. Include a risk matrix: Risk, Likelihood, Impact, Mitigation Strategy.

"Don't oversell." Claims like "this will revolutionize healthcare" without evidence make reviewers skeptical. Let the data speak for itself. Strong proposals make specific, evidence-backed claims rather than sweeping statements.

"Budget should tell a story." Your budget should reflect the project plan. If I read your technical approach and then look at your budget, the two should match perfectly. If you describe three major tasks but your budget only funds one, I'll question whether you can execute the other two.

If you're considering using AI tools to help with proposal drafting, Nesyona's review of AI writing tools covers which tools work best for business and technical writing. AI is useful for first drafts and editing, but the domain expertise and specificity that win grants must come from the applicant.

After submission: what happens next

Federal grants (SBIR, NIH, NSF): Your proposal enters a peer review process. A panel of 3–5 reviewers reads and scores your proposal against the published criteria. Reviews take 3–6 months. You'll receive reviewer comments regardless of the outcome — these are invaluable for improving future proposals.

Private foundation grants: Review processes vary widely. Some use expert panels similar to federal grants. Others have a small selection committee. Timelines range from 6 weeks to 6 months. Many private funders do not provide reviewer feedback for rejected applications.

If you're funded: Celebrate, then prepare for the administrative reality. Federal grants require quarterly progress reports, financial reports, and compliance with 2 CFR 200 (the Uniform Guidance). Set up proper financial tracking from day one — commingling grant funds with general business revenue is a common compliance violation.

If you're rejected: Read the reviewer comments carefully. Most rejections are fixable. Common feedback themes include: "good idea but not aligned with the solicitation topic," "insufficient preliminary data," "budget doesn't match scope," or "commercialization plan is weak." Address the feedback specifically and resubmit to the next cycle. Many funded proposals were rejected on their first submission.

The bottom line

A winning grant proposal isn't about having the best idea — it's about presenting a credible, well-aligned, clearly written case for funding. Read the solicitation criteria before you write anything. Use the template above to structure your sections. Have someone outside your team review the proposal before submission. And don't be discouraged by rejection — most successful grant recipients were rejected at least once before they won. The feedback you receive from reviewers makes every subsequent proposal stronger. For programs to apply to, see our best small business grants in 2026 guide. For federal grant specifics, check our federal grants for startups walkthrough.