Het is mislukt. Waarom?

Het is zes maanden later en het project is mislukt. Schrijf elke reden op alsof het al gebeurd is.

We vertrouwden op de sandbox van de betaalprovider en hebben nooit getest tegen de productielimieten. Het verkeer op de lanceerdag legde de checkout plat.
Alleen Priya begreep de scripts voor de datamigratie. Ze ging in maand drie met verlof en alles lag stil.
De juridische afdeling beoordeelde de algemene voorwaarden twee weken voor de lancering en we moesten de toestemmingsflow opnieuw bouwen.
Vroege waarschuwingssignalen

Wat zouden we als eerste merken als dit begon te gebeuren?

Supporttickets bij de leverancier waarop het langer dan twee dagen duurt voordat er een reactie komt.
Dezelfde persoon wordt getagd bij elke pull request review voor de migratie.
Er verschijnen midden in de sprint nieuwe tickets met 'snel verzoekje van sales' in de omschrijving.
Hoe we het voorkomen

Wat kunnen we nu doen om te voorkomen dat dit gebeurt?

In sprint twee een loadtest draaien op de productieomgeving van de leverancier, voordat we erop verder bouwen.
Iemand samen met Priya aan de migratiescripts laten werken en het runbook voor het eind van de maand documenteren.
De juridische review van de toestemmingsflow inplannen tijdens het ontwerp, niet na de bouw.
Eigenaren en vervolgstappen

Wie is eigenaar van elk toprisico, en voor wanneer?

Marco is eigenaar van de loadtest bij de leverancier, deadline eind sprint twee.
Ik ga samen met Priya aan de migratie werken en we publiceren het runbook uiterlijk de 15e.
Dana plant de juridische review van de toestemmingsflow in vóór de goedkeuring van het ontwerp volgende vrijdag.

Wat is een pre-mortem retrospective?

Een pre-mortem is een risicosessie die je houdt bij de kick-off van een project, voordat scope, deadlines en budget vastliggen. Het team stelt zich een concrete toekomst voor: het is zes maanden later en het project is mislukt. Daarna schrijft iedereen op waarom het misging, alsof de mislukking al heeft plaatsgevonden. Psycholoog Gary Klein ontwikkelde de techniek en beschreef die in 2007 in zijn Harvard Business Review-artikel "Performing a Project Premortem". De methode bouwt voort op onderzoek naar "prospective hindsight" (vooruitkijkende terugblik). Daaruit bleek dat mensen specifiekere oorzaken bedenken als ze zich voorstellen dat een gebeurtenis al heeft plaatsgevonden. Het werkt dankzij de framing. Vraag je een team "wat kan er misgaan?", dan krijg je beleefde, algemene antwoorden zoals "scope creep" of "communicatieproblemen". Vraag je "waarom is het mislukt?", dan noemen mensen echte oorzaken: de API van de leverancier die nooit op belasting is getest, de stakeholder die niet is geraadpleegd, de ene engineer bij wie alle kennis zit. Door de mislukking als gegeven te nemen, wordt het ook veilig om twijfels te uiten die tijdens een optimistische kick-off anders negatief of illoyaal zouden klinken. Dit pre-mortem-template doorloopt in TeamRetro vier stappen. Eerst noteer je de redenen waarom het project is mislukt. Daarna benoem je de vroege waarschuwingssignalen, spreek je preventiestappen af en geef je tot slot elk toprisico een eigenaar en een datum. Die laatste stap is het belangrijkst. Een risico zonder eigenaar en deadline is meestal aan het eind van de eerste week vergeten. Gebruik anonieme ideeën, zodat senioriteit niet bepaalt wat mensen opschrijven. Werk je met een verspreid team, verzamel de ideeën dan asynchroon gedurende een dag en kom alleen samen om te stemmen en eigenaren toe te wijzen.

Format van de pre-mortem retrospective

Het is mislukt. Waarom?

Het is zes maanden later en het project is mislukt. Schrijf elke reden op alsof het al gebeurd is.

Deze kolom is de kern van de pre-mortem. Schets de situatie duidelijk: het project is afgelopen, het is mislukt en iedereen weet het. Vraag mensen in de verleden tijd te schrijven ("We haalden de lancering niet omdat..."), want die framing levert concretere oorzaken op dan speculeren over wat er mis zou kunnen gaan. Houd ideeën anoniem, zodat senior stemmen de groep niet sturen. Geef 8–10 minuten om in stilte te schrijven, moedig één reden per idee aan, groepeer daarna vergelijkbare ideeën en stem om de toprisico's te bepalen die je meeneemt.

Vroege waarschuwingssignalen

Wat zouden we als eerste merken als dit begon te gebeuren?

Vroege waarschuwingssignalen maken van vage angsten iets waar het team op kan letten. Vraag voor elk toprisico uit de eerste kolom wat het eerste waarneembare signaal zou zijn: een metric, een gemist controlemoment, een patroon in de standups. Stuur aan op signalen die specifiek en meetbaar zijn. "Het moreel daalt" is lastig te volgen. "Twee sprints achter elkaar meer dan 30% doorgeschoven werk" valt makkelijk op. Dit worden de triggers die de risico-eigenaren in de gaten houden.

Hoe we het voorkomen

Wat kunnen we nu doen om te voorkomen dat dit gebeurt?

