Hoe voer je een effectieve retrospectieve uit en pas je geleerde lessen toe op toekomstige projecten

Lees het transcript:

 

We proberen onze podcasts uit te schrijven met behulp van een softwareprogramma. Vergeef ons eventuele typefouten, want de bot heeft niet altijd 100% gelijk.

Galen Low: Hallo allemaal, bedankt voor het luisteren. Mijn naam is Galen Low van The Digital Project Manager. Wij zijn een gemeenschap van digitale professionals met als doel elkaar te helpen vaardigheden te ontwikkelen, zelfvertrouwen op te bouwen en contacten te leggen, zodat we de waarde van projectmanagement in een digitale wereld kunnen vergroten. Als je daar meer over wilt horen, ga dan naar thedigitalprojectmanager.com.

Vandaag hebben we het over projectretrospectives: hoe je ze effectief uitvoert en hoe je ervoor zorgt dat de lessen die je tijdens je retrospectives vastlegt daadwerkelijk leiden tot verbeteringen in toekomstige projecten.

Vandaag bij me is Payson Hall, oprichter en hoofdconsultant bij Catalysis Group, die organisaties al ruim dertig jaar helpt leren van misstappen in hun projecten.

Payson, geweldig dat je er bent.

Payson Hall: Hallo, leuk om mee te doen en leuk om het publiek te ontmoeten.

Galen Low: Ja, en ik ben blij dat je dat noemt, want vandaag doen we iets anders. We zijn live met onze leden als studiopubliek en nemen via onze Slack-gemeenschap vragen uit de zaal aan. Michael is ook bij me in de studio, dus hij zal enkele vragen beantwoorden. We verwerken ze in het gesprek en alles kan gebeuren. Laten we het levendig houden.

Goed, we gaan erin duiken. Ik wilde beginnen met een prikkelende vraag, want we hebben het hier al over gehad en jij voert al tientallen jaren als consultant projectretrospectives uit voor allerlei soorten projecten, waaronder softwareprojecten en grootschalige systeemintegratieprojecten. Daarom wilde ik je dit vragen: wanneer je als externe consultant binnenkomt om alle kleine vuile geheimen van een project bloot te leggen, zien projectteams je dan als vriend of als vijand? Voelt het alsof ze mentorschap krijgen? Of voelt het alsof ze worden gecontroleerd?

Payson Hall: Meestal is het een vriendelijke uitwisseling. Ik wil wel een onderscheid maken, want een deel van mijn adviespraktijk bestaat uit projectautopsies. Als een project ernstig ontspoort en er bezorgdheid bestaat dat mensen wisten dat het misging maar niets zeiden, lijkt dat veel meer op een audit.

Ik werk bijvoorbeeld samen met een staatsaccountant in Californië en heb IT-projecten van miljarden dollars geaudit. Daar proberen ze meestal een rechtszaak op te bouwen waarmee advocaten een systeemintegrator kunnen aanpakken. Een gebruikelijkere en vriendelijkere retrospective is gewoon dat mensen zeggen: Hé, we hebben dit project afgerond.

Laten we iemand inschakelen om terug te kijken, toch? Dat is wat een retrospective is: terugkijken om te vragen wat we hebben geleerd, wat we slim hebben aangepakt zonder dat we dat destijds misschien beseften, en wat we achteraf anders hadden willen doen. Het is eigenlijk een sessie over risicobeheer waarbij je in de achteruitkijkspiegel kijkt. Wat kan ik de volgende keer beter doen? Wat heb ik slim gedaan en waarvan wil ik zeker meer doen?

Galen Low: Ik vind dat onderscheid ook erg goed, want ik denk dat sommige luisteraars het verschil misschien niet zo ervaren. Elke retrospective voelt dan als een autopsie, alsof ze bewijsmateriaal voor de rechtbank verzamelen en alsof het een soort schuldspel wordt, in plaats van dat je gewoon, zoals je zei, in de achteruitkijkspiegel kijkt en van je fouten leert.

Payson Hall: Een van de belangrijkste regels voor retrospectives, en er zijn verschillende manieren om ze uit te voeren, is dat je als projectmanager nooit je eigen retrospective moet leiden. Sommige dingen die niet goed gingen, zijn namelijk dingen die jij hebt gedaan. Een goede facilitator kan ervoor zorgen dat het gaat over wat er is gebeurd, wanneer het gebeurde en wat we ervan hebben geleerd. Niet: Galen, jij hebt het echt verpest.

Dat is niet constructief. Mensen worden defensief en het gesprek ontspoort. Of je nu iemand van buitenaf inschakelt of intern iemand hebt die je vertrouwt en die goed kan faciliteren, je wilt iemand die niet bij het project betrokken was en geen persoonlijk belang heeft bij de uitkomst. Zo voorkom je dat er aan het einde veel bloed op de vloer ligt.

