Projectretrospectief: vragen, agenda en sjabloon

Wat is een projectretrospectief?

Een retrospectief is een overleg waarin een team terugkijkt op een bepaalde periode en beslist wat het wil veranderen. Het kan na een project, een fase of een werkcyclus. Bespreek samenwerking, processen en omstandigheden zonder schuldigen te zoeken.

In een statusoverleg gaat het over afgeronde en vertraagde taken. Bij een retrospectief vraag je waarom het werk zo liep en wat de volgende keer helpt. Een lijst met problemen is een begin. Spreek een resultaat af dat je kunt toetsen.

Maak van het overleg geen verdediging van een rapport tegenover het management. Wie straf verwacht voor een open antwoord, kan nuttige details weglaten. Leg vooraf het doel en de gespreksregels uit.

Het team voorbereiden

Baken af, bijvoorbeeld ‘voorbereiding en start van een trainingswebinar’ in plaats van ‘alles wat niet werkt’. Nodig betrokkenen uit die verschillende kanten kennen.

Vraag iedereen om een concreet geval: wat gebeurde, wanneer, wat was het gevolg en wat hielp? Verzamel eventueel vooraf notities en laat mensen bij het overleg even stil nadenken, zodat de eerste uitgesproken mening niet de toon zet.

Houd een plan, taakgeschiedenis, goedgekeurde versies of berichten bij de hand om feiten te controleren. Een ontbrekend verslag betekent niet dat niets is gebeurd. Een niet-opgeslagen opmerking bewijst niet dat iemand niets deed.

Agenda en vragen voor het retrospectief

Dit is een voorbeeldindeling voor een klein team. Pas die zo nodig aan. Een ingewikkeld onderwerp kan een apart overleg vragen.

Als de discussie gaat over wie meestal fouten maakt, ga dan terug naar het geval. Vraag in plaats van ‘We krijgen nooit goed materiaal’: ‘Wat ontbrak deze keer en wanneer viel dat op?’.

Probeer niet alles in één overleg op te lossen. Kies een probleem dat het werk raakt en een haalbare volgende stap heeft. Noteer de andere zaken apart, zodat ze niet verdwijnen of beloften zonder verantwoordelijke worden.

Van klacht naar toetsbare verandering

Een team bereidde een webinar voor. De dag ervoor bleek dat enkele goedgekeurde wijzigingen niet in de presentatie stonden. In het overleg zei iemand: ‘We moesten weer alles op het laatste moment overdoen.’ De frustratie gaf nog geen oplossing.

De deelnemers reconstrueerden het geval met de documenten. Opmerkingen kwamen in twee chats. Sommige wijzigingen waren verwerkt, maar een gezamenlijke status ontbrak. Eén lijst zou kunnen helpen om weglatingen vóór de goedkeuring te zien.

Ze proberen het bij het volgende trainingswebinar. Coördinator Marina maakt vooraf de lijst. Elke opmerking krijgt ‘aanvaard’, ‘in behandeling’ of ‘gecontroleerd’, of een reden voor afwijzing. De dag vóór de lancering vergelijkt de redacteur de lijst met de eindpresentatie.

Bij het volgende overleg bekijkt het team of goedgekeurde wijzigingen nog ontbreken en hoe prettig de lijst werkte. Keren de weglatingen terug, onderzoek dan ook onduidelijke formuleringen en late wijzigingen voordat je het hulpmiddel de schuld geeft.

Sjabloon voor de uitkomst

Project en periode:
Deelnemers:
Wat hielp en behouden blijft:

Gekozen probleem:
Observaties en concrete voorbeelden:
Vermoedelijke oorzaak:
Wat nog onbekend is:

Te testen experiment:
Verantwoordelijke:
Voorbereidingstermijn:
Waar we de voortgang noteren:
Hoe we het resultaat beoordelen:
Wanneer we het resultaat bespreken:
Besluit na controle: [behouden / wijzigen / stoppen]

Overige onderwerpen voor het volgende gesprek:

Stuur de samenvatting en laat deelnemers onjuistheden corrigeren. Noteer het als een besluit van een afwezige nodig is. Vraag die persoon om instemming voordat je een taak toewijst of namens diegene een belofte opschrijft.

• De afbakening is duidelijk.
• Feiten staan los van aannames.
• Het team weet wat het wil behouden.
• Er is een haalbare wijziging gekozen.
• De verantwoordelijke heeft ingestemd.
• Een controlemoment is afgesproken.