A funder-ready work-package timeline in an afternoon

Almost every research proposal asks for one: a Gantt of your work packages, with deliverables and review points as milestones, showing when each strand runs and how they depend on each other. It's due Friday, your co-investigators are in three time zones, and you do not want to learn a licensed scheduler for a single figure. Here's how to build a proposal-grade WP timeline in an afternoon — in the browser, free, nothing uploaded.

The work-package timeline is a small figure that carries a lot of weight. Reviewers use it to check that the project is feasible — that the plan is actually sequenced, that deliverables land when the budget says they will, and that the dependencies between strands are honest rather than aspirational. A vague bar chart reads as a vague project. A crisp, dated Gantt reads as a team that has thought it through.

And yet the tooling most academics reach for is wrong at both ends. A drawing tool gives you rectangles with no dates, no dependencies and nothing that stays consistent when a reviewer asks you to shift the start by two months. A heavyweight desktop scheduler gives you all of that and then some — plus a licence cost, a learning curve, and an install your final-year PhD student can't open. You want the middle: something that understands months, milestones and links, but ships a clean page and gets out of the way.

Think in swimlanes, not a task list

The mental model that makes a proposal timeline click is the swimlane. Each work package — WP1, WP2, WP3… — is a horizontal band that owns its own strip of the chart. Inside each lane sit that WP's tasks; on each lane sit its deliverables and its review points as milestone symbols. The lanes stack down the page, months run across the top, and the dependencies between packages become arrows crossing from one lane into the next.

Read top to bottom you see who does what; read left to right you see when, and in what order. That's exactly the two questions a reviewer is scoring. Group your rows into WP bands and the structure of the whole project falls out of the layout for free — no separate diagram, no second figure to keep in sync.

Build it in an afternoon

Here's the whole flow, start to submitted figure. Nothing here needs a scheduler licence, and nothing you type leaves your browser.

1. Lay the work packages out as lanes. Add a section band for each package — WP1 Requirements & co-design, WP2 Method development, and so on. Each band becomes a swimlane; Sketchedule draws an automatic summary bar across whatever you nest inside it, so the lane always spans its own tasks. If your project outline already lives in Excel or a CSV, paste the rows in and map the columns instead of retyping.
2. Add tasks, then wire the dependencies. Under each WP, add the constituent tasks with start and finish months (use a month or countdown timescale keyed to project start — "M1, M2…" — so you never commit to calendar dates the funder hasn't set). Then link them: draw a finish-to-start dependency where WP2 can't begin until WP1's deliverable lands. The links are real relationships, not drawn arrows — move a predecessor and the arrow follows.
3. Promote deliverables and reviews to milestones. Every deliverable (D2.1) and every review point (interim review, ethics sign-off, mid-term check) becomes a milestone diamond on its lane, dated to the month it's due. Use conditional symbology to make the shapes speak: deliverables as filled diamonds, review gates as flags, dependencies feeding a gate drawn as a curtain across the whole chart. Add a phase band or two — Setup / Delivery / Dissemination — to give the reviewer the arc at a glance.
4. Brand it, then export a clean PDF. Drop your institution logo, project acronym and grant reference into the header/footer, pick a light theme, and export a landscape PDF (or PNG/SVG) that drops straight into the proposal document. What prints is what you see — no screenshot-and-crop, no reflowed bars. On the free tier the export carries a small watermark; Pro removes it for a fully branded page.
5. Share a read-only link with your co-investigators. Send a read-only link to your co-Is and named collaborators. The whole schedule travels inside the link, encrypted — nothing is uploaded to a server — so a collaborator with no account and nothing installed opens the exact timeline in their browser, checks their WP, and sends a comment back before you lock the figure for submission.

Why not a "real" scheduler — or a slide?

Because both fail the specific job. A drawing or slide tool can look like a Gantt, but the bars are just rectangles: there are no dates behind them, no dependencies, and no consistency. The moment a reviewer says "push the start back a quarter," you're nudging shapes by hand and hoping the milestones still line up. For a figure that reviewers scrutinise for feasibility, hand-drawn is a liability.

A heavyweight desktop scheduler has the opposite problem. It has genuine dates, logic and critical-path maths — far more than a proposal figure needs — but it's licensed, it has a real learning curve, and the output is built for a controls office, not a bid document. Worse, the co-investigator who needs to check WP3 usually can't open the file at all. You end up exporting a screenshot and pasting it into the proposal anyway, which is exactly the fragile step you were trying to avoid.

The proposal-grade middle ground is a tool that understands months, milestones and dependencies but ships a clean, branded page and shares by link. That's the whole design brief here: enough scheduling to be honest, none of the overhead, free to start, and openable by anyone on the team.

Primavera and P6 are trademarks of Oracle Corporation; Microsoft Project is a trademark of Microsoft Corporation. Sketchedule is an independent product and is not affiliated with, endorsed by or sponsored by Oracle, Microsoft, or any research-funding body. Figures are illustrative, drawn in Sketchedule; funder names and templates are referenced generically and imply no endorsement.