De 5 stappen van projectmanagement in de praktijk

Waarom projecten vastlopen op stappen die iedereen kent

De vijf stappen van projectmanagement zijn initiatie, planning, uitvoering, monitoring en afsluiting. Ze staan in elk handboek, elke opleiding en elke PMBOK Guide. En tóch loopt het merendeel van de projecten uit in tijd, geld of scope.

Dat komt zelden doordat een projectmanager de fasen niet kent. Wat je in de praktijk ziet: één stap wordt overgeslagen omdat de opdrachtgever haast heeft, of gehaast afgerond omdat het "wel duidelijk is". Initiatie krijgt een half uur, planning een middag en dan mag de uitvoering het oplossen. Monitoring wordt een statusrapport dat niemand leest. Afsluiting? Iedereen is al bezig met het volgende project.

Bij elke stap hieronder staat één veelgemaakte fout plus een voorbeeld uit de praktijk van projectmanagement. Zo zie je wat de stap inhoudt én waar hij bij jou waarschijnlijk vastloopt.

Stap 1 initiatie, oftewel beslissen of het project überhaupt moet

De initiatiefase gaat over één vraag: moeten we dit project wel doen? In deze stap bepaal je het doel, de scope, de business case en breng je de stakeholders in kaart. Aan het eind staat er een go of een no-go. Klinkt logisch, maar in de praktijk slaan teams die eerste vraag over en beginnen ze meteen te plannen.

Wat er misgaat: de opdracht is vaak een gevoel of een wens, geen probleemdefinitie. "We willen een nieuw CRM." Prima. Maar bij doorvragen blijkt regelmatig dat het CRM niet het probleem is. De salesprocessen zijn niet vastgelegd, verantwoordelijkheden zijn onduidelijk en niemand weet wat er in de bestaande tool wél en niet werkt. Een nieuwe tool bovenop een rommelig proces geeft je vooral een duurdere versie van dezelfde chaos. Goed projectmanagement begint bij dit soort vraagstukken met dat onderscheid: is dit een probleem, een symptoom of een aanname?

Kaders opschrijven voordat je begint

Drie dingen op papier, voordat er iemand aan een planning denkt:

• Doel: welk probleem lossen we op, in de taal van de business (niet in features).
• Resultaat: wat is er concreet klaar aan het einde, en hoe merken we dat.
• Randvoorwaarden: budget, doorlooptijd, capaciteit, afhankelijkheden.

Voeg daar een lijstje aannames aan toe. Elk project draait op aannames ("marketing levert de content aan", "de directeur beslist binnen een week") en die staan zelden zwart op wit. Aannames die je opschrijft, kun je toetsen. Aannames die in iemands hoofd zitten, worden pas zichtbaar op het moment dat ze niet kloppen, en dan zit je vaak al middenin de uitvoering.

Stap 2 planning, waar de meeste projecten al scheef groeien

In de planningsfase vertaal je de kaders uit stap 1 naar iets uitvoerbaars. Je knipt het werk in werkpakketten (de work breakdown structure), koppelt daar mensen en uren aan, bepaalt volgordelijkheid en kritieke pad, stelt het budget vast en maakt een risicoanalyse. Op papier een middag werk. In de praktijk de stap waarin de meeste projecten al scheef beginnen.

Wat er misgaat: planningen worden gebouwd op optimisme. Ontwikkelaars zijn "fulltime beschikbaar", terwijl twee van de drie ook aan support hangen. Aannames staan nergens genoteerd. Risico's krijgen een regel in een tabel maar geen eigenaar en geen mitigatie. Voorbeeld: een IT-project met een strakke planning voor drie developers, waarbij niemand had opgeschreven dat support voorrang heeft op nieuwe features. Uitloop vanaf week één, en niemand die het zag aankomen omdat de capaciteit "kloppend" leek.

Wat er wél in een planning hoort

• Werkpakketten met een eigenaar, niet met een team. "Team backend" is geen verantwoordelijke.
• Reële capaciteit, dus niet 40 uur per week per persoon, maar de netto uren die overblijven na support, overleg en vakantie.
• Kritieke pad zichtbaar: welke taken schuiven de einddatum op als ze uitlopen.
• Risico's met mitigatie en trigger: wat doen we als het gebeurt, en wanneer weten we dat het aan de hand is.

Op dit moment heb je een omgeving nodig die planning en dagelijkse uitvoering aan elkaar knoopt. Een planning in Excel en taken in een aparte tool betekent dat je twee waarheden onderhoudt, en dus geen. Platforms als monday.com zijn hier praktisch omdat capaciteit, taken en voortgang in één weergave staan.

Nog een verschil om scherp te houden: in PRINCE2 is de planning formeel en gelaagd (project-, fase- en teamplannen met expliciete tolerances). In Agile plan je niet het hele project vooraf, maar per sprint, met een backlog die schuift op basis van wat je in de vorige sprint hebt geleerd. De valkuil is hetzelfde: wie capaciteit en risico's niet realistisch inschat, loopt in beide werelden vast, alleen merk je het in Agile twee weken eerder.

Stap 3 is uitvoering, en dan ziet niemand meer wat er gebeurt

In de uitvoeringsfase gaan de werkpakketten uit stap 2 daadwerkelijk de wereld in. Het team levert, de projectmanager coördineert, bewaakt afspraken en houdt afhankelijkheden tussen disciplines in de gaten. Klinkt als "iedereen doet gewoon zijn werk", en precies daar zit de valkuil.

