# Deliverables in a Grant Proposal Timeline: Step-by-Step Guide By the end of this guide you will be able to define the deliverables in a grant proposal timeline, schedule them backward from your submission or award dates, and write a deliverables section that a reviewer can verify line by line. You will also build a tracking system you can keep using after the award arrives. Before you start, have these on hand: - The funding announcement or request for proposals (RFP), which is the sponsor document that states what applicants must submit and what awardees must produce - Your draft specific aims page and project narrative - A spreadsheet program such as Excel, Google Sheets, or LibreOffice Calc - Your anticipated submission deadline and, if the announcement lists them, the sponsor's reporting dates - The names and roles of everyone who will contribute to the application, including your sponsored programs office or grants administrator ## What a Deliverable Is (and What It Is Not) A deliverable is a tangible, verifiable product that your project must produce and hand over to the funder, a collaborator, or the public. A progress report submitted to the sponsor is a deliverable. A dataset deposited in a public repository is a deliverable. A trained postdoc is not usually a deliverable, but a workshop the postdoc teaches can be one. Three related terms get confused constantly, so define them now and keep them separate in your proposal: - **Specific aims** are the scientific questions or goals. They describe what you want to learn. - **Milestones** are checkpoints along the way. They describe when you will know a phase is complete, for example "cohort enrollment reaches 100 participants by month 12." - **Deliverables** are the things you hand over. They describe what exists at the end, for example "a de-identified dataset of 100 participant records deposited in a curated repository by month 24." A reviewer reads aims to judge the science, milestones to judge your planning, and deliverables to judge your accountability. Every deliverable should map to at least one aim. Every milestone should lead toward at least one deliverable. If a milestone does not connect to something you hand over, a reviewer may read it as padding. ## Why Deliverables Matter in Grant Proposal Planning Sponsors use deliverables to do three things. First, they verify that the work happened, since a report or dataset is evidence in a way that "the experiment was successful" is not. Second, they schedule their own workload, because program officers and review panels need predictable points of contact. Third, they justify continued funding, since many multi-year awards include annual go or no-go decisions keyed to submitted deliverables. Good grant proposal planning treats deliverables as binding commitments, not aspirations. Once the award is executed, the deliverables listed in your proposal usually become part of the terms and conditions. Missing one can trigger a reduced award, a withheld installment, a required corrective action plan, or in serious cases a finding that affects your institution's standing with the sponsor. That is why the timeline you draft during proposal preparation needs to survive contact with reality. There is also a reviewer-facing reason. Reviewers read dozens of proposals and score research plans partly on feasibility. A timeline with concrete, dated, verifiable deliverables signals that the team has run a funded project before. A timeline with vague language such as "results will be disseminated throughout the project period" signals the opposite. ## Step-by-Step: Building Deliverables into Your Grant Proposal Timeline This walkthrough uses a worked example so you can see the arithmetic and the output at each stage. The example project is a two-year study with a submission deadline of June 1, 2026 and a proposed start date of January 1, 2027. Replace the dates and tasks with your own. ### Step 1. Extract every required deliverable from the announcement Read the funding announcement from beginning to end and list every product the sponsor requires from applicants and awardees. Common categories include the application itself, budget documents, letters of support, [data management](/blog/guides/data-management-basics-principles-processes-and-best-practices) and sharing plans, human subjects or animal welfare documentation, and post-award items such as annual reports and final reports. Make a two-column list in your spreadsheet: what the sponsor requires, and where in the announcement it appears. The second column matters because when a collaborator or administrator questions a requirement, you can quote the section. A representative list for a typical biomedical R01-style application looks like this: 1. Completed application package with narrative, budget, and biosketches 2. Budget justification 3. Letters of support from collaborators and institutional commitments 4. Data management and sharing plan 5. Human subjects protection or animal care documentation, if applicable 6. Facilities and resources description 7. During the award, annual Research Performance Progress Reports and a final report 8. During the award, dataset deposition and publications as specified in the sharing plan ### Step 2. Build a deliverables inventory Create a spreadsheet with these columns: ```csv deliverable_id,deliverable,funder_required,due_date,owner,status,evidence_of_completion ``` Then add one row per deliverable. The `evidence_of_completion` column is the one most people skip and the one that saves the most arguments later. It answers the question "how will we all agree this is done?" A filled example: ```csv deliverable_id,deliverable,funder_required,due_date,owner,status,evidence_of_completion D-01,Specific aims page,yes,2026-04-10,PI,in progress,PDF circulated to co-investigators D-02,Full research strategy draft,yes,2026-04-24,PI,not started,Complete draft shared with all senior personnel D-03,Letters of support,yes,2026-05-01,Co-I Martinez,not started,Signed letters saved in shared drive D-04,Budget and justification,yes,2026-05-11,Grants office,not started,Sponsor forms generated by grants office D-05,Data management and sharing plan,yes,2026-05-11,PI,not started,Plan inserted into application and archived D-06,Internal review draft,yes,2026-05-18,PI,not started,Reviewer comments compiled in one document D-07,Submitted application,yes,2026-06-01,Grants office,not started,Confirmation number from sponsor portal D-08,Year 1 dataset deposition,planned,2027-12-31,Co-I Chen,not started,Repository accession number D-09,Annual progress report,yes,2027-12-31,PI,not started,Sponsor acknowledgment of submitted report ``` Note the distinction in the `funder_required` column between `yes` (the sponsor demands it) and `planned` (you are volunteering it, for example a Year 1 dataset release that exceeds the minimum). Volunteered deliverables strengthen a proposal, but only commit to what you can produce. ### Step 3. Backward-plan the pre-award deliverables from the submission date ![Timeline of pre-award deliverables from kickoff at T-90 days to the June 1 2026 submission, with budget approval at T-21 days.](/article-images/illustrations/deliverables-in-grant-proposal-timeline-preaward-backward-plan.webp) Work backward from the sponsor's deadline, never forward from today. Institutional rules add friction that first-timers underestimate. Many universities require finalized budgets and routing slips five to ten business days before any sponsor deadline, and electronic submission portals can close hours before the sponsor's posted cutoff or slow down on deadline day. A practical backward plan for a June 1, 2026 deadline: ```python from datetime import date, timedelta submission_deadline = date(2026, 6, 1) tasks = [ ("Submitted application", 0), ("Final budget approved by grants office", 21), ("Internal review draft complete", 28), ("Letters of support collected", 31), ("Full research strategy draft", 38), ("Data management plan drafted", 38), ("Specific aims page drafted", 52), ("Kickoff meeting and task list", 90), ] for name, days_before in tasks: due = submission_deadline - timedelta(days=days_before) print(f"{due.isoformat()} T-{days_before:>3} {name}") ``` Running the script produces the pre-award schedule: ``` 2026-06-01 T- 0 Submitted application 2026-05-11 T- 21 Final budget approved by grants office 2026-05-04 T- 28 Internal review draft complete 2026-05-01 T- 31 Letters of support collected 2026-04-24 T- 38 Full research strategy draft 2026-04-24 T- 38 Data management plan drafted 2026-04-10 T- 52 Specific aims page drafted 2026-03-03 T- 90 Kickoff meeting and task list ``` The `days_before` values encode two rules. The budget gets three full weeks because it depends on other people's salary rates, fringe benefit figures, and institutional approvals that you do not control. The aims page gets the longest lead time because every other section inherits its logic, and rewrites cascade. ### Step 4. Schedule the post-award deliverables across the project period Map award-period deliverables onto a month-by-month grid. The grid format below works well inside a proposal because it compresses a two-year plan onto one page a reviewer can scan. | Deliverable | Q1 | Q2 | Q3 | Q4 | Q5 | Q6 | Q7 | Q8 | |--|--|--|--|--|--|--|--|--| | Protocol approved and staff trained | X | | | | | | | | | Enrollment and sample collection | | X | X | X | X | | | | | Interim dataset, internal QA | | | | X | | | | | | Year 1 progress report | | | | X | | | | | | Year 1 dataset deposition | | | | | | X | | | | Manuscript 1 submitted | | | | | | X | | | | Workshop for community partners | | | | | | | X | | | Final dataset deposition | | | | | | | | X | | Final report to sponsor | | | | | | | | X | Three placement rules keep this grid honest: 1. Put reporting deliverables at the end of each budget year, aligned to whatever anniversary date the sponsor uses, not to your convenience. 2. Put every data or code deliverable after the quality checks that make it depositable. If the interim dataset lands in Q4, the cleaning and documentation work belongs in Q3 or earlier. 3. Leave at least one quarter between a risky scientific milestone and the deliverable that depends on it. If enrollment could slip, the manuscript date should not break the moment it does. ### Step 5. Write the deliverables section for reviewers Most sponsors ask for the timeline in a dedicated section or a figure-free page, so use plain sentences plus the grid. Model the language on this pattern: > Year 1 (months 1 through 12). We will complete protocol approval, staff training, and enrollment of at least 100 participants (milestone, month 12). Deliverables: a de-identified interim dataset submitted for internal quality review by month 10, and the Year 1 progress report submitted by month 12. Each deliverable sentence contains four parts: the noun (what gets handed over), the number where one applies (how much, or how many), the recipient (sponsor, repository, community), and the date. If any of the four is missing, a reviewer cannot verify it and a program officer cannot hold you to it, which cuts both ways. ### Step 6. Set up post-award tracking on day one ![Worked countdown showing two deliverables due 2027-12-31 each have 305 days remaining from 2027-03-01.](/article-images/illustrations/deliverables-in-grant-proposal-timeline-days-remaining-countdown.webp) When the award notice arrives, transfer the deliverables inventory into whatever tracker your team will actually use. A minimal spreadsheet system needs only three additions to the inventory: a `days_remaining` column computed from `due_date`, a `next_action` column naming the single physical next step, and a monthly 30-minute review on a standing calendar invitation. The same Python pattern computes the countdown: ```python from datetime import date today = date(2027, 3, 1) deliverables = [ ("D-08", "Year 1 dataset deposition", date(2027, 12, 31)), ("D-09", "Annual progress report", date(2027, 12, 31)), ] for did, name, due in deliverables: print(f"{did} {name} due {due.isoformat()} {((due - today).days)} days remaining") ``` Expected output: ``` D-08 Year 1 dataset deposition due 2027-12-31 305 days remaining D-09 Annual progress report due 2027-12-31 305 days remaining ``` ## Reference Table: Deliverable Types and Their Verification Standards | Deliverable type | Typical sponsor examples | What proves it is complete | |--|--|--| | Reports | Annual progress report, final report, interim technical report | Sponsor portal acknowledgment or submitted PDF with confirmation | | Data | Dataset deposition, shared data packages | Repository accession number or digital object identifier | | Publications | Peer-reviewed articles, book chapters | Manuscript submission or acceptance record, journal citation | | Software and code | Analysis pipeline, open-source tool release | Version tag in a public repository with a license file | | Training and outreach | Workshops, webinars, mentored trainees | Attendance records, course materials, completion certificates | | Regulatory and compliance | Approved protocol, sharing plan, certifications | Approval letters with dates and protocol numbers | | Application-stage items | Budget, justification, letters, biosketches | Sponsor portal validation with zero errors | ## Deliverables in a Grant Proposal Timeline: Tips These are the habits that separate a timeline that reads well from one that runs well. **Work backward, then add buffer forward.** Compute every date from the deadline, then insert buffer before dates you do not control. Letters of support, institutional approvals, and portal submissions each deserve their own buffer week. A useful rule is that anything requiring a signature or an office you do not supervise gets double the lead time you first estimated. **Assign exactly one owner per deliverable.** "The team" owns nothing. When two names appear on a deliverable, mark one as owner and the other as contributor. In the inventory above, the grants office owns the submitted application even though the PI owns the science, because the person who clicks the submit button owns the deadline. **Write deliverables as nouns, milestones as events.** "Interim dataset" is a noun a reviewer can picture. "Enrollment complete" is an event. Keep them in different rows of your plan so the reviewer never has to infer one from the other. **Match every deliverable to budget lines.** If the proposal promises a community workshop, the budget must show workshop costs, and the budget justification must explain them. If the proposal promises dataset deposition, the budget must cover the personnel time and any repository fees. Reviewers and sponsors both check this cross-referencing, and an unfunded deliverable is a commitment you made for free. **Use sponsor vocabulary.** If the announcement says "Research Performance Progress Report," use that exact phrase in your timeline rather than "annual report." Sponsors sometimes run automated checks, and reviewers who manage those awards notice matching language. **Calendar the sponsor's clock, not just yours.** Find the sponsor's review cycle, award start dates, and reporting windows in the announcement and build your post-award deliverable dates around them. A report due "by month 12" is due 12 months from the actual start date listed on the award notice, which may differ from the start date you proposed by several months. **Keep a reusable template.** After each application, archive the inventory and backward plan. Your next proposal starts from a filled template instead of a blank page, and your estimates of how long each item takes improve with every cycle. ## Common Mistakes and Limitations These are the errors that appear most often in real timelines, with the specific fix for each. **Confusing deliverables with activities.** "Conduct interviews" is an activity. "Transcribed, de-identified interview dataset" is a deliverable. A timeline built only from activities gives the sponsor nothing to verify and gives you nothing to celebrate when done. **Promising publication dates you cannot control.** A manuscript submission is within your control. Acceptance and publication are not, because journals set those dates. Promise "manuscript submitted by month 18," never "published by month 18." Experienced reviewers read the second version as a sign of inexperience. **Ignoring the institution's internal deadline.** The most common single point of failure in grant proposal planning is a budget finalized the night before the sponsor cutoff. Sponsored programs offices publish their lead-time requirements, and those requirements are not negotiable on deadline week. Ask for your office's rule at the kickoff meeting, not the week before submission. **Vague dates.** "Early in the project" and "toward the end of Year 2" cannot be tracked, verified, or defended in a progress report. Convert every date to a month number and a calendar quarter. **Orphaned deliverables.** Every deliverable needs a parent aim and a budget line. During drafting, run a three-column check: aims, deliverables, budget lines. Any row missing a match in the other two columns is either a promise you did not fund or spending you did not justify. **No contingency for the risky milestone.** If Aim 2 depends on a reagent, a recruit, or an instrument with meaningful failure risk, do not schedule its deliverable flush against the next one. Build one quarter of slack between the risky step and whatever depends on it, and say in the narrative how you would use that slack if the risk materializes. **Treating the timeline as write-only.** Many PIs draft a beautiful timeline, submit, and never open it again until the progress report is overdue. The inventory you built during preparation is the tracking system for the award. Reuse it. **A limitation to keep in view.** A timeline is a plan, not a prediction. Sponsors know that science has false starts, which is why most allow no-cost extensions and revised reporting schedules when circumstances change. The deliverables that damage a career are the ones missed silently. When a date becomes unreachable, contact your program officer before the deadline passes, explain the cause, and propose a new date in writing. ## Next Steps If this guide filled gaps in your preparation, two follow-on steps pay off quickly. First, apply the six-step walkthrough to your current application this week, starting with the deliverables inventory in Step 2, because the inventory exposes gaps in your project plan faster than any other drafting exercise. Second, if you want structured instruction, a research [grant writing](/knowledge/molecular-biology/grant-writing) course that includes timeline and deliverable design gives you reviewed drafts and peer feedback, which is difficult to reproduce with self-study alone. Your institution's office of research likely offers one, and many professional societies run short courses alongside their annual meetings. ## Frequently Asked Questions ### What counts as a deliverable in a grant proposal timeline? A deliverable is any tangible, verifiable product your project must hand to the sponsor, a collaborator, or the public, such as a report, a deposited dataset, a released software version, or a completed workshop. Plans, questions, and activities do not count. The test is whether an outside person could confirm the item exists in a finished form. ### How do deliverables differ from milestones and specific aims? Aims state the scientific goals, milestones are checkpoints that show progress toward those goals, and deliverables are the finished products you hand over. In one sentence: aims say what you want to know, milestones say when you will know you are on track, and deliverables say what will physically exist at a stated date. ### How many deliverables should I include in a proposal? Include as many as map cleanly to your aims and budget, which for a typical multi-year project is usually between five and ten award-period deliverables plus the required sponsor reports. Fewer than that can look like an underspecified plan. Many more than that, and reviewers start to doubt you can complete any of them. ### What happens if I miss a deliverable deadline after the award? Contact your program officer before the deadline passes, explain the cause in writing, and propose a revised date. Missed deliverables can lead to withheld funding, required corrective plans, or complications at renewal, but sponsors generally respond well to early, documented communication and poorly to silence. ### Should deliverables appear in the budget justification? Yes. Every deliverable with real costs, such as personnel time for data curation, workshop expenses, or repository fees, needs matching budget lines and a justification sentence. Reviewers check this cross-referencing, and an unfunded deliverable is an unfunded commitment. ### How far before submission should I start grant proposal planning? Start about 90 days before the sponsor deadline for a standard multi-investigator application, which gives time for the aims page, a full draft, letters, internal review, and a budget that clears your institution's internal routing rules. Shorter timelines work for experienced teams resubmitting a mature proposal, not for new applications. ### Can I change deliverables after the award is made? Often yes, with sponsor approval. Most sponsors allow revisions through a formal action such as a rebudgeting request, a prior-approval package, or a no-cost extension, depending on the change. Never change unilaterally. Document the request, get written approval, and update your internal tracker. ### Do pilot or small grants need deliverables too? Yes, in simpler form. Small awards typically require a final report, and many require a small number of project deliverables such as a dataset or a manuscript. The same discipline applies at any budget size: name the product, name the date, name the proof of completion.