How to show work packages and deliverables in a Gantt chart
Show work packages and deliverables on a Gantt chart: packages as groups, deliverables as milestones, handoffs by dependency, overlap inside a package, and an acceptance gate before the next package starts. Grant-funded project example.
A funded project is divided into work packages, and the deliverable from one package is often what the next one builds on. This guide shows how to draw packages, deliverables and acceptance gates on a Gantt chart so you can see which package decides the finish.
The short version
- Make each work package a group and each deliverable a milestone with a duration of 0.
- Link the next package to the acceptance milestone, not to the last task before it.
- Use a start-to-start link with a lag where later work can begin on partial results.
- Draw interim reports and reviews as tasks with a length, and give them their own place in the sequence.
- Switch on Critical path in the View menu to see which package sets the finish date.
Packages are groups, deliverables are gates
A work package is a block of related work with a defined output. That output, the deliverable, is what a funder, a client or a steering group expects to see, and it is usually what the next package starts from. Draw only the tasks and the sequence looks like one long list. Draw the packages and their deliverables and the structure of the project shows: which package is waiting for which, and where a late deliverable would hold everything behind it.
In a Gantt chart the mapping is direct. Each work package is a group, so its tasks sit in one band with a summary bar. Each deliverable is a milestone, a task with a duration of 0, drawn as a diamond. Give the milestone a name that says what happened to the deliverable, such as accepted, not just finished, because the work being done and the deliverable being accepted are different moments. The next package then depends on the milestone, not on the last task before it, so a change to the gate shows what it moves.
Inside a package, not everything has to wait. Analysis can begin when the first data arrives rather than when the last is collected. That is a start-to-start link with a lag, written for example as 9SS+10: the later task starts 10 working days after the earlier one starts. Across packages the link should usually stay finish-to-start through the acceptance milestone, because the next package really does use the findings. Use overlap where partial results are enough, and a gate where they are not.
A change of approach is the expensive late event. If an acceptance decision or a funder's comment alters what the next package should do, every task behind the gate moves with it. The example below is a grant-funded project with three work packages, an interim report that runs beside the second and a final report. The deliverables are the gates, and a decision about approving a change is shown as a flowchart, because a Gantt chart cannot draw a decision or a loop.
All durations are illustrative. Replace them with your own estimates and with what your funder or client tells you about review and acceptance. A timeline schedules the work. It does not make a project eligible, compliant or approved, and it does not replace the funder's rules on deliverables, amendments or reporting. For the fundamentals see /guides/gantt-chart-dependencies and /guides/gantt-chart-milestones.
A grant-funded project, built in stages
Twenty-two tasks in five groups. Durations and lags are illustrative working days. Open the spreadsheet panel to see the rows behind each stage.
Set-up and recruitment come first
"Sign the grant agreement" (3 working days) leads to three tasks that run side by side: "Set up governance and project reporting" (4), "Recruit and hire project staff" (15) and "Agree partner subcontracts" (8). "Onboard staff and hold kick-off" (3) waits for the hire, so recruitment sets the day "Project set-up complete" is reached.
Work package 1 and its deliverable
"Design the WP1 methods and protocols" (6) and "Prepare data sharing agreements" (7) both lead to "Carry out WP1 fieldwork" (15), so the agreements set the start. "Analyse WP1 results and write the report" (8) starts 10 working days into the fieldwork, then "WP1 deliverable accepted" closes the package.
Work package 2 starts from the accepted deliverable
"Build the WP2 tool on WP1 findings" (7) waits for "WP1 deliverable accepted" because it uses the findings. "Run the WP2 pilot" (12) follows, and "Evaluate the WP2 pilot" (6) starts 8 working days into the pilot. "WP2 deliverable accepted" closes the package.
Work package 3 and the interim report
"Draft the interim report" (5) starts from the first accepted deliverable, and "Funder review of the interim report" (10) is a plain wait you replace with what you are told. It finishes 6 working days before "Deliver WP3 with partners" (14) can start, but that task waits for both it and the second deliverable. "Write WP3 guidance and outputs" (8) starts 7 days into delivery, then "WP3 deliverable accepted" closes the package.
The final report closes the project
"Draft the final report" (6) starts when "WP3 deliverable accepted" is reached, and "Final report submitted" ends the plan. With these illustrative numbers the project is 88 working days. Turn on Critical path to see that the recruitment chain, the three packages in turn and the final report set the date, not the reporting.
Approving a change that a Gantt chart cannot draw
Moving money or scope between work packages needs a decision, and a rejected request goes back for rework. A Gantt chart has no decisions or loops, so the process sits in a flowchart and the schedule gets a task with a length.
The request and the completeness check
It starts at "Budget request submitted". "Review business case and assumptions" leads to the decision "Request complete and **costed**?". On No, "Revise request and supporting evidence" sends it back to the review, which is a loop. On a plan, that shows up only as time.
Funding and authority
On Yes, "Check funding and forecast impact" leads to "Within delegated authority?". On No, "Escalate to higher approval tier" adds a step before the decision. Which route a request takes is not known until it is checked, so a plan cannot show it.
The decision and what follows
Both routes reach "Budget approved?". Approved leads to "Load budget and notify owner". Rework or decline leads to "Return decision with rationale", which returns to the review. In the schedule, give the task for an approved change a duration that allows for a round of rework.
Published
The path ends at "Approved budget published". Add one task to the Gantt chart for the approval, give it a length from how long your approvals really take, and link the affected package to it.
How it works
List the packages and their deliverables
Write down each work package in your agreement and the deliverable it produces. Make the packages groups, and add one milestone per deliverable, named for its acceptance, for example "WP1 deliverable accepted".
Add the tasks inside each package
Under each group add the design, delivery and writing-up tasks with a duration in working days. Put the responsible person in People so each package has a visible owner.
Link packages through the acceptance milestones
Make the first task of the next package depend on the previous deliverable milestone. If two packages really are independent, do not link them, and they will run in parallel.
Overlap where partial results are enough
Use a start-to-start link with a lag, such as 9SS+10, where analysis or writing can begin before collection ends. Keep the deliverable milestone after both tasks. See /guides/gantt-chart-overlapping-tasks.
Add reviews and reports as tasks
Draw an interim report and the funder's review as tasks with durations you replace with what you are told, and link the package that depends on the outcome to the review.
Read the critical path and share
Turn on Critical path in the View menu to see which package sets the finish. Share the chart as a link with partners, or export a PDF or PNG for the project board.
Mistakes to avoid
Linking to the last task instead of the deliverable
If the next package depends on the last task of the previous one, the acceptance step disappears from the plan. Link it to the milestone, so the gate is visible and a delay there is visible.
Treating finished work as an accepted deliverable
The fieldwork ending is not the deliverable being accepted. Add the writing-up and the acceptance step as their own tasks or milestone, with a length.
Overlapping packages that really depend on each other
A start-to-start link is right when partial results are enough. If the next package needs the finished findings, keep the finish-to-start link through the gate, and see what that does to the end date.
Expecting progress to move the dates
Progress is drawn inside the bar and does not move any date. If a package will take longer, change its duration. QueryChart also does not track the budget for a package, only the schedule.
Open the grant-funded project Gantt chart
Open the template, rename the work packages and deliverables, and see which package decides the finish date.
Related guides
Frequently asked questions
How do I show a work package in a Gantt chart?
Put its tasks in a group. The group is drawn as a band with a summary bar, so the whole package reads as one block with its tasks inside. Name the group for the package, for example Work package 1.
How do I show a deliverable?
Add a task with a duration of 0. It is drawn as a diamond. Name it for the event, such as "WP1 deliverable accepted", and link the work that depends on the deliverable to it. See /guides/gantt-chart-milestones.
Can tasks in one package start before the previous task has finished?
Yes. Use a start-to-start link with a lag, written for example as 9SS+10, so the later task starts 10 working days after the earlier one starts. Keep the milestone after both tasks.
Can the chart show a change request or a decision?
No. A Gantt chart has no decisions or loops. Keep the process in a flowchart, such as /templates/budget-approval-workflow, and add a task to the Gantt chart for the approval with a duration that allows for a round of rework.
Where do I go from here for the other grant plans?
For the proposal before the award, see /guides/grant-deadline-gantt-chart. For one report cycle, see /guides/reporting-periods-gantt-chart. To start with the funded project plan, open /templates/grant-funded-project-gantt-chart.