Skip to main content

På slutten av et prosjekt skal du fullføre oppgaver som å arkivere dokumentasjon, fakturere kunden, gjennomføre medarbeidersamtaler for teamet ditt og, selvfølgelig, det viktigste av alt – prosjektretrospektivet.

Retrospektiver skal brukes til å reflektere over hvordan prosjektet gikk, og hva som kan forbedres i fremtidige prosjekter (og de er ikke en unnskyldning for å arrangere en fest med 80-tallstema, selv om det kanskje høres slik ut).

Hva er et prosjektretrospektiv?

Prosjektretrospektivet er en formell aktivitet der prosjektets interessenter blir bedt om å se tilbake på det fullførte prosjektet og reflektere over hva som gikk bra, hva som ikke gikk så bra, og hva som kunne vært forbedret. Du skal lage en handlingsplan for å forbedre fremtidige prosjekter og prosesser.

Continue Reading for Free

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

Som en av de viktigste agile hendelsene, eller seremoniene, bruker prosjektledere retrospektiver til å vurdere hvordan teamet samarbeider og forbedre prosessen. Prosjektlederen må skape et trygt rom slik at åpen og ærlig (og kanskje ubehagelig) tilbakemelding kan deles under økten.

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 prosjektretrospektiver viktige?

Et vellykket retrospektiv vil forbedre prosjektprosessene dine og øke sannsynligheten for at fremtidige prosjekter lykkes. Her er noen andre grunner til at prosjektretrospektiver er viktige:

  • Kontinuerlig forbedring: Teamet kan reflektere over hva som gikk bra, og hva som ikke gjorde det. Lær av eventuelle feil, og identifiser suksesser du ønsker å gjenta. Når dere gjør endringer i prosessene og arbeidsflytene basert på dette, vil teamet forbedre seg og samarbeide bedre over tid.
  • Bedre teambygging og samarbeid: Retrospektivet gir teamet en mulighet til å knytte sterkere bånd. Det er et trygt rom der de gir hverandre konstruktive tilbakemeldinger og finner ut hvordan de kan samarbeide bedre fremover. Bruk også retrospektiver til å feire seire, siden dette forbedrer teamets moral og motivasjon.
  • Forbedret problemløsning: Teamet kan løse problemer knyttet til utfordringer og hindringer de møtte under prosjektet, og finne ut hvordan de kan håndtere lignende utfordringer i fremtidige prosjekter. De kan også dele beste praksis med hverandre, noe som forbedrer den samlede kunnskapen.
  • Bedre ansvarlighet: Ved å samle teamet for å diskutere hva som gikk galt, styrker retrospektiver ansvarligheten og oppmuntrer teammedlemmene til å ta eierskap til arbeidet sitt. Ikke plasser skyld for feil, men fokuser på hva som må endres for å unngå de samme feilene i fremtiden.
  • Forbedret prosjektplanlegging: Ved å dokumentere risikoer, prosjektforutsetninger, hindringer og andre ting som gikk galt under prosjektet, kan du sørge for at du tar hensyn til disse i prosjektplanene for fremtidige prosjekter.

Slik gjennomfører du prosjektretrospektiver

La oss se på noen praktiske trinn og råd for hvordan du kan legge til rette for en effektiv retrospektivøkt for prosjektet ditt.

Trinn 1: Bygg en tillitskultur

Det kan være vanskelig å få folk til å være åpne og gi tilbakemeldinger. Det er enda vanskeligere når det mangler tillit blant prosjektteamet og interessentene. 

  • Ble tilbakemeldinger tidligere kritisert? 
  • Følte teammedlemmene seg skremt av å dele ideer og tilbakemeldinger? 
  • Ble det gjort negative handlinger etter at tilbakemeldinger ble delt, som kan oppfattes som straffende (for eksempel at enkelte goder ble fjernet)? 
  • Ble det spilt et skyldspill da problemer ble avdekket? 

Hvis du svarte ja på noen av disse spørsmålene, er dette klare grunner til at det kan finnes mistillit og en manglende vilje til å være åpen.

