Waarom projectstarts de mensen teleurstellen die later aansluiten
De mythe van de projectstart: Projectstarts zorgen aan het begin voor overeenstemming, maar dingen zullen onvermijdelijk veranderen.
Eigenaarschap is belangrijk: Wanneer mensen die halverwege een project instromen geen eigenaarschap ervaren, zullen het projectmomentum, het moreel en de impact daaronder lijden.
De uitdaging van documentatie: Traditionele documentatie schiet tekort in snel veranderende projecten; lichte, aanpasbare formats zijn essentieel.
AI en neurodiversiteit: AI-tools kunnen het inwerken ondersteunen door toegankelijke projectinformatie te bieden, maar vereisen nauwkeurige gegevens.
Een cultuur waarin iedereen erbij hoort: Het bevorderen van het gevoel erbij te horen is cruciaal voor een efficiënte integratie in het team en het succes van het project.
Waarom projectstarts geweldig zijn… maar gebrekkig
Ik houd van een geweldige projectstartbijeenkomst. Het is een kans om enthousiasme te creëren, momentum op te bouwen en voor afstemming te zorgen met alle juiste mensen in de ruimte.
Behalve dan... projectstarts zijn een complete mythe.
Tenminste, die versie ervan.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
De versie waarin we alle bekende belanghebbenden bijeenbrengen, het gezamenlijk eens worden over een Poolster, onze aanpak in steen beitelen en vervolgens samen van start gaan in de veronderstelling dat de kinetische energie die we die dag hebben gecreëerd het project eigenhandig van begin tot eind zal dragen.
De realiteit is dat verandering onvermijdelijk is en dat de aanpak van de meeste teams voor projectstarts in feite gebrekkig is.
En dat gaat een stuk belangrijker worden in de economie van AI-ondersteunde, fractionele werknemers waar we aan het begin van staan.
Waarom een goede projectstart geen goed project garandeert
Vroeger dacht ik dat mijn vermogen om geweldige projectstarts te leiden mijn oneerlijke voordeel als projectmanager was. Wanneer ik mijn projecten startte, schoten teams met duidelijkheid en momentum uit de startblokken, in plaats van met verwarring en nog meer onbeantwoorde vragen.
In feite kwamen mensen na een startbijeenkomst naar me toe en vroegen of ze mijn agenda of presentatie mochten lenen, zodat ze die voor hun eigen projecten konden gebruiken. Daar was ik trots op.
Maar toen gebeurde er iets waardoor ik heel anders over projectstarts ging denken.
Bij een van mijn projecten werden belangrijke teamleden bij me weggehaald en aan andere projecten toegewezen — allemaal zonder tijd voor een goede kennisoverdracht. De getalenteerde mensen die insprongen waren ook zeer bekwaam, maar ze hadden het gevoel dat ze met een achterstand begonnen en in de schaduw leefden van wat er al was gebeurd. Elk gesprek begonnen ze met een voorbehoud als "maar ik was er niet toen het project begon" of "ik ben hier alleen maar mijn achterstand aan het inhalen, laat mijn ideeën je plannen niet ontsporen."
Voor de nieuwe teamleden was het niet zo dat ze de informatie, de bevoegdheid of zelfs de ideeën niet hadden. Het was dat ze niet het gevoel hadden dat ze eigenaarschap hadden.
En zonder dat eigenaarschap was de wind uit de zeilen. De missie was niet van hen. Ze voelden zich als invalkrachten die de kastanjes uit het vuur moesten halen — slachtoffers van hun omstandigheden, met weinig zeggenschap of controle.
Helaas had ik dat toen nog niet door.
Het probleem van kennisoverdracht
Destijds leek de oplossing eenvoudig: breng de nieuwe mensen gewoon op de hoogte. Draag de kennis over aan hun brein. Toch?
Er zijn tenslotte genoeg briefings, scopeverklaringen en eisen- en wensenoverzichten — om nog maar te zwijgen over de startpresentatie en de resultaten van visieoefeningen.
Maar zelfs als al je projectdocumenten netjes en geordend zijn, kan de ervaring van een nieuw teamlid dat zich een weg moet banen door een berg losjes gestructureerde informatie aanvoelen alsof je forensische boekhouding doet met een pistool tegen je hoofd.
Natuurlijk kunnen nieuwe teamleden vragen stellen, maar ze weten niet wat ze niet weten. En meestal voelen ze zich nog niet op hun gemak om de "domme" vragen te stellen, uit angst voor de gevreesde reactie: "dat stond in de documenten, heb je dat niet gezien?"
Hierdoor ontstond een cyclus waarin nieuwkomers langer verdwaald bleven — wat het project alleen maar moeilijker bestuurbaar maakte.
Het probleem van actualiteit
Daar kwam nog bij dat ik telkens wanneer ik een nieuw teamlid in mijn project inwerkte, ontdekte dat binnen mijn prachtige documenten kleine details — verdorie, soms zelfs grote details — niet meer overeenkwamen met de actuele stand van het project.
Sinds de start waren er honderdduizenden microbeslissingen genomen. Niet de grote beslissingen die je in een beslislogboek zet — de kleine die tussen de mazen van updates van documentatie doorglippen.
Ik merkte dat ik verschillen moest uitleggen, kleine nuances moest toelichten en informele gesprekken tussen teamleden moest doorgeven waarvan we nooit hadden bedacht dat we ze moesten vastleggen.
Het snelheidsprobleem
Had ik dit allemaal kunnen beperken door een "buddy-systeem" te gebruiken, waarbij een nieuw teamlid aan een collega in het project werd gekoppeld? Geloof me, ik heb het geprobeerd. Maar ook dat liep op niets uit, omdat het project het zich niet kon veroorloven dat een teamlid parttime ondersteuning bood.
We werkten al in een moordend tempo en konden het ons niet veroorloven om te vertragen. Deadlines kwamen snel dichterbij, de druk nam toe, de zichtbaarheid groeide en de verwachting was dat het team sneller zou werken naarmate er meer mensen bijkwamen, niet langzamer.
Dus in plaats van het tempo te verlagen, ging ik door met de bestaande werkwijze: de versie waarin mensen die halverwege het project instappen vast komen te zitten in mijn aanpak waarbij ik in een rijdende auto spring en mijn hand in het vuur steek.
Het probleem van erbij horen
Maar terwijl ik documenten en vergaderuitnodigingen in paniek naar mensen bleef slingeren die aan het project werden toegevoegd — en terwijl het team gedachteloos door taken uit de achterstandslijst bladerde — werd iets heel duidelijk: het ging niet om informatie. Het ging om erbij horen. En dat is een emotionele toestand die niet alleen met documentatie kan worden bereikt.
Ik kon nieuwe teamleden niet het gevoel geven dat ze erbij hoorden door ze alleen maar gerust te stellen of meer tegen ze te praten. Geen buddysysteem zou dit oplossen. Geen vergaderingen met een agenda waarin iedereen “alles mocht vragen” zouden de situatie gladstrijken. Er moesten veilige en alternatieve ruimtes zijn.
Mensen ervaren erbij horen in verschillende contexten op verschillende manieren: sommigen willen eerst rustig de documentatie doornemen voordat ze met het team praten; sommigen willen een buddy; sommigen willen een veilige plek om de “domme” vragen te stellen; en sommigen willen gewoon begrijpen wat de “waarom” achter de missie is en welke rol zij daarin spelen.
Daar had ik mijn tijd en energie in moeten investeren: een kader bouwen waarmee teamleden op hun eigen voorwaarden een gevoel van verbondenheid kunnen vinden.
Uiteindelijk investeerde ik te veel in de startceremonie, om vervolgens mensen die halverwege het project instroomden aan hun lot over te laten.
Deze cyclus van ontoereikende inwerkbegeleiding frustreert niet alleen individuen — hij ondermijnt hele projecten. Wanneer nieuwkomers niet snel op de hoogte kunnen komen, vertragen beslissingen, stapelen fouten zich op en lijdt het moreel van het team eronder.
En wanneer verandering onvermijdelijk is — wanneer teamleden gedurende de levenscyclus van een project in- en uitstromen — wordt deze aanpak onhoudbaar.
Voor de nieuwe teamleden was het niet zo dat ze niet over de informatie, de bevoegdheid of zelfs de ideeën beschikten. Het was zo dat ze niet het gevoel hadden dat ze eigenaarschap hadden.
Een andere manier om over startsessies na te denken: doorlopende inwerkbegeleiding
Dus wat is dan het antwoord? Als we te veel investeren in startsessies en te weinig in het omgaan met veranderingen en inwerkbegeleiding halverwege een project, hoe kunnen we dat corrigeren?
Ik had mijn hypotheses, maar ook een inzichtsmoment dankzij iemand die ik enorm respecteer en die zei:
"Ik herhaal het aandachtspunt bijna elke vergadering opnieuw, omdat de 'leidende ster' voortdurend verschuift. Het doet me denken aan hoe we Kung Fu beoefenen… Er is een centraal punt waarop we ons richten en dat we onder controle proberen te houden, en daarbuiten is alles context om terug te keren naar die waarheid. Het is een gesprek, waarbij beide kanten in realtime met al hun zintuigen 'vragen stellen' en antwoorden ontvangen."
Met andere woorden: in plaats van te vertrouwen op het grote spektakel van een startsessie, kunnen we elke interactie gebruiken om de essentie van wat belangrijk is in het project opnieuw te benadrukken. Het zit ingebakken in het samenwerken zelf, in plaats van dat het een groot feest is waarbij je gemakkelijk het gevoel krijgt dat je iets hebt gemist als je er niet bij was.
Dit is dus wat ik sindsdien voor elk project probeer te doen:
1. Een beleid voor lichtgewicht, eenvoudig bij te werken documentatie
Ik laat mijn fraaie presentaties voor startsessies en tot in de puntjes uitgewerkte projectdocumenten (briefings, statusrapporten, vergaderagenda's, RAID-logboeken) achterwege en geef in plaats daarvan prioriteit aan een indeling die eenvoudig bij te werken en gemakkelijk leesbaar is voor menselijke teamgenoten of teamgenoten die AI gebruiken.
Vervolgens werk ik met projectteams samen om verantwoordelijken voor documentupdates aan te wijzen — net zoals we dat voor risicoverantwoordelijken zouden doen. Zo wordt de werklast verspreid en krijgen teamleden de mogelijkheid om zich in te zetten voor nauwkeurige documentatie.
We hebben bijvoorbeeld eenvoudige, beknopte documenten in Notion of Slite voor teamrollen en verantwoordelijkheden, onze projectbriefing en onze projectcommunicatieplannen. Niets ligt vast in spreadsheets of pdf's.
2. Doorlopende inwerkbegeleiding als geaccepteerde realiteit
Samen met de documentatie beheer ik vanaf het allereerste begin de verwachtingen van het team: de teams, doelen en andere onderdelen van het project kunnen van het ene op het andere moment veranderen, en dan moeten we de krachten bundelen.
Met andere woorden: in plaats van te hopen en te bidden dat teams en doelstellingen niet veranderen, gaan we ervan uit dat ze dat wel zullen doen.
Dat betekent dat we zo min mogelijk informatie alleen in het hoofd van mensen vastleggen of aan een specifiek moment koppelen. Vergaderingen hebben transcripties, de aantekeningen van sprekers zijn schriftelijk toegankelijk, de meeste projectgesprekken vinden plaats in openbare kanalen en beslissingen worden nauwgezet vastgelegd.
Zo zorgen we ervoor dat mensen die de eerste dag van het project hebben gemist, nog steeds toegang hebben tot de informatie als ze die nodig hebben. En het helpt ons ook om als een zwerm veldleeuweriken van richting te veranderen als een van de doelen of omstandigheden van het project verandert.
3. AI als bron van waarheid voor alle neurotypen
Daarnaast richten mijn teams en ik al zo vroeg mogelijk in het project AI-chatbots of doorzoekbare kennisbanken met projectinformatie in.
In veel gevallen is dit niet zo geavanceerd als je bij AI misschien zou dromen, maar het doet iets wat voor ons echt belangrijk is: het creëert een relatief persoonlijke, veilige en minder gepolitiseerde manier waarop teamleden toegang krijgen tot projectinformatie — op hun eigen voorwaarden, op de manier waarop zij graag leren.
Deze chatbots worden vanaf het allereerste begin gevoed met gestructureerde en ongestructureerde projectgegevens — briefings, SOW's, statusrapporten, notulen van vergaderingen en enkele teamgesprekken. En omdat de documentatie licht genoeg is voor menselijke teamleden om deze bijgewerkt te houden, is het voor een AI relatief eenvoudig om bij te houden wat er in de loop van het project is veranderd — genomen beslissingen, toegevoegd budget, ontstane problemen, gerealiseerde risico's, geëscaleerde kwesties, enzovoort.
Vervolgens zou elk teamlid die chatbot op elk moment vragen kunnen stellen in een context waarin diegene zich geen zorgen hoeft te maken dat hij of zij dom overkomt en zonder een vergadering te hoeven plannen met een gezaghebbende persoon die al weinig tijd heeft.
Een teamlid kan bijvoorbeeld dingen vragen als:
- “Hoe ondersteunt mijn taak het algemene projectdoel?”
- “Wie is van mij afhankelijk om mijn oplevering op tijd af te ronden?”
- “Waar moet ik mijn definitieve opleveringen opslaan en wat is onze conventie voor bestandsnamen?”
Dit kunnen vragen zijn waarop ze het antwoord wel weten, maar waarover ze geruststelling willen wanneer ze tussen projecten en andere taken heen en weer schakelen.
Uiteindelijk stroomlijnen AI-chatbots het proces van toegang tot informatie, verhogen ze de efficiëntie doordat de behoefte aan uitgebreide training of overleg met meerdere bronnen verdwijnt en verbeteren ze de toegankelijkheid dankzij een gebruiksvriendelijke interface die 24/7 vanaf elk apparaat met een internetverbinding toegankelijk is.
Maar dit is het addertje onder het gras: het is bekend dat AI fouten maakt.
En als de AI het bij het verkeerde eind heeft, kan dat een project razendsnel op een zijspoor zetten. Het uiteindelijke gevolg zou een extra stap zijn: de chatbot iets vragen, het antwoord kritisch bekijken omdat het mogelijk onjuist is en vervolgens op je intuïtie afgaan om te beslissen of je het ontvangen antwoord volgt zonder iemand anders iets te vragen, of een collega zoekt aan wie je het kunt vragen — met andere woorden: wanneer we AI niet vertrouwen, zijn we weer terug bij af.
De gegevens moeten dus schoon genoeg zijn om niet tegenstrijdig te zijn. En vervolgens moeten de mensen in het team er daadwerkelijk op vertrouwen dat de informatie correct is (ervan uitgaande dat we het systeem geen desinformatie hebben gevoerd).
Om dat te helpen waarborgen, ligt onze prioriteit bij het bereiken van een zo groot mogelijke nauwkeurigheid, waarbij belangrijke teamleden optreden als ambassadeurs en kwaliteitsbewakers aan de hand van enkele testgevallen en steekproeven die we regelmatig uitvoeren.
4. Rituele versterking van doelen
En om alles met elkaar te verbinden, probeer ik enkele van mijn favoriete elementen van de tragische projectstart die slechts een “momentopname” is geweest te verweven in het dagelijks werk. Denk aan het opnieuw verwoorden en voortdurend ter discussie stellen van de productvisie of BHAG, zodat de missie goed genoeg wordt begrepen om kritisch te worden onderzocht en we zeker weten dat we nog steeds het juiste bouwen.
Ik probeer mensen er bijvoorbeeld aan het begin van elke teamvergadering aan te herinneren wat de gewenste resultaten voor het project zijn. Iets in de trant van: "Ter herinnering: dit project gaat reizigers in het openbaar vervoer met verschillende mogelijkheden helpen om veiliger en met minder frustratie op hun bestemming te komen."
En als die Noordster is verschoven, probeer ik dat ook tijdens elke vergadering of statusupdate opnieuw te verwoorden: "Ter herinnering: dit begon als een initiatief voor reizigers met een beperking in het openbaar vervoer, maar is nu een kans om de ervaring voor alle klanten binnen meerdere openbaarvervoernetwerken te verbeteren."
Het andere wat ik doe, is mijn rol als generalist gebruiken om vragen te stellen die beslissingen in de richting van ons doel sturen. Als het team bijvoorbeeld probeert te kiezen tussen twee benaderingen, zou ik iets vragen als: "Welke optie helpt ons om de meeste wrijving uit de klantervaring weg te nemen?"
Voor zaken als teamwaarden en manieren van werken sluit ik vergaderingen af met een herinnering daaraan: "Vergeet niet om belangrijke communicatie in het gedeelde kanaal te plaatsen als die anderen kan helpen hun werk te doen."
Dit zorgt er niet alleen voor dat mensen die halverwege bij het project komen zich minder voelen alsof ze aan het begin iets hebben gemist, maar helpt ook om de missie voortdurend bij al je belanghebbenden onder de aandacht te brengen.
5. Een cultuur waarin iedereen erbij hoort
Maar het allerbelangrijkste is dat ik probeer mijn mindset te veranderen van "kennisoverdracht" naar "eigenaarschapsoverdracht" door prioriteit te geven aan manieren om nieuwe teamleden of belanghebbenden het gevoel te geven dat ze bij het project "horen" en zichzelf er volledig in kunnen meenemen.
Naar mijn mening bestaat er geen enkele waterdichte manier om dit te doen, maar ik geloof er sterk in dat het antwoord niet ligt in het over mensen uitstorten van nog meer informatie. Wij mensen moeten onze menselijkheid gebruiken om de zaken aan te pakken die bij uitstek menselijke zaken zijn — emoties, ego, gemeenschap en zingeving.
Wanneer mensen geen eigenaarschap voelen, zullen ze zich minder snel uitspreken als iets niet goed voelt of een beslissing ter discussie stellen die het project de verkeerde kant op kan sturen.
Waarom dit nu belangrijker is
Vandaag zie ik dat het probleem van onboarding halverwege een project steeds groter wordt. Leden van mijn community leiden projecten met een voortdurend wisselende bezetting van deeltijdspecialisten, freelancers en zelfs gewoon FTE's die flexibel tussen projecten worden ingezet om hun capaciteit te benutten.
Tegelijkertijd zorgen AI-tools voor flexibele verwachtingen bij belanghebbenden van projecten: er wordt verwacht dat projecten sneller vooruitgaan, beter met veranderingen omgaan en meer waarde leveren door inzichten uit gegevens, automatisering en agentgestuurde besluitvorming te benutten.
Met andere woorden: de teams zijn veranderlijker en het tempo versnelt. Dat betekent dat de kloof in verbondenheid groter wordt wanneer alles sneller beweegt en vaker verandert.
En dit is het echte risico: we willen niet alleen het verkeerde sneller bouwen.
Wanneer mensen geen eigenaarschap voelen, zullen ze zich minder snel uitspreken als iets niet goed voelt of een beslissing ter discussie stellen die het project de verkeerde kant op kan sturen.
Daarom is doorlopende onboarding niet langer optioneel. Het is geen aardige extra of zachte vaardigheid. Het is een zakelijke noodzaak. Als we teams willen die zich kunnen aanpassen en echte waarde kunnen leveren in dit snellere, meer versnipperde projectlandschap, hebben we mensen nodig die zich betrokken voelen bij de visie, niet alleen geïnformeerd zijn over de taken.
Zijn projectstarts dan verleden tijd?
Projectstarts zijn absoluut niet verleden tijd. Niet voor mij en ook niet voor veel projectteams.
Persoonlijk ben ik er dol op. Ik denk dat projectstarts bijeenkomsten zijn die een band tussen mensen kunnen creëren en op een cruciaal moment in de levenscyclus van een project ruimte kunnen bieden voor dialoog. Ik vind ze heel menselijk. Dus ja, ik organiseer nog steeds projectstarts, en je zult die gewoonte uit mijn koude, dode handen moeten wrikken.
Wat ik wel anders doe, is dat ik niet al mijn hoop en dromen in mijn projectstarts prop. Ik steek niet meer zoveel energie in het vlekkeloos, gelikt en geënsceneerd maken ervan. Ik streef er niet naar om ze de allesbepalende ceremonie te maken waardoor mensen die er vanaf het begin niet bij waren zich tweederangsburgers voelen. En ik probeer ze al helemaal niet zo vorm te geven dat we vastzitten aan de verwachting van één enkele, onveranderlijke route.
Want projecten verlopen niet in een rechte lijn. Ze zijn als een vlieger in de wind: ze worden voortdurend heen en weer geslingerd en moeten actief worden bijgestuurd, wat er ook gebeurt. Verandering is onvermijdelijk. Daar zouden we dus onze energie in moeten steken: ons daarop voorbereiden.
Wat vind jij?
Maar ik hoor ook graag van jou: zijn projectstarts inderdaad zo problematisch als ik ze heb voorgesteld? Hoe kijk jij aan tegen onboarding binnen je projecten, vooral wanneer teamleden halverwege instromen?