Galen Low: Dat is terecht. En het is een interessante invalshoek, want ik weet dat veel mensen hiernaar luisteren om uit te zoeken hoe ze hun eigen retrospective kunnen uitvoeren.

Dat is voor veel projectteams natuurlijk de realiteit, en we zullen enkele tips bespreken die je onderweg hebt geleerd. Maar ik vind het goede advies dat het iemand anders kan zijn — en misschien zelfs iemand anders zou moeten zijn — om dat perspectief te bieden en ervoor te zorgen dat het geen schuldspel wordt. Dan ligt er achteraf, zoals jij zegt, niet zoveel bloed op de vloer.

Payson Hall: Het moet iemand zijn die met een andere reeks aannames binnenkomt. Denk aan projecten waaraan je hebt gewerkt. Tijdens het project heb je aannames gedaan over de oorzaken van problemen. Die kunnen juist of onjuist zijn. Iemand die zonder die aannames binnenkomt, staat misschien open voor andere informatie of andere interpretaties.

Galen Low: Dat vind ik geweldig. Iemand die niet twaalf tot achttien maanden bij een langlopend project betrokken is geweest, er emotioneel dicht op zit en daardoor misschien het bos door de bomen niet meer ziet.

Misschien beginnen we met het brede plaatje. Laten we even uitzoomen om onze luisteraars houvast te geven. Kun je vanuit jouw perspectief uitleggen wat een projectretrospective is en waarom het de moeite waard is?

Payson Hall: Goede vraag. Het woord retrospective betekent terugkijken. Het idee is dat we een belangrijk moment in het project bereiken of een project afronden. Dan kijken we terug en zeggen we: goed, laten we even op adem komen. Wat hebben we in dit laatste deel geleerd? Welke lessen willen we toepassen in het volgende deel of in het volgende project?

Wat hebben we toevallig slim gedaan? Of wat deden we waarvan we achteraf zeggen: als ik het opnieuw kon doen, zou ik het anders aanpakken? Als ik een bericht naar mezelf in het verleden kon sturen, wat zou ik dan anders willen doen? Het gaat er dus om even adem te halen en projectgebeurtenissen in hun context te bekijken.

Zoals je zei: uitzoomen en het grote geheel zien, zodat we begrijpen wat belangrijk is en wat niet. Sommige dingen zijn gewoon zwarte zwanen: onverwachte gebeurtenissen, zoals COVID. Ik ga in de meeste toekomstige projecten geen pandemieën plannen, maar als dat je project overkomt, heeft het wel degelijk impact.

Daar kunnen lessen in zitten, maar sommige dingen zijn gewoon niet te voorzien. Misschien had je twaalf laptops nodig en bestelde je er veertien voor het geval er een paar defect zouden zijn. Uiteindelijk was er één defect en dat was slim, omdat je een strakke planning had.

Als je de kosten van de twee extra laptops afzet tegen de vertraging die je hebt voorkomen, kan dat een heel goede geleerde les zijn. Die extra laptop is bovendien niet per se verloren. Misschien kun je hem retourneren. Je kunt zelfs contractueel vastleggen dat je het recht hebt om hem terug te sturen zolang de verpakking ongeopend is.

Het kan dus zijn dat die duizend dollar heel goed besteed was omdat je daarmee drie weken vertraging hebt voorkomen. Als je de afgelopen drie jaar met hardware en verstoorde toeleveringsketens hebt gewerkt, weet je precies wat ik bedoel.

Galen Low: Zeker. Ik vind dat een geweldig voorbeeld. En er is iets belangrijks waar mensen vaak niet aan denken: retrospectives kunnen ook reflecteren op iets dat juist heel goed ging, op die slimme aanpak die geweldig werkte.

Achteraf vraag je soms: wat ging goed? Dan zegt iedereen: het team werkte goed samen, we communiceerden goed, enzovoort. Maar een concrete les kan zijn: weet je nog dat iemand die alternatieve vergaderruimte had gereserveerd? Onze locatie werd geannuleerd en we hadden een back-up. Dat was geweldig. Dat moeten we meenemen in ons proces voor de volgende keer.

En zoals jij zei, zorgen we ervoor dat het contract bepaalt dat we een extra laptop kunnen retourneren als die ongeopend is. Dan hebben we ons ingedekt en kunnen we die slimme aanpak in toekomstige projecten gebruiken.

