Het vaak geciteerde Chaos Report van Standish Group toont aan: projecten lopen wel uit, niet in. Ook als projectmanager merk ik dat. Het is natuurlijk heerlijk om een project een keer te vroeg op te leveren, maar dat is honderd keer moeilijker dan gewoon op tijd. Maar de vraag is natuurlijk: hoe komt dat?
De verklaring begint bij je eigen bedrijfskantine. Op het eerste gezicht bestaat de lunch uit een verzameling kleine zelfstandige projectjes. Vanaf 12:00 uur stormen de medewerkers hongerig de lunchruimte in, storten zich als wolven op de verse boterhammen en werken de broodnodige calorieën in hoog tempo naar binnen. Tot zover gaat de vergelijking met een normaal project nog op: er is een vast beginmoment (er is nu eenmaal afgesproken dat men geen herrie, rommel en gedoe wil vóór 12:00 uur) en elke ‘resource’ voert zijn ‘taken’ uit in zijn eigen tempo. Al om 12:06 zie je dat de eerste ‘deadline’ is behaald en de eerste ‘oplevering’ wordt gedaan (bord en bestek worden in de vaatwasser of op de afruimband geplaatst). Je zou denken: zie je wel, een project kan ook wel eens snel klaar zijn.
Grote projecten: vergaderzalen en tomatensoep
Echte projecten zijn natuurlijk complexer dan één medewerker met één taak. Stel dat tien collega’s een vergadering hebben na de lunch, dan kan die niet eerder starten dan dat de traagste eter zich meldt. Stel dat er ook nog schaarse facilitaire resources in de planning staan, zoals een kommetje tomatensoep om 12:30, dan slaat de vertraging in alle hevigheid toe. Je kunt nooit eerder starten met de vergadering dan 13:00, want de ruimte is niet beschikbaar. En meestal start je later, omdat de traagste eters ook nog hebben gewacht op de soep. Kortom: de mensen werken snel, maar de afhankelijkheden zorgen voor vertraging.
De echte wereld
Een kritische lezer denkt nu misschien: deze vergelijking deugt niet. En terecht. Echte projecten zijn namelijk nóg complexer, hebben nóg meer afhankelijkheden en nóg meer schaarse resources. In een echt project worden mensen ziek, zit er wel eens wat tegen, wordt wel eens een taak over het hoofd gezien of komen er haastklusjes tussendoor. Anders gezegd: waar de interne afhankelijkheden op zich al leidden tot vertraging, zorgen menselijke factoren en externe afhankelijkheden voor totale onvoorspelbaarheid. En alleen maar meer vertraging.
In ons bedrijf proberen we hier zo veel mogelijk rekening mee te houden. Projectplanningen worden vooral ontworpen op het elimineren van afhankelijkheden, we hebben zelfs onze ontwikkelmethodiek erop gebaseerd. Natuurlijk werken onze mensen snel en efficiënt, maar dat heeft pas resultaat wanneer ze hun taak kunnen starten zonder op allerlei andere dingen te moeten wachten. Dat is niet gemakkelijk en vereist een bepaalde manier van denken, maar het werkt wel.
Tot slot: iedereen die met het openbaar vervoer reist en onderweg een beetje oplet, wist dit allemaal al. Je eerste trein is nooit zo vroeg dat je een aansluiting eerder kunt nemen, maar vaak wel vaak een klein beetje te laat, waardoor de volgende trein al weg is als je het perron op komt rennen. Heeft je reis drie overstappen, dan kan dit drie keer gebeuren. OV-reizigers zouden eigenlijk ervaringsdeskundigen bij uitstek moeten zijn. OV-reizigers die van ver moeten komen, zijn nooit, maar dan ook nooit ergens op tijd. Bovendien geven ze de NS daar de schuld van. Terwijl de theorie zegt dat ze toch echt beter hadden moeten weten.
Als je bedoelt dat een project eerder moet starten omdat we zouden moeten anticiperen op het uitlopen ervan, dan kom je van een koude kermis thuis. Juist te vroeg gestarte projecten hebben de neiging uit te lopen. En al helemaal als het de in dit stuk geschetste waterval aanpak betreft. De vergelijking met de trein is dan ook wat ongelukkig, temeer daar de NS bij teveel vertraging er gewoon een trein tussenuit haalt om een escalatie van vertragingen te voorkomen. Bij een project hoef je het natuurlijk niet te proberen een geplande (tussen)release van een cruciaal stuk software eruit te halen.
Een goed project kent een reële planning, een goede bezetting, een goede logistiek, beschikt over de juiste en voldoende faciliteiten en vooral: wordt door iedereen belangrijk gevonden.
Maar ja, de theorie zegt dat we dit allemaal al zouden kunnen weten.
Als je ruwweg met de helft van je projecten te vroeg klaar bent weet je dat je planning realistisch was. Maar ambitie, kosten en zelfoverschatting doen mensen ertoe te bewegen dat planningen te krap worden gekozen.
Je kan er ook voor kiezen om aan te geven hoe ver je bent zodat men daar rekening kan houden ipv een einddatum te schatten.
PRINCE2 waarschuwt ons voor de risico’s van externe producten. Indien projecten afhankelijk zijn van externe factoren zoals parttime resources of deliverables buiten de scope van het project, moet je als PM hieraan extra aandacht besteden.
Stel dat de hongerige wolven hun boterhammen niet bij zich hadden, maar afhankelijk waren van de laattijdige catering, dan was die ene taak nog niet op tijd afgerond.
Conclusie: Wil je jouw project op tijd opleveren, ga dan opzoek naar risico’s buiten de scope van het project.
Herkenbaar, tot aan de vergelijking met het OV. Vooral “OV-reizigers die van ver moeten komen, zijn nooit, maar dan ook nooit ergens op tijd. ” is we erg stellig. Juist de mensen die geregeld met de trein reizen en grote afstanden moeten afleggen calculeren wat vertraging in, met als resultaat dat ze vaak een half uur te vroeg zijn. Maar allemaal prima te plannen. Incidentele treinreizigers hebben altijd problemen (“nou, dat is nou ook wat, zit ik voor het eerst in 15 jaar weer in een trein, heeft ie vertraging”).
Het zijn overigens vaak de autorijders die te laat zijn (“ineens een file op de A1” en “de parkeergarage was vol”) maar die had je als projectmanager annex autorijder kunnen incalculeren.
Mijn opa vond te laat komen verschrikkelijk. Als we opa en oma ophaalden van het station stonden ze er na een lange reis steevast al te wachten. “We hadden de voortrein” zei mijn opa dan.
Misschien moet je in projecten wat meer ‘voortreinen’ inplannen.