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.