Wat ik ook goed vond, is dat je zei dat retrospectives zowel aan het einde van een project als op een belangrijk moment tijdens het project kunnen plaatsvinden. Veel mensen denken dat retrospective betekent dat het project is afgelopen en dat het te laat is. Je kijkt in de achteruitkijkspiegel met een wat weemoedige toon: dit had beter gekund, maar het is nu te laat. We moeten wachten op het volgende project. Terwijl er juist ook andere momenten tijdens het project zijn waarop je een retrospective kunt houden. Daar wil ik later op terugkomen.

Payson Hall: Dat is een van de interessante dingen die we uit agile werkwijzen halen. Daar wordt meestal aan het einde van elke sprint een kleine retrospective gehouden. Ik heb aan projecten gewerkt waarbij we ze bij grote projecten op basis van mijlpalen uitvoerden, maar Agile zei eigenlijk: waarom doen we dit niet op terugkerende momenten?

Omdat we het vaker doen, zijn de sessies kleiner. Het team begrijpt het proces beter en kan de sessie snel uitvoeren. Ik vind dat een mooie innovatie: retrospectives aan het einde van elke sprint.

Galen Low: Ik hou van die verschuiving in mindset: we kunnen dit regelmatiger doen en het wordt daardoor kleiner. Om advocaat van de duivel te spelen: veel organisaties zeggen dat ze willen leren van hun fouten en snel willen falen. Maar als het erop aankomt, willen ze niet investeren in terugkijken. Ze zeggen: we hebben onderweg geleerd, we hoeven daar geen vergadering over te houden. Laten we doorgaan.

Wat is er nodig om een goede projectretrospective uit te voeren? En is het de moeite waard als een organisatie zegt: mensen hebben tijdens het project de pijn gevoeld, laten we gewoon verdergaan en Payson niet inschakelen?

Payson Hall: Dat is een goede vraag. Bij procesverbetering moeten we ervoor zorgen dat de kosten van de geleerde lessen en de verbetering niet hoger zijn dan de waarde van die verbetering. Wat kost een retrospective? Laat me een voorbeeld geven.

De context is belangrijk. Een project van meerdere miljoenen of miljarden dollars vraagt meer inspanning dan een klein project. Er zijn meer gegevens. Een probleemproject vraagt meer werk dan een project dat soepel verliep. Als een project volledig instort en advocaten betrokken zijn, doe je geen retrospective maar een autopsie. Dat kan erg duur zijn.

Onlangs heb ik een retrospective uitgevoerd met een team van ongeveer twaalf mensen voor een intern project van ongeveer achttien maanden. Het project voldeed aan de eisen, liep iets uit maar dat was acceptabel, en er waren geen advocaten betrokken.

De vraag was: we zijn klaar, laten we op adem komen. Wat hebben we geleerd? Wat kunnen we anders doen? Teamleden besteedden ieder waarschijnlijk vier tot zes uur aan voorbereiding, de bijeenkomst en de nabespreking. Als facilitator besteedde ik ongeveer twaalf uur aan voorbereiding, begeleiding en verslaglegging.

De projectmanager besteedde waarschijnlijk acht tot twaalf uur aan het verzamelen van informatie en het doornemen van het project met mij. In totaal kostte de retrospective ongeveer twee persoonsweken. Een team van twaalf plus de projectmanager die achttien maanden werkt, vertegenwoordigt ongeveer duizend persoonsweken.

We besteden dus 0,2% van de totale inspanning aan terugkijken: wat hebben we geleerd, wat kunnen we anders doen en wat hebben we slim aangepakt? Je hoeft maar een manier te vinden om twee persoonsweken aan inspanning te besparen en je hebt al een positief rendement op de investering.

Dat kan structureel zijn: een aanbeveling aan het PMO die tijd en problemen bespaart. Het kan ook organisch zijn. Stel dat we in dit project bewust een codebeoordeling hebben uitgevoerd en dat dit enorm hielp. De teamleden nemen die les mee naar hun volgende projecten en kunnen ervoor pleiten.

Ik heb nog nooit een retrospective meegemaakt waarbij we niet eindigden met bevindingen, aanbevelingen en suggesties. Volgens mij is dat minstens de twee persoonsweken waard die we erin investeren.

Galen Low: Dat klinkt redelijk. We praten over grotere projecten, maar is er ook een ondergrens voor kleinere projecten? Als je project maar vier weken duurde, lijkt twee persoonsweken investeren misschien niet rendabel. Laat je het dan achterwege? Of combineer je vijf kleine projecten in één retrospective?

Payson Hall: Nee, dat was vroeg in mijn carrière een fout die ik maakte. Je wilt niemand in een retrospective hebben die niet bij het project betrokken was. Als het team niet met elkaar overhoopligt, zijn mensen veel comfortabeler wanneer ze eerlijk praten over wat wel en niet werkte met een team waarmee ze nauw hebben samengewerkt dan met een groep vreemden.