Så hvordan får du folk til å være åpne og dele tilbakemeldinger? Hvordan bygger du en tillitskultur og får folk til å føle at de befinner seg i et trygt rom?

illustrasjon av to valnøtter som symboliserer at teammedlemmer kommer ut av skallet sitt under prosjektretrospektiver
Å få folk til å åpne seg er en av de vanskeligste delene av et prosjektretrospektiv.

Du kan prøve følgende:

  • Oppmuntre til åpen og ærlig kommunikasjon: Sørg for at teamet ditt føler seg verdsatt og satt pris på. De vil være mer villige til å åpne seg og dele hvis de vet at de ikke vil bli ignorert eller marginalisert.
  • Skap muligheter for samarbeid: Dette kan være daglige statussjekker for prosjektet eller oppgaver som ikke er knyttet til prosjektet, for eksempel en teambyggingsaktivitet. Hvis folk får mulighet til å samarbeide, vil de føle seg mer komfortable med å kommunisere.
  • Gjør tilbakemeldinger til en del av teamkulturen: I programvareutviklingsprosjekter er det vanlig at teammedlemmer får koden sin fagfellevurdert av andre i teamet som en del av den vanlige utviklingsprosessen. Se etter muligheter til å gjøre noe lignende i prosjektet ditt, slik at teamet regelmessig kan både gi og motta positive og negative tilbakemeldinger.

Trinn 2: Bestem hvilken type tilbakemeldinger du ønsker å samle inn

Det skjer mye i løpet av et prosjekt, og derfor finnes det mange muligheter til å samle inn et bredt spekter av tilbakemeldinger under en retrospektiv gjennomgang. Dette er helt greit, men det kan også bli overveldende.

Når du planlegger en retrospektiv gjennomgang, bør du definere omfanget av tilbakemeldingene du ønsker å få fra deltakerne. 

Prøv å definere noen temaer du ønsker å samle inn tilbakemeldinger om, for eksempel:

  • Teamets prestasjoner: Hvordan presterte teamet under prosjektet? Ble tidsfristene overholdt? Var arbeidet av god kvalitet?
  • Kommunikasjon og interessentengasjement: Ble informasjonen delt med de riktige personene til riktig tid og ved hjelp av de riktige verktøyene? Var det for mye eller for lite informasjon?
  • Prosjektleveransen: Oppfylte prosjektleveransen interessentenes forventninger? Hvorfor eller hvorfor ikke?
  • Prosessene og verktøyene i prosjektet: Var det noen prosesser som hjalp eller hindret prosjektets resultater? Manglet det prosesser, eller var det for mange? Var de smidige verktøyene som ble brukt i prosjektet, nyttige eller skadelige?

Trinn 3: Sett av et bestemt tidspunkt til prosjektets retrospektive gjennomgang

Sett av tid og planlegg en retrospektiv gjennomgang på et bestemt tidspunkt for prosjektevalueringen. Hvis det er mulig, bør du prøve å planlegge møtet og sende ut kalenderinvitasjoner (eller avtaler for å «holde av datoen») noen uker i forveien.

Når du planlegger den retrospektive gjennomgangen, bør du også sende ut agendaen sammen med invitasjonen (det kommer vi snart tilbake til).

Ta også med eventuelle forventninger til deltakerne i invitasjonen, for eksempel om deltakerne må utføre oppgaver før møtet, som å laste ned et bestemt programvareverktøy.

Agenda for prosjektets retrospektive møte

En retrospektiv gjennomgang trenger ikke å være en svært komplisert aktivitet. Formålet med en prosjektretrospektiv gjennomgang er å få tilbakemeldinger om prosjektet for å oppnå kontinuerlige forbedringer i de neste prosjektene dine. 