Wat er misgaat: uitvoering wordt behandeld als een optelsom van individuele taken, terwijl juist hier de afstemming tussen teams het verschil maakt. Statusupdates gebeuren in Slack of Teams, verdwijnen in een chatstroom en zijn twee dagen later niet meer terug te vinden. Blokkades worden mondeling gemeld, actiepunten belanden in de notulen van iemand die met vakantie is. De projectmanager weet pas dat iets fout gaat als de deadline al gemist is.

Voorbeeld: een marketingcampagne waarbij content, design en development parallel lopen. Content wacht op briefing, design wacht op copy, development wacht op de definitieve assets. Iedereen werkt hard, niemand ziet dat de volgorde niet klopt. De launch schuift een week op. Twee weken later opnieuw, omdat er nog een afhankelijkheid opduikt die niemand had zien staan.

Wat werkt is één plek waar taken, eigenaren, deadlines en blokkades zichtbaar zijn voor het hele team, niet alleen voor de projectmanager. Zodra een taak vasthaakt, zie je het aan de status, niet aan een chatbericht dat je misschien gemist hebt. Dat scheelt tussen op schema blijven en achteraf brandjes blussen.

Waarom stap 4 (monitoring en controle) geen bijproduct van uitvoering is

Monitoring en controle is geen samenvatting van wat je in de uitvoering al doet. Het is een aparte activiteit: voortgang meten tegen de planning, afwijkingen signaleren en bijsturen voordat de deadline in zicht komt. Skip je die stap, dan kom je er pas achter dat het misgaat op het moment dat corrigeren niet meer kan.

Wat er misgaat: monitoring wordt versmald tot een wekelijkse standup waarin iedereen "op schema" zegt te liggen. Niemand liegt, maar er zit geen meetpunt achter dat gevoel. Voorbeeld uit de bouw: een aannemer rapporteert acht weken lang dat alles loopt. In week acht blijkt dat een staallevering drie weken vertraagd is, en dat de vervolgtaken (vloer, installaties, oplevering) daarop wachten. De hele planning kantelt in één gesprek.

Harde meetpunten in plaats van meer overleg

Bijsturen begint bij cijfers die vroeg alarm slaan. Wat je op zijn minst wil zien:

• Schedule Variance en kritieke pad: loopt een taak op het kritieke pad uit, dan verschuift de einddatum. Dat is een feit, geen inschatting.
• Budget besteed versus voortgang: 60% van het budget op en 30% klaar is een signaal, geen tussenstand.
• Openstaande blokkades met leeftijd: een blokkade die vijf dagen oud is, is een ander probleem dan één van gisteren.
• Scope changes sinds start: hoeveel wijzigingen zijn er goedgekeurd, en wat kostten ze aan tijd en geld.

Zet die vier in een dashboard dat elke week automatisch actualiseert. Een standup vertelt je wat mensen denken. Meetpunten vertellen je wat er is gebeurd.

Zo sluit je stap 5 af zonder de geleerde lessen te verliezen

De afsluitfase bestaat uit oplevering aan de klant of eindgebruiker, evaluatie, documentatie en formele decharge. Op papier vier bullets, in de praktijk de stap die het vaakst wordt overgeslagen omdat iedereen mentaal al bezig is met het volgende project.

Wat er misgaat: het project houdt gewoon op. Geen evaluatie, geen retrospective, geen adoptiecheck. Geleerde lessen verdwijnen in het hoofd van de projectmanager en het volgende team maakt dezelfde fouten. Voorbeeld: een implementatietraject gaat live, iedereen viert de release en zes maanden later blijkt dat niemand de handleidingen gebruikt. De tool staat er, maar de mensen werken eromheen. Niemand heeft gemeten of het echt landde.

Wat een goede projectafsluiting oplevert:

• Oplevering met acceptatiecriteria die aantoonbaar zijn afgevinkt, niet alleen mondeling bevestigd.
• Evaluatie met het team én de opdrachtgever, waarin je ook benoemt wat niet werkte.
• Documentatie op één vindbare plek, inclusief besluiten en aannames uit stap 1.
• Nazorg met een adoptiecheck na drie en zes maanden: gebruikt men het echt, en wat is er nodig om het te blijven gebruiken.

Nazorg wordt vaak apart gepland, maar hoort bij deze stap. Zonder die check weet je niet of het project geslaagd is, alleen dat het klaar is.

Conclusie

Van de vijf stappen krijgt monitoring en controle in de praktijk de minste aandacht, terwijl daar de meeste winst zit. Initiatie en planning krijgen bijna vanzelf tijd, uitvoering ook (er moet iets gebeuren) en afsluiting doet iedereen op zijn eigen manier. De tussenstap waarin je durft te zien dat je afwijkt van de planning wordt vaak afgeraffeld tot een wekelijkse status waarin niemand liegt en niemand meet. Daar loopt grip op projecten stil.

Wil je die structuur echt inrichten, dan is de kern dit: overzicht en meetmomenten moeten in dezelfde omgeving zitten als het werk zelf. Een dashboard in een aparte tool is een dashboard dat niemand opent. Voor teams die dit stap voor stap willen opbouwen is een monday.com implementatie een praktische route om planning, voortgang en meetpunten op één plek te krijgen, in plaats van in drie systemen die elkaar tegenspreken.