Daarom zou ik projecten niet combineren. Na een reeks kleine retrospectives kun je de projectmanagers wel bij elkaar brengen om gemeenschappelijke patronen te bespreken. Dat kan interessant zijn voor het PMO. Maar in een retrospective wil ik geen toeristen. Ik wil alleen het team.

Kun je dit op kleine schaal doen? Absoluut. Bij een project van drie of vier weken kun je misschien een uur samenkomen en het meeste bespreken. Ik zou wat voorbereiding doen en de projectmanager vragen wat die verwachtte, maar je kunt zo'n retrospective informeel in één of twee uur uitvoeren.

Galen Low: Je noemde eerder dat je in een agile raamwerk mogelijk na elke sprint een retrospective houdt. Misschien is er daarnaast aan het einde van het project een moment nodig om alle lessen samen te brengen en aanbevelingen te formuleren. Die twee persoonsweken hoeven dus niet allemaal aan het einde plaats te vinden.

Payson Hall: Precies. Met een team van acht mensen kost een uur samenkomen acht persoonsuren. Voeg daar wat voorbereiding en tijd van de projectmanager aan toe en je kunt het geheel misschien in twaalf uur uitvoeren, inclusief een lijst van één pagina met wat we hebben geleerd.

Galen Low: Er zijn ook opportuniteitskosten. Als je een uur besteedt en een les ontdekt die je telkens een half miljoen dollar bespaart, heeft die investering zichzelf tien keer terugverdiend. Dat is de prijs van géén retrospective houden.

Veel luisteraars werken bij bureaus. De klant wil niet betalen voor een retrospective omdat die zegt dat het bureau daar zelf beter van wordt. Tegelijk wil de leiding van het bureau er niet in investeren omdat het geen factureerbare tijd is. Hoe kunnen projectleiders de waarde van dit soort leren uitleggen aan eigenaren en leidinggevenden?

Payson Hall: Ik wil beleefd blijven, maar als ik ergens werkte waar de CEO zei dat we het volgende project niet beter hoefden te doen dan dit project, zou ik mijn cv bijwerken. Dat zou me grote zorgen baren.

Voordat ik Catalysis Group oprichtte, werkte ik vier jaar bij IBM Professional Services aan projecten van meerdere miljoenen dollars. Meestal betaalt de klant hier niet rechtstreeks voor; de organisatie betaalt ervoor. De organisatie betaalt omdat ze de klanttevredenheid, efficiëntie en processen wil verbeteren.

Bij adviesbureaus moet je bedenken hoeveel uren je moet besparen voordat een retrospective waardevol wordt. Als iemand bijvoorbeeld 2.000 dollar per dag factureert en je met zes mensen een uur besteedt om een manier te vinden waarmee je vier dagen bespaart op het volgende project, heb je de retrospective ruimschoots terugverdiend.

Begin klein. Organiseer een lunch of plan een uur. Toen ik jong was werkte ik bij Price Waterhouse. Elke maand organiseerden de partners een ontbijt voor het personeel om zeven uur 's ochtends. Wij dachten dat we geluk hadden, terwijl de partners dachten dat ze ons twee uur eerder naar kantoor hadden laten komen voor een personeelsvergadering.

Professionele dienstverleners proberen meestal hun organisatie te verbeteren. Er kunnen uitzonderlijke omstandigheden zijn — als er brand is, moet je die eerst blussen — maar over het algemeen is de waarde van retrospectives niet moeilijk te verkopen. Begin klein; de waarde wordt vanzelf zichtbaar.

Wanneer een retrospective een bruikbare les oplevert, vertel dan dat je die op het volgende project hebt toegepast en dat dit twee weken heeft bespaard. Zo overtuig je leidinggevenden dat het een goede besteding van tijd is.

Galen Low: Begin klein en verzamel bewijs. Laat zien dat het waarde heeft gecreëerd. Beslissers hebben misschien nog geen bewijs dat dit waarde oplevert, terwijl er wel geld op tafel ligt.

Payson Hall: Een veelvoorkomend resultaat is een document of presentatie met de belangrijkste punten. Je kunt dat voor leidinggevenden bewerken. Misschien is er een interne versie en een versie die je deelt. Als het goed is opgesteld, kan het ook laten zien dat leidinggevenden soms problemen veroorzaken, bijvoorbeeld door middelen zonder waarschuwing opnieuw toe te wijzen of door op de verkeerde kosten te besparen.

Je wilt zulke lessen op een tactvolle manier formuleren, zodat ze het denken van leidinggevenden naar productievere interacties sturen.

