Wat is een post-mortem retrospective?
Een post-mortem is het gesprek dat je team voert nadat iets is afgelopen. Soms is dat een incident: een systeem viel uit, een release liep mis, een klant kreeg de gevolgen te voelen. Net zo vaak gaat het om een gewoon project dat is afgerond, en wil je een duidelijke agenda voor de evaluatie in plaats van er zelf een te bedenken. Deze template werkt voor allebei. Je schetst eerst het kader met de doelen en scope van het project, loopt door wat goed ging en wat niet, duikt waar nodig in de grondoorzaken en zet de eerlijke inzichten om in geleerde lessen die je organisatie opnieuw kan gebruiken. Zo werkt het in TeamRetro. Iedereen voegt eerst privé zijn eigen observaties toe, zodat de luidste stem in de ruimte het verhaal niet bepaalt voordat stillere collega's iets hebben opgeschreven. Daarna worden de ideeën gegroepeerd en besproken en wordt erover gestemd. Zo richt je je op de paar thema's die ertoe doen, in plaats van veertig opmerkingen in willekeurige volgorde af te werken. Dat is het verschil met een document dat je in je eentje invult: dit is een live debrief die je hele team samen doet, en die eindigt met eigenaren en deadlines voor echte acties, niet met een rapport dat niemand ooit nog opent. Gebruik het als standaard projectevaluatie bij de afsluiting van een oplevering, campagne, migratie of kwartaal, en als incidentevaluatie wanneer er iets is misgegaan en je een verslag zonder schuldvraag nodig hebt van de tijdlijn en de oorzaken. Het laatste onderwerp biedt ruimte voor kudos, want erkenning voor de mensen die het werk hebben gedragen hoort bij een goede afsluiting. Hoe dan ook moet het team weggaan met een helder beeld van wat het gaat herhalen, waar het mee stopt en wie wat gaat doen. Exporteer het rapport als je klaar bent, zodat de lessen vindbaar blijven voor het volgende team dat in dezelfde situatie belandt.
Format voor de post-mortem retrospective
Projectoverzicht, doelen en scope
Wat wilde het project bereiken, en wanneer?
Dit onderwerp schetst het kader voordat iemand ergens een oordeel over velt. Vraag naar het oorspronkelijke doel, de afgesproken scope, de tijdlijn en de succescriteria, en naar wat er daadwerkelijk is opgeleverd. Gebruik het bij een incidentevaluatie juist voor de tijdlijn: wat ging er kapot, wanneer werd het ontdekt, wie waren erbij betrokken en hoe is het opgelost. Houd interpretaties buiten deze kolom en bewaar meningen voor de volgende onderwerpen. Zijn mensen het niet eens over wat de doelen of succescriteria eigenlijk waren? Dan is die onenigheid zelf een bevinding die je moet vastleggen.
Wat ging goed
Welke successen en werkwijzen zijn het herhalen waard?
Teams razen vaak langs dit onderwerp, zeker na een moeilijk project of een stressvol incident, dus bewaak de tijd ervoor. Je zoekt werkwijzen die het herhalen waard zijn, geen complimenten; kudos krijgen later een eigen onderwerp. Plaatst iemand lof, vraag dan wat het precies deed werken, zodat het antwoord herbruikbaar wordt. Let op successen die voortkwamen uit individueel heldenwerk, en benoem die als risico.
Wat ging niet goed
Waar liepen we vast, ging iets kapot of misten we doelen?
Hier zit het grootste deel van de leerwaarde, dus spreek de basisregel zonder schuldvraag hardop uit voordat je begint: je onderzoekt systemen en beslissingen, geen mensen. Vraag om specifieke voorbeelden in plaats van vaag gemopper. Met "de communicatie was slecht" kun je niets, maar met "we hoorden van de gewijzigde deadline in een gesprek op de gang" wel. Gebruik stemmen, zodat de discussie niet uitwaaiert over elke ergernis van de afgelopen drie maanden.
Grondoorzaakanalyse
Waarom ging het mis, niet alleen dát het misging?
Optioneel bij een eenvoudige projectevaluatie, onmisbaar bij een incident. Neem de problemen met de meeste stemmen uit het vorige onderwerp en blijf vragen waarom, tot je bij een omstandigheid uitkomt en niet bij een persoon: een ontbrekende vangrail, een onduidelijke eigenaar, tijdsdruk, een aanname die niemand heeft getoetst. De Five Whys werkt hier goed, net als de vraag waardoor de verkeerde actie op dat moment logisch leek. Stop zodra je bij iets komt wat je echt kunt veranderen, en noteer bijdragende factoren apart van de directe aanleiding.
Geleerde lessen
Welke lessen nemen we mee naar de toekomst?
Dit is het "wat betekent dit nu" dat observaties omzet in kennis die je kunt hergebruiken. Blijf bij elk idee doorvragen tot het een gedrag, een trigger of een vangrail benoemt die bij het volgende project nog steeds steek houdt. Maak onderscheid tussen wat dit team zelf kan veranderen en wat naar een manager of een andere groep moet, en wees eerlijk over die tweede lijst. Formuleer elke les zo dat iemand die er niet bij was hem in het geëxporteerde rapport kan lezen en begrijpen zonder dat jij hoeft uit te leggen wat ermee bedoeld wordt.
Actiepunten, eigenaren en deadlines
Wie doet wat, en wanneer?
Een post-mortem zonder toegewezen acties telt niet, dus neem hier echt de tijd voor in plaats van het in de laatste twee minuten te proppen. Zet de lessen met de meeste stemmen om in een klein aantal concrete acties, elk met een eigenaar bij naam en een deadline, vastgelegd in TeamRetro zodat ze in je volgende sessie terugkomen. Twee of drie acties met een duidelijke eigenaar zijn beter dan tien ambitieuze voornemens. Hoort een actie bij iemand die er niet bij is, spreek dan af wie het bij die persoon neerlegt en wanneer.
Waardering en kudos
Wie verdient erkenning voordat we afsluiten?
Sluit af met de mensen, niet met de problemen. Vraag iedereen om een specifiek persoon te noemen en iets specifieks wat die persoon deed; dat betekent veel meer dan algemene dank en werkt zelfs na een moeizaam project. Het is het belangrijkst wanneer de evaluatie zwaar was, omdat het het team eraan herinnert dat een mislukking onderzoeken niet hetzelfde is als elkaar de schuld geven. Houd het kort, lees er een paar hardop voor en laat het geëxporteerde rapport de rest dragen.
Wanneer dient u deze retrospective te gebruiken?
- Een project, oplevering, migratie of campagne is net afgerond en je wilt een gestructureerde evaluatie, geen informeel gesprek dat vervolgens wegebt
- Een incident, storing of mislukte release vraagt om een post-mortem zonder schuldvraag over de tijdlijn, de grondoorzaken en preventieve acties
- Een langlopend programma heeft een fase afgerond en je wilt de geleerde lessen vastleggen zolang de details nog vers zijn
- Een multidisciplinaire groep gaat uit elkaar, en dit is je laatste kans om te evalueren en bijdragers te erkennen voordat mensen aan nieuw werk beginnen
- Iets ging onverwacht goed en je wilt begrijpen waarom, zodat je het kunt herhalen in plaats van het aan geluk toe te schrijven
Voorstellen voor ijsbrekers
- Hoe voelde dit project of incident, in één woord, toen je er middenin zat?
- Als je jezelf op dag één één zin advies kon sturen, wat zou daarin staan?
Wilt u een opwarmoefening waarbij uw team daadwerkelijk meedoet, en niet alleen hardop antwoorden geeft? Bekijk gratis ijsbrekers →
Ideeën en tips voor uw retrospectievevergadering
- Houd de sessie binnen een week of twee nadat het project is afgesloten of het incident is opgelost. Herinneringen vervagen snel, en de bruikbare details verdwijnen mee
- Benoem aan het begin dat er geen schuldige wordt gezocht. Je kijkt naar beslissingen, systemen en druk, niet naar iemand die je verantwoordelijk kunt houden
- Neem een paar minuten om het eens te worden over het projectoverzicht voordat de meningen loskomen. Een gedeeld kader voorkomt dat de sessie verzandt in een discussie over wat het doel eigenlijk was
- Sla de grondoorzaakanalyse over of kort hem in bij een soepele projectevaluatie, en besteed er juist meer tijd aan bij incidenten waar preventie het doel is
- Prioriteer met stemmen en laat de meeting niet eindigen zonder eigenaren en deadlines voor de belangrijkste acties, anders blijven je geleerde lessen theorie
- Neem de acties van de vorige post-mortem mee en bespreek die eerst. Niets verbetert de opvolging zo goed als weten dat erop wordt gecontroleerd