Her er derfor et eksempel på en agenda som kan brukes og tilpasses basert på hvor lang økten er:

  1. Velkomst og introduksjon: Ønsk deltakerne velkommen til økten, presenter møtelederen og angi formålet med og målene for økten
  2. Oversikt over hvordan tilbakemeldinger skal samles inn: Gi en kort oppsummering av hvordan tilbakemeldinger skal samles inn under økten (muntlig, skriftlig, hybrid, anonymt osv.), og hvilke verktøy som skal brukes (en virtuell tavle, en rundebordsdiskusjon osv.)
  3. Gå gjennom eventuelle samhandlingsregler for økten: Fortell deltakerne om eventuelle grunnregler (for eksempel: Tilbakemeldinger bør være konstruktive og ærlige, og både positive og negative tilbakemeldinger bør gis osv.)
  4. Samle inn tilbakemeldinger: Registrer tilbakemeldingene du ønsker å samle inn, ved hjelp av det verktøyet du foretrekker.
  5. Gå gjennom tilbakemeldingene med deltakerne: Gå gjennom alle innsamlede tilbakemeldinger (det gode, det dårlige og det stygge). I denne delen av økten bør tilbakemeldingene bare presenteres. Spørsmål og diskusjon rundt spesifikke tilbakemeldinger bør begrenses (dette er for å sikre at du får gått gjennom alle tilbakemeldingene, og at tiden ikke brukes på ett eller to punkter)
  6. Diskuter tilbakemeldinger og spørsmål: Be deltakerne dele tanker, meninger og svar. Er de enige i tilbakemeldingene? Er det ytterligere innsikt eller kontekst som bør deles? Diskuter og dokumenter resultatene.
  7. Formuler tiltak og neste steg for forbedringer: Ta utgangspunkt i tilbakemeldingene og idemyldre rundt læringspunkter og tiltak som prosjektteamet kan gjennomføre for å gjøre forbedringer. For gjentakende eller komplekse problemer bør du vurdere å gjennomføre en rask rotårsaksanalyse for å undersøke hvorfor problemet oppstår. Be om frivillige som kan ta ansvar for oppfølgings- eller forbedringstiltak.
  8. Oppsummer tilbakemeldinger og forbedringer: Før du avslutter økten, kan du gi en kort oppsummering og fremheve tilbakemeldingene som er dokumentert i møtereferatet, samt eventuelle neste steg eller tiltak som skal gjennomføres.
  9. Takk og avslutning av økten: Takk deltakerne for tiden og tilbakemeldingene deres. Del informasjon om eventuelle oppfølgingsøkter som kan bli planlagt. Del også informasjon om hvor tilbakemeldingene som ble samlet inn under økten, vil bli lagret, og om de vil være tilgjengelige for deltakerne senere (for eksempel på en delt Google Drive).

Vanlige spørsmål om prosjektevalueringer

Her er noen vanlige spørsmål om prosjektevalueringer. Hvis du ser etter mer inngående informasjon om smidige konsepter generelt, kan du vurdere å prøve en smidig sertifisering.

Hva er forskjellen mellom en sprint- og en prosjektevaluering?

En sprintevaluering er en aktivitet i en smidig arbeidsflyt som gjennomføres på slutten av en sprint eller iterasjon. Formålet med en sprintevaluering er å undersøke hvilke forbedringer som kan gjøres i prosessene for påfølgende og fremtidige sprinter.

Ettersom sprinter er tidsavgrensede aktiviteter (som varer fra 2 uker til en måned), vil en sprintevaluering generere tilbakemeldinger og forbedringer fra en kort periode i prosjektets tidslinje, mens en prosjektevaluering ser på hele prosjektet: hva som gikk bra, hva som ikke gikk bra, og hvilke forbedringer som kan gjøres for fremtidige prosjekter.

Bør du inkludere kunden?

Det avhenger av hvilken type tilbakemeldinger du ønsker å hente inn under prosjektevalueringen. Hvis du ønsker tilbakemeldinger på prosjektets kommunikasjon, interessentinvolvering og leveranser, er svaret ja. Hvis det gjelder prosjektteamets prestasjoner – kanskje, men sannsynligvis ikke. Dette er opp til prosjektlederens og teamets vurdering.

Hvem bør lede en prosjektevaluering?

