Milestones, work packages, and the Gantt: planning the funded year reviewers believe

Founders routinely blur these and it weakens the plan. An Arbeitspaket (work package) is a bundle of activity with an owner, a duration, and a deliverable - "AP2: build and benchmark the matching engine, technical lead, months 2-5." A milestone (Meilenstein) is a single verifiable point in time that marks the result of one or more packages - "M2: matching engine processes 1.000 records/second on the benchmark set, end of month 5." Work packages describe the work; milestones prove it happened. Reviewers want to see both, and they want the milestones to be the checkpoints where they could, in principle, verify you are on track.

The test for a real milestone is binary verifiability: on the named date, an outside observer could say yes or no without arguing. "Prototype substantially advanced" fails the test - who decides what "substantially" means. "Closed beta live with five external users completing the core flow" passes it. Rewrite every soft milestone into a binary one and the plan immediately reads more credible, because it shows you know what done looks like.

The instinct is to pack the year full to look ambitious. Resist it. A funded year that lists fifteen milestones reads as a team that has not prioritised and will hit none of them cleanly. Three to five well-chosen milestones is the sweet spot for a one-year stipend: enough to show real progress across the year, few enough that each one is meaningful and achievable. Pick milestones that move different risks - one that retires the biggest technical risk, one that retires the biggest market risk, one that sets up the next funding step - rather than five milestones that are all variations of "build more product."

Sequence them so an early milestone de-risks a later one. If your month-ten milestone is "first paying pilot," your month-five milestone should be the thing that makes the pilot possible (a working core, a signed letter of intent). A plan where the milestones build on each other reads as a team that understands its own critical path; a plan where milestones are independent islands reads as a wish list.

A Gantt chart in the application has one job: to show that the work packages fit in twelve months without two founders being in three places at once. The most common Gantt mistake is the everything-parallel chart, where six packages all run months one through twelve - that is not a plan, it is a list with bars. A credible Gantt shows dependencies (AP3 starts when AP2 delivers), shows where each founder's time actually goes, and shows the milestones as diamonds at the points where packages converge. If your chart implies one founder is full-time on four packages simultaneously, the reviewer sees it instantly and the feasibility score drops.

Keep it readable. A Gantt that needs a magnifying glass loses the reviewer; six to ten bars, clear month axis, milestone diamonds, and a colour or initials to show who owns what is enough. The chart should be legible printed in greyscale, because some reviewers still print. And the bars should leave slack - a plan with zero buffer between dependent packages is a plan that breaks the first time anything slips, and reviewers who have run projects know it.

The strongest applications make the milestone plan and the Finanzplan two views of the same year. Every Sachkosten line should attach to a work package - the GPU credits belong to the model-training package, the user-testing incentives belong to the validation package. When a reviewer can trace a spend to a package to a milestone, the budget stops looking like a wish and starts looking like a plan. When they cannot - when there is a 4.000-euro line with no home in any package - that is exactly the line they will question in the Fachgespräch.

This is also why you write the Finanzplan last, after the milestone plan is settled. Build the year first - packages, dependencies, milestones - then read down the packages and ask what each one costs. The budget that falls out of that process is internally consistent by construction. The budget you build first and try to retrofit a plan onto almost always has orphan line items, and orphan line items are where applications lose feasibility points. None of this is tax advice; confirm the bookkeeping treatment of any larger purchase with a professional before you commit to it in the plan.

Reviewers in research-funding programmes (BMBF, ZIM, EU lines) expect three distinct planning artefacts, and founders who blur them lose clarity points. The Projektstrukturplan (PSP) answers "what is to be done" - it decomposes the project hierarchically into sub-projects and work packages, with no time axis. The Gantt (Balkenplan) answers "when does what happen" - it lays the work packages on a month axis and shows durations, overlaps, and dependencies. The Meilensteinplan answers "when do we reach which result" - it strips away the activity detail and lists only the verifiable checkpoints. They are three lenses on the same year: the PSP is the skeleton, the Gantt is the schedule, the Meilensteinplan is the dashboard.

You do not always need all three as separate diagrams - a one-year EXIST stipend can carry the work packages and milestones in a single Gantt with diamonds, while a multi-year BMBF Verbundprojekt usually wants a real PSP plus a Gantt plus a milestone table. Read the call. The point is conceptual: keep the three questions separate in your head even when one chart answers two of them, because a plan that confuses "what" with "when" with "what result" is the plan that reads as muddled.

In any application where the main cost is people - BMBF, ZIM, EU, and EXIST Forschungstransfer all work this way - each work package carries an effort estimate in Personenmonate (PM): one PM is one person working full-time for one month. AP2 might be "6 PM, technical lead"; AP4 might be "3 PM split across two founders." Person-months are the hinge between the plan and the budget: the PM per package, multiplied by the funded rate for each role, is the Personalkosten line in the Finanzplan. When the PM are honest and the rates are right, the personnel budget falls out automatically and reconciles with the work; when the PM are guessed to back-fit a target budget, a reviewer who adds them up finds a team that has not thought about who actually does the work.

Two sanity checks reviewers run, so run them first. One: do the total PM across all packages match the headcount and project length you claim? Two founders over twelve months is at most 24 PM - a plan that sums to 40 PM is either hiding unfunded help or inflating. Two: is the PM distribution plausible per person across time? If the Gantt shows one founder owning four parallel packages at 1 PM/month each, that founder is booked at 400 % - the same overcommitment the Gantt section warns about, now visible in the numbers. Effort that survives both checks reads as a team that understands its own capacity, which is exactly what the feasibility score rewards (see the grading criteria).