Hier gaat het team van zorgen naar actie. Richt je alleen op de risico's met de meeste stemmen, meestal drie tot vijf. Vraag bij elk risico wat het team deze week of deze maand kan doen om de kans of de impact te verkleinen. Geef de voorkeur aan kleine, concrete stappen boven grote procesveranderingen. Heeft een preventie-idee goedkeuring of budget nodig, noteer dan wie je dat moet vragen. Houd het praktisch; het doel is een kortere lijst acties die mensen ook echt uitvoeren.

Eigenaren en vervolgstappen

Wie is eigenaar van elk toprisico, en voor wanneer?

Om deze kolom draait de hele sessie. Elk toprisico heeft één eigenaar met naam en een datum nodig, anders vervagen de zorgen van vandaag voordat de eerste week voorbij is. Eigenaren hoeven het risico niet alleen op te lossen; ze zijn verantwoordelijk voor het in de gaten houden van de waarschuwingssignalen en zorgen dat de preventiestap wordt uitgevoerd. Leg elk risico vast als actie in TeamRetro, zodat het meegaat naar volgende retrospectives, en plan bij de eerste mijlpaal een korte check-in om de voortgang te bespreken.

Wanneer dient u deze retrospective te gebruiken?

  • Bij de kick-off van een nieuw project, productlancering of groot initiatief, voordat scope, deadlines en budget definitief zijn.
  • Voor een mijlpaal waarbij veel op het spel staat, zoals een migratie, go-live of contractondertekening, waarbij een late verrassing duur zou zijn.
  • Als een team ongewoon optimistisch is over een plan en stillere teamleden hun twijfels misschien voor zich houden.
  • Bij de start van een samenwerking met een nieuwe leverancier, partner of multidisciplinaire groep waarvan de afhankelijkheden nog niet goed bekend zijn.
  • Aan het begin van een nieuw kwartaal of program increment, om het plan op de proef te stellen voordat het team zich eraan verbindt.

Voorstellen voor ijsbrekers

  • Wat is het meest memorabele plan dat je ooit zag mislukken, op het werk of privé, en wat was het eerste waarschuwingssignaal?
  • Als dit project een film was, welk genre zou de versie zijn waarin het mislukt?

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 pre-mortem bij de kick-off van het project, voordat toezeggingen vastliggen. Doe het nooit midden in een crisis, als het team problemen moet oplossen en het voorstellen van een mislukking alleen maar extra spanning geeft.
  • Houd ideeën anoniem. Als namen zichtbaar zijn, bepalen de zorgen van de meest senior persoon de toon en schrijven anderen alleen nog wat instemming op.
  • Sta in de eerste kolom op de verleden tijd. "Waarom is het mislukt?" levert specifiekere, realistischere risico's op dan "Wat kan er misgaan?", dus herformuleer ideeën voorzichtig als ze terugvallen in hypotheses.
  • Stem om de lijst terug te brengen tot drie tot vijf toprisico's voordat je preventie bespreekt. Wie elk idee wil aanpakken, versnippert de aandacht van het team en dan komt er niets van terecht.
  • Sluit de sessie pas af als elk toprisico één eigenaar en een datum heeft. Zonder die twee zijn de verzamelde risico's vergeten voordat de eerste week om is.
  • Werk met verspreide teams asynchroon: verzamel ideeën gedurende een dag over tijdzones heen en kom daarna 30 minuten samen om alleen te groeperen, te stemmen en eigenaren toe te wijzen.

Veelgestelde vragen

Wat is het verschil tussen een pre-mortem en een post-mortem?
Een post-mortem vindt plaats nadat een project is afgerond of mislukt en kijkt terug op wat er werkelijk misging. Een pre-mortem vindt plaats voordat het werk begint en stelt zich de mislukking vooraf voor, zodat het team die kan voorkomen terwijl er nog tijd is om bij te sturen.
Wie heeft de pre-mortemtechniek bedacht?
Psycholoog Gary Klein bedacht de pre-mortem en beschreef die in 2007 in zijn Harvard Business Review-artikel "Performing a Project Premortem". De methode is gebaseerd op onderzoek waaruit blijkt dat mensen specifiekere oorzaken vinden als ze zich voorstellen dat een uitkomst al heeft plaatsgevonden.
Hoe lang duurt een pre-mortem?
De meeste pre-mortems duren 45–60 minuten voor een team van vijf tot tien mensen. Met de asynchrone optie kan de live meeting korter worden, tot ongeveer 30 minuten, omdat de ideeën al vóór het gesprek zijn verzameld.
Wanneer houd je een pre-mortem?
Houd hem bij de kick-off van een project, voordat toezeggingen zoals scope, deadlines en budget vastliggen. Doe het liever niet midden in een crisis, wanneer het team zich moet richten op het oplossen van echte problemen.
Waarom moeten pre-mortemideeën anoniem zijn?
Als namen zichtbaar zijn, herhalen mensen vaak de zorgen van de meest senior persoon in de ruimte. Anonieme ideeën brengen de risico's naar boven waar mensen zich echt zorgen over maken, ook als die te maken hebben met beslissingen van het management.
Kun je een pre-mortem asynchroon uitvoeren?
Ja. Verspreide teams kunnen in TeamRetro gedurende een dag ideeën verzamelen en daarna alleen samenkomen om te groeperen, op de toprisico's te stemmen en eigenaren met datums toe te wijzen.
Bent u klaar om deze retrospective te houden?Probeer deze retrospective live eens