Galen Low: Dat is een strategische communicatielens. Het leiderschapsteam krijgt misschien een versie met de belangrijkste lessen, zonder alle details uit de teamversie.

Payson Hall: Absoluut. Ik houd niet zo van de metafoor van vuile was. Een van de slimste dingen die iemand mij ooit vertelde, is dat de meeste mensen proberen het juiste te doen met de informatie die ze hebben. Het is gemakkelijk om achteraf te zeggen dat iemand dit of dat niet heeft gedaan, maar dat is niet het punt.

Ga ervan uit dat mensen hun best deden met de beschikbare informatie. De vraag is dan: welke informatie hadden ze? Hoe kunnen we die eerder beschikbaar maken? We moeten constructief zijn, want als mensen denken dat je iemand zoekt om te kruisigen, kom je nergens.

Galen Low: Laten we het proces doorlopen. Stel dat iedereen akkoord is en we een projectretrospective gaan uitvoeren. Hoe ziet jouw proces eruit als ik de projectmanager ben?

Payson Hall: Stel dat we een groot project van een jaar afronden met een team van tien tot twaalf mensen. Eerst wil ik met jou praten. Jij bent de projectmanager. Ik wil een goede verstandhouding opbouwen. Als jij me hebt uitgenodigd, is dat eenvoudig. Als leidinggevenden of het projectbureau mij hebben gestuurd, moet ik ervoor zorgen dat je me vertrouwt.

Ik leg het proces uit en beloof dat ik je niet zal verrassen. Je krijgt mijn bevindingen te zien voordat iemand anders ze ziet. Je kunt bezwaar maken, mijn mening veranderen, aanvullende gegevens geven of een andere interpretatie bieden.

Dat haalt veel stress weg bij de projectmanager. Ik wil niet dat die bang voor me is of informatie achterhoudt. Zodra we een goede verstandhouding hebben, wil ik begrijpen wat jullie oorspronkelijk wilden bereiken.

Zijn er projectdefinities, rapporten, memo's, een projectcharter of requirements? Wat was de oorspronkelijke definitie van het project? Daarna wil ik begrijpen hoe die in de loop van de tijd veranderde. Waren er wijzigingsverzoeken? Kun je die delen?

Ik probeer te begrijpen waar jullie begonnen en hoe het project zich ontwikkelde. Elk project verandert. Hulpmiddelen worden vervangen en softwareversies worden bijgewerkt. Het is nuttig om daarvan afstand te nemen.

Stel dat een project een jaar zou duren en drie maanden na de start een probleem ontstond doordat PeopleSoft moest worden bijgewerkt. Als dat een maand vertraging veroorzaakte, kan ik in de bevindingen aangeven dat dit niet de schuld van de projectmanager was. In toekomstige projecten moeten we bepalen of een software-update binnen de scope valt en daar tijd voor reserveren.

Mijn eerste stap is zoveel mogelijk huiswerk verzamelen: de projectdefinitie, wijzigingsverzoeken, risico-informatie en statusrapporten. Een van de beste manieren om projectmanagement te leren is een jaar aan statusrapporten lezen. Dan zie je hoe een kleine gebeurtenis in maand twee in maand drie groter wordt en in maand vier een volledig probleem is.

Ik maak aantekeningen over afwijkingen, onverwachte sprongen in de planning en gesprekken in statusrapporten, risicoregisters of wijzigingslogboeken. Vervolgens bouw ik in Excel of Word een eenvoudige tijdlijn. Ik probeer als historicus achteraf de belangrijkste gebeurtenissen te reconstrueren.

Daarna bespreek ik de hiaten met de projectmanager. Wanneer die begrijpt dat ik wil helpen en ik voldoende georiënteerd ben, vraag ik het team om zestig tot negentig minuten voorbereiding.

Ik wil dat ze nadenken over drie soorten dingen: interessante gebeurtenissen, gelukkige of slimme gebeurtenissen en obstakels of problemen. Iedereen heeft een ander perspectief op wat er gebeurde. Dat is het Rashomon-effect.

Tijdens de sessie maak ik een muur vrij en bouw ik een eenvoudige tijdlijn met mijlpalen en gebeurtenissen uit de statusrapporten. Ik leg het proces uit en geef iedereen post-its. Welke gebeurtenissen waren er? Toen Susan trouwde, hadden we een geweldige tijd. Dat helpt mensen zich in de tijd te oriënteren.

Daarna vragen we wat goed ging. We namen Jim aan en hij bleek veel meer vaardigheden te hebben dan verwacht. Vervolgens bespreken we de obstakels: een regenbui, stroomstoring, softwareprobleem of ziekte van een belangrijk teamlid.

