Skip to main content

Ved afslutningen af et projekt udfører du opgaver som at arkivere dokumentation, fakturere kunden, gennemføre præstationsvurderinger for dit team og selvfølgelig det vigtigste af det hele – projektretrospektivet.

Retrospektiver er beregnet til at reflektere over, hvordan projektet gik, og hvad der kan forbedres i fremtidige projekter (og de er ikke en undskyldning for at holde en fest med 80'er-tema, selvom det måske lyder sådan).

Hvad er et projektretrospektiv?

Projektretrospektivet er en formel aktivitet, hvor projektets interessenter bliver bedt om at se tilbage på det afsluttede projekt og reflektere over, hvad der gik godt, hvad der ikke gik så godt, og hvad der kunne forbedres. Du udarbejder en handlingsplan for at forbedre dine fremtidige projekter og processer.

Continue Reading for Free

Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.

Som en af de vigtigste agile begivenheder eller ceremonier bruger projektledere retrospektiver til at vurdere, hvordan teamet arbejder sammen, og forbedre deres proces. Projektlederen skal skabe et trygt rum, så åben og ærlig (og muligvis ubehagelig) feedback kan deles under sessionen.

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Hvorfor er projektretrospektiver vigtige?

Et vellykket retrospektiv vil forbedre dine projektprocesser og øge sandsynligheden for, at fremtidige projekter lykkes. Her er nogle andre grunde til, at projektretrospektiver er vigtige:

  • Kontinuerlig forbedring: Teamet kan reflektere over, hvad der gik godt, og hvad der ikke gjorde. Lær af eventuelle fejl, og identificer succeser, som I ønsker at gentage. Efterhånden som I foretager ændringer i jeres processer og arbejdsgange på baggrund af dette, vil teamet forbedre sig og arbejde bedre sammen over tid.
  • Bedre teambuilding og teamsamarbejde: Retrospektivet giver teamet mulighed for at knytte tættere bånd. Det er et trygt rum, hvor de giver konstruktiv feedback og finder ud af, hvordan de kan samarbejde bedre fremover. Brug også retrospektiver til at fejre sejre, da det forbedrer teamets moral og motivation.
  • Forbedret problemløsning: Teamet kan løse problemer omkring udfordringer og blokeringer, som de stod over for under projektet, og finde ud af, hvordan de kan løse lignende udfordringer i fremtidige projekter. De kan også dele bedste praksis med hinanden, hvilket forbedrer deres samlede viden.
  • Bedre ansvarlighed: Ved at samle teamet for at diskutere, hvad der gik galt, styrker retrospektiver ansvarligheden og opmuntrer teammedlemmerne til at tage ejerskab over deres arbejde. Placér ikke skylden for fejl, men fokusér på, hvad der skal ændres for at undgå de samme fejl fremover.
  • Forbedret projektplanlægning: Dokumentation af risici, projektantagelser, blokeringer og andre ting, der gik galt under projektet, sikrer, at du kan tage højde for disse ting i projektplaner for fremtidige projekter.

Sådan gennemfører du projektretrospektiver

Lad os se på nogle praktiske trin og råd til, hvordan du faciliterer en effektiv retrospektiv session for dit projekt.

Trin 1: Skab en tillidskultur

Det kan være svært at få folk til at være åbne og give feedback. Det er endnu sværere, når der er mistillid blandt projektteamet og interessenterne. 

  • Blev feedback tidligere kritiseret? 
  • Fik teammedlemmerne en følelse af at blive intimideret, når de delte idéer og feedback? 
  • Blev der foretaget negative handlinger, efter at feedback var blevet delt, som kunne opfattes som straf (for eksempel at fjerne visse frynsegoder)? 
  • Blev der spillet et skyldspil, hvis der blev afdækket problemer? 

Hvis du svarede ja på nogle af disse spørgsmål, er det klare grunde til, at der kan være mistillid og manglende villighed til at være åben.

Så hvordan får du folk til at være åbne og dele feedback? Hvordan opbygger du en tillidskultur og får folk til at føle, at de befinder sig i et trygt rum?

illustration af to valnødder, der repræsenterer teammedlemmer, som kommer ud af deres skal under projektretrospektiver
At få folk til at åbne sig er en af de sværeste dele af et projektretrospektiv.

Du kan prøve følgende:

  • Fremmér åben og ærlig kommunikation: Sørg for, at dit team føler sig værdsat og anerkendt. De vil være mere villige til at åbne op og dele, hvis de ved, at de ikke bliver ignoreret eller marginaliseret.
  • Skab muligheder for samarbejde: Det kan være daglige statusopdateringer om projektet eller opgaver, der ikke vedrører projektet, såsom en teambuildingaktivitet. Hvis folk får mulighed for at samarbejde, vil de føle sig mere trygge ved at kommunikere.
  • Gør feedback til en del af teamets kultur: I softwareudviklingsprojekter er det almindeligt, at teammedlemmer får deres kode fagfællebedømt af andre i teamet som en del af den almindelige udviklingsproces. Se efter muligheder for at gøre noget lignende på dit projekt, så teamet regelmæssigt kan både give og modtage positiv og negativ feedback.

Trin 2: Fastlæg, hvilken type feedback du gerne vil indsamle

Der sker meget under et projekt, og derfor er der mange muligheder for at indsamle en bred vifte af feedback under en retrospektiv. Det er fint, men det kan også virke overvældende.

Når du planlægger at afholde en retrospektiv, skal du definere omfanget af den feedback, du gerne vil modtage fra deltagerne. 

Prøv at definere nogle temaer, som du gerne vil indsamle feedback om, såsom:

  • Teamets præstation: Hvordan klarede teamet sig under projektet? Blev deadlines overholdt? Var arbejdet af god kvalitet?
  • Kommunikation & interessentinddragelse: Blev information delt med de rigtige personer på det rigtige tidspunkt og ved hjælp af de rigtige værktøjer? Var der for meget eller for lidt information?
  • Projektleverance: Levede projektleverancen op til interessenternes forventninger? Hvorfor eller hvorfor ikke?
  • Projektprocesser og -værktøjer: Hjalp eller hæmmede nogle processer projektets resultater? Manglede der processer, eller var der for mange? Var de agile værktøjer, der blev brugt i projektet, nyttige eller skadelige?

Trin 3: Afsæt et særskilt tidspunkt til projektets retrospektiv

Reservér og planlæg en retrospektiv på et dedikeret tidspunkt til projektevalueringen. Hvis det er muligt, kan du prøve at planlægge mødet og sende kalenderinvitationer (eller aftaler om at reservere datoen) ud nogle uger i forvejen.

Når du planlægger din retrospektiv, skal du ligeledes sende din dagsorden sammen med invitationen (det vender vi snart tilbage til).

Inkludér også eventuelle forventninger til deltagerne (for eksempel hvis deltagerne skal udføre forberedende opgaver før mødet, såsom at downloade et bestemt softwareværktøj) i din invitation.

Dagsorden for projektets retrospektive møde

En retrospektiv behøver ikke at være en meget kompliceret aktivitet. Formålet med en retrospektiv for et projekt er at indsamle feedback om projektet for løbende at forbedre dine næste projekter. 

Her er derfor et eksempel på en dagsorden, som kan bruges og tilpasses ud fra sessionens længde:

  1. Velkomst og introduktion: Byd deltagerne velkommen til sessionen, introducer facilitatoren, og angiv sessionens formål & målsætninger
  2. Overblik over, hvordan feedback indsamles: Giv et kort overblik over, hvordan feedback vil blive indsamlet under sessionen (mundtligt, skriftligt, hybrid, anonymt osv.), og hvilke værktøjer der vil blive brugt (en virtuel tavle, en rundbordssamtale osv.)
  3. Gennemgå eventuelle spilleregler for sessionen: Fortæl deltagerne om eventuelle grundregler (for eksempel: Feedback bør være konstruktiv og ærlig, giv både positiv og negativ feedback osv.)
  4. Indsaml feedback: Registrer den feedback, du ønsker at indsamle, ved hjælp af det ønskede værktøj.
  5. Gennemgå feedback med deltagerne: Gennemgå al indsamlet feedback (det gode, det dårlige & det grimme). I denne del af sessionen bør feedbacken kun præsenteres. Spørgsmål og diskussion om specifikke feedbackpunkter bør begrænses (det sikrer, at du får mulighed for at gennemgå al feedback, og at tiden ikke bruges på 1 eller 2 punkter)
  6. Drøft feedback og spørgsmål: Indhent deltagernes tanker, meninger og svar. Er de enige i feedbacken? Er der yderligere indsigt eller kontekst, der skal deles? Drøft og registrer resultaterne.
  7. Formuler handlinger og næste skridt til forbedringer: Brainstorm på baggrund af feedbacken over pointer og handlinger, som projektteamet kan gennemføre for at skabe forbedringer. Ved tilbagevendende eller komplekse problemer kan I overveje at udføre en hurtig årsagsanalyse for at undersøge, hvorfor problemet opstår. Bed frivillige om at tage ejerskab for eventuelle opfølgningshandlinger eller forbedringstiltag.
  8. Opsummer feedback og forbedringer: Inden sessionen afsluttes, skal du lave en kort opsummering og fremhæve den feedback, der er registreret i mødereferatet, samt eventuelle næste skridt eller handlinger, der vil blive gennemført.
  9. Tak og afslut sessionen: Tak deltagerne for deres tid og feedback. Del oplysninger om eventuelle opfølgningssessioner, der måtte blive planlagt. Del ligeledes oplysninger om, hvor den feedback, der blev indsamlet under sessionen, vil blive gemt, og om den senere vil være tilgængelig for deltagerne (for eksempel på et delt Google Drev).

Ofte stillede spørgsmål om projektrevisioner

Her er nogle ofte stillede spørgsmål om projektrevisioner. Hvis du leder efter mere dybdegående information om agile begreber generelt, kan du overveje at prøve en agil certificering.

Hvad er forskellen mellem en sprint- og en projektrevision?

En sprintrevision er en begivenhed i et agilt workflow, som gennemføres ved afslutningen af en sprint eller iteration. Formålet med en sprintrevision er at undersøge, hvilke forbedringer der kan foretages af processerne for de efterfølgende og fremtidige sprints.

Da sprints er tidsafgrænsede begivenheder (der varer alt fra 2 uger til en måned), vil en sprintrevision generere feedback og forbedringer fra en kort periode i projektets tidslinje, mens en projektrevision ser på hele projektet: hvad gik godt, hvad gik ikke godt, og hvilke forbedringer kan foretages til fremtidige projekter.

Bør du inkludere kunden?

Det afhænger af, hvilken type feedback du ønsker at indsamle under projektrevisionen. Hvis du søger feedback på projektets kommunikation, interessentinddragelse og leverancer, så ja. Hvis det handler om projektteamets præstation—måske, men sandsynligvis ikke. Det er op til projektlederen og teamet at vurdere.

Hvem bør lede en projektrevision?

Projektlederen eller Scrum-masteren faciliterer normalt en revisionssession, men ethvert medlem af projektteamet, der er villig til at facilitere sessionen, kan gøre det. Hvis revisionssessionen kan bringe negativ eller kontroversiel feedback frem, bør du overveje at bruge en facilitator fra en neutral tredjepart.

I en organisation, jeg tidligere arbejdede i, blev projektledere bedt om at facilitere revisionssessioner for andre projektteams i organisationen for at sikre en neutral facilitator, men også for at give teamets projektleder mulighed for at deltage fuldt ud i sessionen som interessent.

Hvilke værktøjer kan jeg bruge til en projektrevision?

Der findes nogle gode værktøjer inden for agil projektstyringssoftware, som organisationer kan bruge til at gennemføre revisioner. Her er nogle anbefalinger.

Onlinesamarbejde og whiteboardtavler
  • Miro eller Mural: Begge disse værktøjer giver brugerne mulighed for at oprette virtuelle whiteboardtavler og lærreder, hvor teams kan indsende deres feedback. Ideelt til fjernteams.
  • IdeaBoardz: Gratis og brugervenligt værktøj, der giver brugerne mulighed for at oprette tilpassede onlinetavler til revisioner og anonym indsamling af feedback via virtuelle post-it-sedler.

Se flere samarbejdsværktøjer (til agile projekter eller andre projekter).

Revisionssoftware
  • Atlassian Confluence: Online-samarbejdsområde med indbyggede skabeloner til revisioner. Et godt værktøj, hvis en organisation bruger andre Atlassian-produkter såsom Jira
  • GoRetro: Tilpasseligt agilt revisionsværktøj, der tilbyder mange gratis skabeloner
Til fysiske revisioner eller revisioner på stedet
  • Et whiteboard og whiteboardmarkere, der kan viskes ud
  • Post-it-sedler
  • Flipoverpapir
  • Mobiltelefon med kamera til at tage billeder af whiteboards eller flipoverark, så de kan gemmes til senere og deles

Hvad er forskellen mellem en revision, en session med lærte erfaringer og en efteranalyse?

En aktivitet med lærte erfaringer minder om en projektrevision. Hvis du bruger vandfaldsmetoden til projektlevering, gennemfører du aktiviteten med lærte erfaringer under afslutningsfasen af et projekt. Formålet er at dokumentere nyttige erfaringer og læringspunkter til forbedringer, som kan anvendes af fremtidige projektteams.

Revisioner stammer fra leveringsmetoden Scrum (agil) og gennemføres for det meste ved afslutningen af et inkrement eller en ‘sprint’. De har til formål at få et team til at reflektere over, hvad der gik godt, hvad der ikke gik godt, og hvad der kunne forbedres på baggrund af det afsluttede inkrement.

Revisioner sigter mod at afdække forbedringer, der kan iværksættes med det samme, mens aktiviteter med lærte erfaringer giver input til fremtidige forbedringer. Hvis et projekt derimod er afsluttet før tid (uanset om det blev annulleret før den planlagte afslutning eller ikke blev gennemført på succesfuld vis), kan der gennemføres en efteranalyse for at fastslå, hvad der skete under projektet.

Skal en projektrevision gennemføres ved projektets afslutning?

Nej—en projektrevision kan (og bør) gennemføres på ethvert tidspunkt under et projekt. Hvis en væsentlig milepæl eller fase er blevet afsluttet, kan det give god mening at planlægge en revision. Hvis noget er gået galt under et projekt, kan der ligeledes gennemføres en revision. Det vigtigste er, at feedbacken indsamles, og at der tages skridt og iværksættes handlinger for at foretage de nødvendige forbedringer.

Hvad nu?

Find ud af mere om de agile principper, der guider retrospektiver, og det oprindelige Agile Manifest, som fastlagde disse principper, og bliv medlem af DPM for at få adgang til samtaler i Slack om agilitet (og meget mere) med hundredvis af andre digitale projektledere!