Prosjektlederen eller Scrum-masteren tilrettelegger vanligvis for en evalueringsøkt, men ethvert medlem av prosjektteamet som er villig til å lede økten, kan gjøre det. Hvis evalueringsøkten kan ta opp negative eller kontroversielle tilbakemeldinger, bør du vurdere å bruke en nøytral tilrettelegger fra en tredjepart.

I en organisasjon jeg tidligere jobbet i, ble prosjektledere bedt om å tilrettelegge for evalueringsøkter for andre prosjektteam i organisasjonen for å sikre en nøytral tilrettelegger, men også for å la prosjektlederen for teamet delta fullt ut i økten som interessent.

Hvilke verktøy kan jeg bruke til en prosjektevaluering?

Det finnes noen gode verktøy for smidig prosjektstyringsprogramvare som organisasjoner kan bruke til å gjennomføre evalueringer. Her er noen anbefalinger.

Nettbasert samarbeid / digitale tavler
  • Miro eller Mural: Begge disse verktøyene lar brukerne opprette virtuelle tavler og arbeidsflater der team kan legge inn tilbakemeldingene sine. Ideelt for fjernteam.
  • IdeaBoardz: Gratis og brukervennlig verktøy som lar brukere opprette tilpassbare nettbaserte tavler for evalueringer og anonym innsamling av tilbakemeldinger via virtuelle lapper.

Se flere samarbeidsverktøy (for smidige prosjekter eller andre prosjekter).

Programvare for prosjektevaluering
  • Atlassian Confluence: Nettbasert samarbeidsområde med innebygde maler for evalueringer. Et godt verktøy hvis en organisasjon bruker andre Atlassian-produkter, for eksempel Jira
  • GoRetro: Tilpassbart, smidig evalueringsverktøy som tilbyr mange gratis maler
For evalueringer ansikt til ansikt eller på stedet
  • En whiteboard og slettebare whiteboardtusjer
  • Post-it-lapper
  • Papir til flippover
  • Kameratelefon for å ta bilder av whiteboardene eller flippoverarkene, slik at de kan lagres til senere og deles

Hva er forskjellen mellom en evaluering, en økt for erfaringslæring og en etteranalyse?

En aktivitet for erfaringslæring ligner på en prosjektevaluering. Hvis du bruker fossefallsmetodikken for prosjektgjennomføring, gjennomfører du aktiviteten for erfaringslæring i avslutningsfasen av et prosjekt. Hensikten er å dokumentere nyttige erfaringer og lærdommer for forbedringer som kan brukes av fremtidige prosjektteam.

Evalueringer stammer fra leveringsmetodikken Scrum (smidig) og gjennomføres vanligvis når en inkrementell leveranse eller «sprint» er fullført. De har som formål å få et team til å reflektere over hva som gikk bra, hva som ikke gikk bra, og hva som kunne vært forbedret basert på den fullførte inkrementelle leveransen.

Evalueringer har som mål å avdekke forbedringer som kan gjennomføres umiddelbart, mens aktiviteter for erfaringslæring gir innspill til fremtidige forbedringer. Alternativt kan det gjennomføres en etteranalyse hvis et prosjekt er avsluttet før tiden (enten fordi det ble kansellert før planlagt slutt, eller fordi det ikke ble fullført på en vellykket måte), for å finne ut hva som skjedde under prosjektet.

Må en prosjektevaluering gjennomføres på slutten av prosjektet?

Nei – en prosjektevaluering kan (og bør) gjennomføres når som helst under et prosjekt. Hvis en viktig milepæl eller fase er fullført, kan det være fornuftig å planlegge en evaluering. På samme måte kan det gjennomføres en evaluering hvis noe har gått galt under et prosjekt. Det viktige er at tilbakemeldingene samles inn, og at det iverksettes trinn og tiltak for å gjøre nødvendige forbedringer.

Hva skjer videre?

Finn ut mer om de smidige prinsippene som veileder retrospektiver, og det opprinnelige Agile-manifestet som fastsatte disse prinsippene, og bli DPM-medlem for å få tilgang til samtaler i Slack om smidig arbeidsmetodikk (og mer) med hundrevis av andre digitale prosjektledere!