Zo bouwen we visueel een tijdlijn op en zien we hoe het project zich ontwikkelde. Vaak brengt dat nieuwe inzichten naar boven. Misschien werd halverwege een nieuwe belanghebbende toegevoegd zonder dat die goed was bijgepraat. Daardoor kwamen er maandenlang extra vragen en verstoringen.

Dat is niet per se iemands fout. Als je voortdurend problemen ontwijkt, vergeet je gemakkelijk een uur uit te trekken om een nieuwe stakeholder bij te praten over het doel, de rollen, de huidige situatie en de uitdagingen. De tijdlijn maakt zichtbaar wanneer de stakeholderwisseling plaatsvond en welke gevolgen die had.

Daarna doen we risicobeheer achteraf. We nemen belangrijke gebeurtenissen en stellen drie vragen: wat hadden we kunnen doen om het risico, de kans of het probleem eerder te signaleren? Wat hadden we kunnen doen om de kans op goede resultaten te vergroten of de kans op slechte resultaten te verkleinen? En wat hadden we kunnen doen om de impact van slechte gebeurtenissen te beperken of de voordelen van goede gebeurtenissen te vergroten?

Zo kunnen we bijvoorbeeld concluderen dat het slim was om veertien laptops te kopen, maar dat we in de toekomst het recht moeten bedingen om ongeopende apparaten te retourneren.

De resultaten vormen de eerste versie van het eindrapport: wat wilde het team doen, wat werd bereikt, hoeveel kostte het, hoe lang duurde het, wat ging goed en welke gebeurtenissen veroorzaakten druk op planning, scope of middelen?

Een retrospectiveverslag moet geen telefoonboek worden. Niemand leest dat. Maak het één of twee pagina's, of een korte samenvattende slide met enkele verbeterpunten.

Galen Low: Hoe diep moet je gaan? We bespreken mijlpalen en gebeurtenissen op de tijdlijn. Sommige mensen brengen tien, vijftien of twintig punten in. Bespreek je alles uitgebreid of gaat het vooral om identificeren en later de drie vragen stellen?

Payson Hall: Dat is een kwestie van inschatting. Mensen moeten genoeg tijd krijgen voor een inzicht, maar je wilt niet in een konijnenhol belanden waardoor de vergadering veel te lang duurt.

Als een analyse drie of vijf minuten nuttig is, ga je door. Als ze niet meer productief is, zeg je: laten we dit meenemen en het offline verder onderzoeken met de mensen die er het meest bij betrokken zijn.

Galen Low: Daarom is faciliteren zo belangrijk. Niet alle problemen van de wereld worden in één sessie opgelost. Sommige zaken gaan offline, maar je moet wel de grote thema's kunnen bespreken en kijken hoe je verbeteringen kunt aanbrengen of succesvolle en slimme ideeën kunt benutten.

Payson Hall: Absoluut. Een goede facilitator bewaakt of je nog constructieve vooruitgang boekt en hoe het gesprek past in het grotere geheel. Ik ben een herstellende ingenieur; bij een interessant probleem wil ik er diep induiken. Maar dat helpt niet altijd. Je hebt iemand nodig die vraagt of je nog vooruitgaat.

Galen Low: Ik vind het goed om dit te zien als een eerste versie van een rapport voor anderen die toekomstige projecten uitvoeren. Die mensen willen waarschijnlijk niet een volledige Ishikawa-analyse doorlopen.

Je zei ook dat dit risicobeheer achteraf is. Veel mensen zien risicobeheer als iets voor de toekomst, maar een retrospective is als een boodschap in een fles aan toekomstige teams: zo voorkom je wat er misging en zo benut je wat goed werkte.

Payson Hall: Precies. Het moet gaan over wat werkte en wat niet werkte, niet over wie goed werkte en wie niet. Dat is de taak van de facilitator. Dit gaat niet over schuld.

Ik heb ooit iets doms gedaan. Een team zou een retrospective houden en ik nodigde mezelf uit, terwijl ik zei dat je geen toeristen wilt. Eén teamlid zei dat hij niet zou komen omdat ze hem overal de schuld van zouden geven. Ik ging toch als observator mee en ontdekte dat de facilitator verschrikkelijk was. Die wilde weten wie verantwoordelijk was.

Het team weigerde de persoon voor de bus te gooien. Ze zeiden dat het niet belangrijk was wie het had gedaan; dit was wat er was gebeurd. Later ontdekte ik dat de persoon met een alcoholprobleem kampte. Dat was persoonlijke informatie en niet relevant voor de retrospective.

Je wilt niet afhankelijk zijn van vermoeide mensen die zelf discipline en empathie moeten opbrengen om iemand niet te kruisigen. Je hebt een goede facilitator nodig die begrijpt dat het gaat om het verbeteren van het proces, niet om het aanwijzen van schuldigen.

