Bijna iedereen die weleens een project heeft geleid, kent het moment waarop de planning en de werkelijkheid uit elkaar gaan lopen. Eerst is het een week, daarna een maand, en uiteindelijk wordt de opleverdatum stilletjes verschoven. Vertraging lijkt soms onvermijdelijk, maar vaak is ze al bij de start in de planning ingebakken. Wie een projectplanning maakt die rekening houdt met de manier waarop mensen en organisaties werken, voorkomt een groot deel van die problemen.
Dit artikel beschrijft vijf stappen om een realistische projectplanning te maken. Om de stappen concreet te maken, loopt er één voorbeeld doorheen: een middelgroot bedrijf dat binnen vier maanden een nieuw klantportaal wil lanceren.
Waarom projecten zo vaak uitlopen
Voordat je begint met plannen, helpt het om te weten waar vertraging vandaan komt. Psychologen Daniel Kahneman en Amos Tversky beschreven al in 1979 de planning fallacy: mensen schatten de tijd die een taak kost structureel te laag in, zelfs als ze weten dat vergelijkbare taken eerder ook langer duurden. We plannen vanuit het scenario waarin alles meezit, niet vanuit wat er gewoonlijk gebeurt.
Ook gedrag tijdens het project speelt een rol. De wet van Parkinson stelt dat werk zich uitbreidt tot de tijd die ervoor beschikbaar is. Wie drie weken krijgt voor een taak van twee weken, is na drie weken klaar. Eliyahu Goldratt noemde het verwante verschijnsel dat mensen pas vlak voor de deadline echt beginnen het studentsyndroom. Samen zorgen deze effecten ervoor dat tijdwinst op de ene taak zelden wordt doorgegeven, terwijl vertraging op een andere taak wel doorwerkt.
Een goede projectplanning neemt deze menselijke neigingen serieus. Dat betekent niet dat je overal ruime marges inbouwt, maar dat je bewust kiest waar onzekerheid zit en hoe je daarmee omgaat. Meer over de bredere aanpak lees je op de pagina over projectmanagement.
Stap 1: Leg het eindresultaat en de afbakening vast
Een planning is zo goed als de afspraak over wat er aan het einde moet liggen. Veel vertraging ontstaat doordat het doel onderweg verschuift: er komen wensen bij, iemand had iets anders verwacht of de randvoorwaarden blijken onduidelijk. Begin daarom met een korte, concrete beschrijving van het eindresultaat, inclusief wat er nadrukkelijk niet bij hoort.
Formuleer het doel zo dat iedereen kan vaststellen of het is bereikt. Het SMART-principe helpt daarbij: een doel moet specifiek, meetbaar, acceptabel, realistisch en tijdgebonden zijn. Betrek ook de belangrijkste stakeholders al in deze fase. Hun verwachtingen nu ophalen kost een paar gesprekken; ze later moeten verwerken kost weken.
In het voorbeeld legt het projectteam vast dat het klantportaal bij de lancering facturen, orderstatus en contactgegevens toont. Een chatfunctie en een app vallen buiten dit project en komen eventueel in een tweede fase. Die ene zin voorkomt later discussies over de vraag of de chatfunctie “er toch even bij kan”.
Stap 2: Deel het werk op in concrete taken
Een groot doel is niet te plannen; een reeks overzichtelijke taken wel. Projectmanagers gebruiken hiervoor vaak een work breakdown structure: je deelt het eindresultaat op in deelresultaten en die weer in taken, tot elk onderdeel klein genoeg is om goed in te schatten. Een vuistregel is dat een taak hooguit enkele dagen tot twee weken werk is en een duidelijk resultaat oplevert.
Let er bij het opdelen op dat je ook het minder zichtbare werk meeneemt. Testen, afstemming met juristen, het schrijven van handleidingen en het trainen van gebruikers worden vaak vergeten, terwijl ze in de praktijk veel tijd kosten.
Voor het klantportaal betekent dit onder meer: het ontwerp van de schermen, de koppeling met het boekhoudsysteem, het inlogsysteem, een privacytoets, testen met een groep klanten, het informeren van de klantenservice en de communicatie richting klanten. Juist die laatste drie taken ontbraken in de eerste versie van de planning.
Stap 3: Breng afhankelijkheden en het kritieke pad in kaart
Niet alle taken kunnen tegelijk worden uitgevoerd. Sommige taken kunnen pas starten als een andere klaar is. Door die afhankelijkheden in kaart te brengen, zie je welke reeks taken samen de totale doorlooptijd bepaalt. Dat is het kritieke pad. Een vertraging op dat pad vertraagt het hele project; een vertraging op een taak buiten het pad heeft vaak nog wat speling.
De kritiekepadmethode is in de jaren vijftig ontwikkeld voor grote industriële projecten, maar het principe werkt net zo goed bij een marketingcampagne of een verbouwing. Een Gantt chart maakt de afhankelijkheden zichtbaar: elke taak is een balk op een tijdlijn, en je ziet in één oogopslag wat parallel loopt en wat op elkaar wacht.
In het voorbeeld blijkt de koppeling met het boekhoudsysteem op het kritieke pad te liggen. Het testen met klanten kan pas beginnen als die koppeling werkt, en de lancering hangt weer af van die test. Het ontwerp van de schermen loopt grotendeels parallel en heeft enkele weken speling. Het team weet daardoor waar het de meeste aandacht op moet richten.
Stap 4: Schat realistisch in en plan buffers bewust
Hier gaat het vaak mis. Laat de schatting bij voorkeur doen door de mensen die het werk uitvoeren, en vraag niet alleen naar de verwachte duur, maar ook naar wat er mis kan gaan. Een eenvoudige techniek is om per taak een optimistische, een waarschijnlijke en een pessimistische schatting te vragen. Het verschil tussen die getallen laat zien waar de onzekerheid zit.
Kijk daarnaast naar vergelijkbare projecten uit het verleden. Kahneman raadde aan om niet alleen vanuit het eigen plan te redeneren, maar ook te vragen hoe lang soortgelijke projecten bij anderen duurden. Die buitenblik corrigeert de neiging om het eigen project als uitzondering te zien.
Ga bewust om met buffers. Wie op elke taak een eigen marge zet, loopt het risico dat die marge door de wet van Parkinson gewoon wordt opgebruikt. Een alternatief, dat Goldratt uitwerkte in zijn methode Critical Chain, is om taken krap te plannen en één gezamenlijke buffer aan het einde van het kritieke pad te zetten. De buffer wordt dan zichtbaar en het team kan volgen hoeveel ervan al is verbruikt. Houd ook rekening met beschikbaarheid: iemand die ook ander werk heeft, besteedt zelden acht uur per dag aan het project. Vakanties, feestdagen en piekdrukte in de lijnorganisatie horen in de planning thuis.
Het team van het klantportaal schatte de koppeling met het boekhoudsysteem eerst op drie weken. De ontwikkelaar die eerder een vergelijkbare koppeling bouwde, gaf als pessimistische schatting zeven weken, omdat de documentatie van de leverancier vaak onvolledig is. Het team plande vijf weken en zette twee weken gezamenlijke buffer vóór de lancering.
Stap 5: Volg de voortgang en stuur vroeg bij
Een planning is geen document dat je één keer maakt en daarna in een map stopt. De waarde zit in het regelmatig vergelijken van plan en werkelijkheid. Spreek een vast ritme af, bijvoorbeeld een wekelijks kort overleg, waarin je per taak op het kritieke pad bespreekt wat er klaar is, wat er nog moet gebeuren en wat in de weg zit.
Vraag daarbij liever naar de resterende tijd dan naar een percentage. “Hoeveel dagen heb je nog nodig?” levert eerlijker antwoorden op dan “Hoe ver ben je?”, omdat taken vaak lang op negentig procent blijven hangen. Houd ook bij hoeveel van de buffer al is gebruikt. Is meer dan de helft van de buffer op terwijl nog geen helft van het werk klaar is, dan is dat het moment om in te grijpen: werk anders verdelen, de afbakening bijstellen of de opdrachtgever informeren.
Methodes als Prince2 werken met vaste fasen en beslismomenten, terwijl teams die agile werken in korte cycli plannen en na elke cyclus bijsturen. Welke aanpak past, hangt af van het project. Bij een duidelijk afgebakend eindresultaat werkt een vaste planning goed; bij veel onzekerheid over wat de klant precies nodig heeft, is plannen in korte stappen vaak verstandiger. In beide gevallen geldt dat vroeg signaleren goedkoper is dan laat repareren.
In het voorbeeld liep de koppeling met het boekhoudsysteem na drie weken een week achter. Omdat het team dat in het wekelijkse overleg zag, kon het op tijd een extra ontwikkelaar inzetten en hoefde de lanceringsdatum niet te schuiven. Een week van de buffer werd gebruikt, de andere week bleef over voor onverwachte bevindingen tijdens de klanttest.
