Open een projectplan dat je niet zelf hebt geschreven en ga op zoek naar de mijlpalen. Vaak vind je iets als “Fase 2 afgerond” — een balk die zich over twee weken van de kalender uitstrekt, van niemand is en geen geschreven definitie heeft van wat “afgerond” eigenlijk betekent.
Dat is geen mijlpaal. Het is een verklede taak, en die zal je nooit ergens voor waarschuwen.
Mijlpalen zijn het goedkoopste systeem voor vroegtijdige waarschuwing in projectmanagement. Geen extra tools, geen extra vergaderingen, hooguit twintig minuten om ze op te zetten. Maar ze werken alleen als je ze op een specifieke manier bouwt, en de meeste plannen doen dat niet. Zo ziet de versie eruit die wel werkt.
Een mijlpaal is een moment, geen stuk werk
De PMBOK Guide definieert een mijlpaal als een belangrijk punt of een belangrijke gebeurtenis in een project, programma of portfolio. Het sleutelwoord is punt. Een mijlpaal heeft een duur van nul: hij kost geen tijd, geen budget en geen mensen.
Die nul is geen technisch detail. Het is het hele mechanisme.
Een taak kan voor 60% klaar zijn. Een mijlpaal niet. Hij wordt op een specifieke datum bereikt of niet, en juist dat binaire maakt hem bruikbaar als controlepunt. Zodra je een mijlpaal een start- en einddatum geeft, geef je je team ruimte om hem als “bijna klaar” te rapporteren — en met “bijna klaar” blijft vier weken uitloop onzichtbaar tot de week vóór de lancering.
De vier-vragentest
Voordat je een mijlpaal aan een plan toevoegt, laat je hem deze vragen doorlopen:
- Is hij binair? Als iemand redelijkerwijs “gedeeltelijk” kan antwoorden, kijk je naar een taak.
- Verandert er iets verderop? Een echte mijlpaal ontgrendelt werk, maakt geld vrij of draagt verantwoordelijkheid over. Als niets zich de dag erna anders gedraagt, is het decoratie.
- Zou iemand buiten het uitvoerende team het belangrijk vinden? Mijlpalen zijn net zo goed een communicatie-instrument als een planningsinstrument. Een controlepunt dat alleen je eigen team begrijpt, hoort in je takenlijst, niet op de mijlpaallijn.
- Kun je de acceptatiecriteria in één zin opschrijven? Lukt dat niet, dan zal niemand het eens worden over de vraag of hij is gehaald.
Die laatste vraag doet het meeste werk. “Testen” is geen mijlpaal. “Testen afgerond, nul openstaande kritieke defecten” wel. Die tweede kan niet als waar worden verklaard zolang er drie kritieke bugs openstaan, en dat is precies de bedoeling: precieze acceptatiecriteria zijn het medicijn tegen het 99%-klaar-syndroom, waarbij een controlepunt als afgerond wordt gemarkeerd terwijl er daarachter stilletjes nog twee weken opruimwerk doorgaat.
Wijs daarna een eigenaar aan. Niet de persoon die het werk doet dat naar de mijlpaal toe leidt, maar de ene persoon die aan de hand van die criteria verklaart of hij wel of niet is gehaald. Een controlepunt dat van “het team” is, is een controlepunt dat niemand hoeft te verdedigen.
Hoeveel mijlpalen is het juiste aantal?
Er zijn twee manieren om het fout te doen. Drie mijlpalen op een programma van negen maanden is nutteloos — het eerste eerlijke signaal komt in maand vier. Veertig mijlpalen op een project van twaalf weken is net zo nutteloos, want als alles een controlepunt is, is niets het.
Een praktische regel: verdeel ze zo dat geen enkel deel van het project langer dan twee tot vier weken zonder mijlpaal zit, en houd het totaal klein genoeg om op één statusslide te passen. Bij de meeste projecten kom je dan uit tussen vijf en twaalf.
Een standaardset die in vrijwel elk domein werkt:
- Plan goedgekeurd en basislijn vastgelegd
- Scope bevroren
- Ontwerp of specificatie goedgekeurd
- Bouw afgerond / feature freeze
- Overdracht aan de opdrachtgever, de klant of QA
- Go-live
Mijlpalen hebben voorgangers nodig, niet alleen datums
Dit is de structurele fout die het hele systeem ongemerkt uitschakelt: een mijlpaal op een datum parkeren zonder afhankelijkheden die erin uitkomen.
Een mijlpaal zonder voorgangers is een bewering. Hij staat op 14 november omdat iemand 14 november heeft ingetypt. Taken schuiven eromheen, de ruit beweegt niet, en je plan blijft een datum publiceren die drie weken geleden al niet meer klopte.
Een mijlpaal met voorgangers is een berekening. Koppel elke taak die klaar moet zijn voordat het controlepunt kan worden verklaard — finish-to-start naar de ruit — en de mijlpaal wordt de laatste van die einddatums. Loopt één voorganger uit, dan verschuift de mijlpaal dezelfde dag, op het diagram, zonder dat iemand het hoeft op te merken.
Twee gevolgen om rekening mee te houden. Ten eerste: een mijlpaal met veel inkomende koppelingen is een convergentiepunt, en convergentiepunten concentreren risico: zes voorgangers betekent zes onafhankelijke kansen om te laat te zijn, die allemaal op één datum landen. Ten tweede: mijlpalen erven speling zoals elk ander knooppunt in het netwerk. Een mijlpaal met nul speling ligt op het kritieke pad, wat betekent dat het geen controlepunt is dat je ongemerkt kunt missen.
Ze volgen: mijlpaaltrendanalyse
Zodra mijlpalen goed in de planning zijn verankerd, ontgrendel je de meest informatieve en minst gebruikte grafiek in projectmanagement.
Mijlpaaltrendanalyse is eenvoudig. Leg bij elke rapportagecyclus voor elke mijlpaal de verwachte datum van dat moment vast — en bewaar de historie in plaats van die te overschrijven. Zet de rapportagedatum op de horizontale as en de verwachte mijlpaaldatum op de verticale.
Een go-live-mijlpaal wekelijks volgen kan dit opleveren:
| Reviewdatum | Verwachte go-live |
|---|---|
| Week 1 | 14 nov |
| Week 2 | 14 nov |
| Week 3 | 19 nov |
| Week 4 | 26 nov |
| Week 5 | 3 dec |
Een vlakke lijn betekent dat de prognose stabiel is. Een stijgende lijn betekent dat de mijlpaal van je wegloopt, en de helling is het echte signaal. Vanaf week 3 verliest dit project zeven dagen per week, wat betekent dat de go-livedatum precies zo snel wegschuift als de kalender vordert. Dat is geen project dat zich in de tweede helft herstelt. Het is een project waarvan plan en werkelijkheid uit elkaar zijn gegroeid — en de grafiek liet dat drie weken eerder zien dan de datum officieel werd gemist.
Eén discipline laat dit werken, en die is tegenintuïtief: leg de uitloop vast in plaats van de oorspronkelijke datum aan te passen aan de werkelijkheid. Elke keer dat iemand een mijlpaal stilletjes naar zijn huidige plek sleept, gaat er een datapunt verloren en vlakt de trend af tot een comfortabele leugen.
Zo werkt het in LoopGantt
In LoopGantt is een mijlpaal een taak met een duur van nul, en elke weergave toont hem bewust anders.
- Op het Gantt-diagram verschijnt hij als ruit in plaats van als balk, zodat je de controlepunten van het plan in één oogopslag leest, en de markering van het kritieke pad laat meteen zien welke ervan geen speling meer hebben.
- In de weergave Tabel zijn de start- en einddatum identiek en is de kolom Dagen leeg. Daardoor kun je het plan van iemand anders snel controleren: alles wat als mijlpaal is gelabeld maar een duur toont, is er geen.
- In de weergave Kalender staat de ruit op zijn ene dag in plaats van zich over cellen uit te strekken, naast de taken die dat wel doen.
- In de WBS-boom verschijnen mijlpalen als ruitvormige knooppunten tussen ronde taakknooppunten, zodat je kunt zien of elke fase echt eindigt in een controlepunt.
Op het dashboard bewijzen mijlpalen hun waarde. Het heeft een eigen paneel Mijlpalen dat elke mijlpaal met datum en status toont, en een sectie Planningscontroles die de mijlpalen markeert die volgens het netwerk in de problemen zitten — bijvoorbeeld Mijlpaal in gevaar: “Projectkick-off” — voeg buffertijd toe vóór deze mijlpaal of verklein de scope van de voorgaande taken. Die controles worden rechtstreeks berekend uit de afhankelijkheidsgraaf en de speling, dus ze verschijnen direct en kosten geen AI-tegoed.
Voor de trendanalyse hierboven slaan basislijnen je geplande datums op, zodat je geplande en huidige mijlpaaldatums kunt vergelijken in plaats van op je geheugen of oude screenshots te vertrouwen. Gantt-diagrammen, afhankelijkheden, mijlpalen en analyse van het kritieke pad zitten allemaal in het Free-abonnement; basislijnen en het volgen van afwijkingen horen bij Pro, en het Teams-abonnement wordt per lid gefactureerd. Hier vind je de actuele prijzen.
Vier fouten die je beter kunt vermijden
- Een mijlpaal een duur geven. Dan kun je hem als gedeeltelijk klaar rapporteren, en dat is precies het enige wat een controlepunt nooit mag zijn.
- Hem ongekoppeld laten. Een ongekoppelde mijlpaal kan niet uitlopen, dus kan hij je ook niet waarschuwen. Hij houdt zijn datum vast tot de dag dat hij wordt gemist.
- Acceptatiecriteria niet opschrijven. Zonder die criteria wordt “afgerond” in het statusoverleg uitonderhandeld door wie het zelfverzekerdst is.
- De datum aanpassen in plaats van de uitloop vast te leggen. Het voelt als goede hygiëne en vernietigt de enige dataset die je de trend had laten zien.
Kortom
Een bruikbare mijlpaal heeft vijf eigenschappen: een duur van nul, een binaire uitkomst, een eigenaar met naam en toenaam, geschreven acceptatiecriteria en echte voorgangers die erin uitkomen. Heb je die op orde, dan begint je plan problemen te melden weken voordat ze toeslaan. Heb je ze niet op orde, dan heb je decoratieve ruitjes.
Heeft je huidige plan al mijlpalen, doe dan deze week één controle. Open ze een voor een en kijk wat erin is gekoppeld. De mijlpalen zonder iets stroomopwaarts zijn de mijlpalen die tegen je liegen.