Ga ervan uit dat iedereen het beste deed met de beschikbare informatie. Misschien ontbraken bepaalde vaardigheden. Dan zeg je niet dat de projectmanager schuldig is; je zegt dat het team niet over de benodigde vaardigheden beschikte en die voor toekomstige projecten moet versterken.

Galen Low: Psychologische veiligheid zit dus verweven in de manier waarop je de sessie opzet. Je bouwt vooraf vertrouwen op, legt het proces uit en maakt duidelijk dat je niet vraagt wie iets heeft gedaan, maar wat er is gebeurd. Hoe stuur je bij als mensen toch in een schuldspel terechtkomen?

Payson Hall: De eerste keer geef je een gele kaart. Je zegt dat het niet gaat om wie wat deed, maar om wat er gebeurde en welke gevolgen dat had. De tweede keer kun je opnieuw ingrijpen of een pauze nemen en de persoon apart spreken. Je maakt duidelijk dat het gesprek gaat over wat we hebben geleerd, wat werkte en wat niet werkte — niet over wie wel of niet werkte.

Galen Low: En hoe voorkom je dat leidinggevenden tussen de regels door toch iemand de schuld geven?

Payson Hall: Persoonlijke kwesties horen niet in het rapport. De projectmanager moet die afhandelen. In het rapport beschrijf je projectproblemen neutraal. Als middelen werden herverdeeld naar een project met hogere prioriteit, schrijf je dat het project voor uitdagingen kwam te staan doordat teamleden elders werden ingezet.

De aanbeveling kan zijn om meer personele flexibiliteit in te bouwen of de projectmanager zo vroeg mogelijk te informeren over herverdeling, zodat die tijd heeft om vervanging te regelen.

Als je planning ervan uitgaat dat niemand ziek wordt en iedereen elke week veertig uur beschikbaar is, is die planning kwetsbaar. Mensen worden ziek, kinderen vallen van fietsen en familiegebeurtenissen komen voor. Een bevinding kan zijn dat we middelen te agressief hebben toegewezen en meer tijd, geld of mensen nodig hadden.

Galen Low: Dat onderscheid is nuttig: projectproblemen waar we van kunnen leren tegenover persoonlijke personeelskwesties die niet in het rapport thuishoren.

Payson Hall: Het rapport moet ook diplomatiek zijn. Als consultant word ik betaald om te zeggen wanneer iets niet goed is, maar er zijn manieren om dat te formuleren zonder de situatie te laten escaleren. Gebruik positieve taal: dit hebben we gedaan, en dit raden we aan om het in de toekomst anders te doen. Niet: we hebben dit volledig verpest.

Galen Low: We hebben het proces nu doorlopen: voorbereiding, documentatie bekijken, mijlpalen op een tijdlijn zetten, bespreken wat goed en slecht ging en aanbevelingen formuleren. Veel mensen zeggen vervolgens: wat is het nut? We maken een rapport dat niemand leest, het wordt verkeerd geïnterpreteerd en verdwijnt in een kast. Hoe zorg je ervoor dat aanbevelingen daadwerkelijk tot verandering leiden?

Payson Hall: Een rapport van dertig pagina's met bevindingen en aanbevelingen wordt niet gelezen. Houd het kort en stel prioriteiten. Als de projectmanager zes verbeterpunten ziet, kies er dan twee of drie uit en werk die goed uit voor de leiding.

Overweldig mensen niet met actiepunten. De andere bevindingen blijven bekend bij het team en worden informeel meegenomen naar volgende projecten. Er is een formele laag — twee of drie bevindingen voor het PMO of de directie — en een informele laag, waarbij deelnemers de lessen meenemen.

Er bestaat een mythe dat alle retrospectives in een grote database met geleerde lessen terechtkomen. Ik heb dat in geen enkele organisatie goed zien werken. Het is te omvangrijk en te contextafhankelijk. De beste aanpak is meestal om twee of drie aanbevelingen onder de aandacht van de directie te brengen.

Een kleine speciale projectruimte kan bijvoorbeeld enorm veel tijd besparen. Teams verliezen vaak uren met het zoeken naar vergader- of trainingsruimtes. Een vaste ruimte kan persoonsweken besparen. Als leidinggevenden dezelfde aanbeveling meerdere keren zien, kunnen ze uiteindelijk besluiten er iets aan te doen.

Galen Low: Ik vind de scheiding tussen strategische aanbevelingen en informeel leren ook waardevol. Iedereen die aan de retrospective deelnam, neemt een zaadje mee naar het volgende project. Dat is moeilijk meetbaar, maar wel belangrijk.

Payson Hall: Om terug te komen op risicobeheer: na een retrospective zijn mensen beter voorbereid om risico's voor het volgende project te bespreken. Ze hebben echte ervaringen, geen hypothetische voorbeelden. Ze kunnen zeggen: dit deden we en het werkte goed; dit deden we en het was een slecht idee. Dat verbetert het risicobeheer en verspreidt de kennis door de organisatie.

Galen Low: Het is inderdaad een verhaal dat mensen met elkaar delen. De database is ons geheugen. Een projectgebeurtenis wordt een verhaal waarmee we kennis overdragen.

Een vraag uit het publiek ging over een prospectieve analyse of premortem. Je kunt risicobeheer vóór een project doen in plaats van erna. Wat vind je ervan om beide te doen? Hoe verhouden risicobeheer en iteratieve retrospectives zich tot elkaar?

Payson Hall: Ze lopen in elkaar over. In een agile retrospective bespreek je vaak barrières en dingen waarvan je zegt: ik wou dat we dit anders hadden gedaan. Die punten worden acties om risico's in de volgende sprint te beperken. Bij Agile vinden retrospective en risicobeheer dus vaak tegelijkertijd plaats.

Galen Low: Dat is logisch. Je kijkt terug, maar de volgende sprint ligt in de toekomst. Het is nog steeds hetzelfde gesprek.

Een andere vraag ging over situaties waarin belangrijke teamleden worden weggehaald naar een ander project. Hoe leg je dat vast en zorg je ervoor dat het invloed heeft buiten dit ene project?

Payson Hall: Ik denk in termen van bevindingen. De bevinding kan zijn: het project ondervond problemen met middelen doordat teamleden werden ingezet op projecten met een hogere prioriteit. Dat is een neutrale formulering en geeft de directie het voordeel van de twijfel.

De aanbeveling kan zijn om de bezetting te vergroten voor meer flexibiliteit en de projectmanager zo vroeg mogelijk te informeren wanneer mensen worden herplaatst. Dan is er tijd om te reageren en vervanging te regelen. Je zegt niet dat iemand iets verkeerd heeft gedaan; je zegt wat er gebeurde, welk gevolg het had en wat je in de toekomst kunt doen om het te voorkomen.

Galen Low: Wat zijn de belangrijkste onderwerpen om in een retrospective te bespreken als je weinig tijd hebt?

Payson Hall: Dat hangt van de context af. Vanuit mijn ervaring is een duidelijke, gedeelde en goedgekeurde projectdefinitie belangrijk. En wanneer die verandert: hebben we een effectief proces voor verandermanagement?

Als je extra versieringen aan de kerstboom wilt toevoegen, kost dat meer tijd en geld. Scopegroei zonder extra middelen is een van de oorspronkelijke problemen die veel andere problemen veroorzaakt. Vaak zeggen mensen dat ze het project hebben onderschat, terwijl het project in werkelijkheid is gegroeid zonder dat iemand tijdig aan de bel trok.

Galen Low: Er is inderdaad een relatie tussen alles. Het gaat om het gemeenschappelijke begrip met de betrokken stakeholders en om de waardevolste invalshoek voor het gesprek.

Payson, bedankt dat je vandaag bij ons was. Het was een eer je te ontvangen. Hoe kunnen luisteraars meer te weten komen over wat je doet bij Catalysis Group?

Payson Hall: Ga naar catalysisgroup.com. Daar vind je informatie over trainingen en advies. Bij de bronnen staan ook artikelen over risicobeheer en het uitvoeren van een risicobeheersessie. Die zijn ook nuttig als voorbereiding op een retrospective.

Galen Low: Geweldig. Dat bevestigt dat Payson een zeer onderhoudende schrijver is. In elk artikel dat ik van je heb gelezen, heb ik hardop gelachen, maar ik heb het verhaal ook onthouden. Voor iedereen die denkt dat retrospectives en risicobeheer saai zijn: bekijk het werk van Payson. Ik voeg de link toe aan de shownotities.

Luisteraars, ik hoop dat jullie hier veel uit hebben gehaald. Er waren nog enkele vragen die we niet konden behandelen; die brengen we in de gemeenschap ter sprake.

Payson Hall: Als mensen me na afloop per e-mail vragen willen sturen, beantwoord ik die graag.

Galen Low: Daar hebben jullie het. Als je wilt deelnemen aan het gesprek met meer dan duizend gelijkgestemde kampioenen in projectmanagement, sluit je dan aan bij onze gemeenschap. Ga naar thedigitalprojectmanager.com/membership voor meer informatie. Als je dit gesprek interessant vond, abonneer je dan en blijf in contact via thedigitalprojectmanager.com.

Tot de volgende keer, bedankt voor het luisteren.