Slik gjennomfører du en effektiv retrospektiv og bruker lærdommene i fremtidige prosjekter

Les transkripsjonen:

 

Vi prøver ut å transkribere podkastene våre ved hjelp av et program. Tilgi eventuelle skrivefeil, siden roboten ikke er korrekt 100 % av tiden.

Galen Low: Hei alle sammen, og takk for at dere lytter. Jeg heter Galen Low og er fra The Digital Project Manager. Vi er et fellesskap av digitale fagfolk med et mål om å hjelpe hverandre med å bli dyktigere, tryggere og bedre tilknyttet, slik at vi kan øke verdien av prosjektledelse i en digital verden. Hvis du vil høre mer om dette, kan du gå til thedigitalprojectmanager.com.

I dag snakker vi om prosjektretrospektiver: hvordan man gjennomfører dem effektivt, og hvordan man sørger for at lærdommene man fanger opp i retrospektivene, faktisk fører til forbedringer i fremtidige prosjekter.

Med meg i dag har jeg Payson Hall, grunnlegger og hovedkonsulent i Catalysis Group, som har hjulpet organisasjoner med å lære av prosjektfeilene sine i godt over 30 år.

Payson, det er flott å ha deg med i programmet.

Payson Hall: Hei, hyggelig å være med og hyggelig å møte publikum.

Galen Low: Ja, og jeg er faktisk glad for at du nevnte det, for vi gjør noe litt annerledes i dag. Vi er direkte sammen med medlemmene våre som studiopublikum, og vi kommer til å ta imot spørsmål underveis via Slack-fellesskapet vårt. Michael er også i studioet sammen med meg, så han kommer til å supplere med noen av spørsmålene. Vi fletter dem inn i samtalen, og alt kan skje. Så la oss skru opp energien.

Greit, da setter vi i gang. Jeg tenkte å begynne med et saftig spørsmål, for vi har snakket om dette, og du har jobbet med prosjektretrospektiver som konsulent i flere tiår, for alle slags prosjekter, blant annet programvareprosjekter og store systemintegrasjonsprosjekter. Jeg ville spørre deg om dette: Når du kommer inn som ekstern konsulent for å avdekke alle prosjektets skitne små hemmeligheter, ser prosjektteamene på deg som en venn eller en fiende? Er det som å få veiledning? Føles det som å bli revidert?

Payson Hall: Vanligvis er det en vennlig utveksling. Jeg vil gjerne skille mellom to ting, for én del av konsulentpraksisen min handler om prosjektobduksjoner. Hvis et prosjekt har sporet alvorlig av, og det er bekymring for at folk visste at det var i ferd med å spore av uten å si fra, ligner det mye mer på en revisjon.

Jeg samarbeider faktisk med en delstatsrevisor i California, og jeg har revidert IT-prosjekter til en verdi av milliarder av dollar. Der prøver de vanligvis å bygge en sak som advokatene kan bruke mot en systemintegrator. En mer vanlig og vennlig retrospektiv er bare at folk sier: Hei, vi er ferdige med dette prosjektet.

La oss få noen til å fasilitere en gjennomgang, ikke sant? Det er det et retrospektiv er. En gjennomgang for å spørre: Hva lærte vi? Hva gjorde vi som var smart, kanskje uten at vi la merke til det der og da? Hva gjorde vi som vi i ettertid skulle ønske at vi hadde gjort annerledes? Det er egentlig en risikostyringsøkt der man ser i bakspeilet. Hva kan jeg gjøre bedre neste gang? Hva gjorde jeg som var smart, og som jeg vil sørge for å gjøre mer av?

Galen Low: Jeg liker virkelig det skillet også, for jeg tror noen av dem som lytter, kanskje ikke opplever forskjellen like tydelig. For dem føles hvert retrospektiv som en obduksjon, som om de skal legge frem bevis i retten, og som et slags skyldspill, i stedet for bare å se i bakspeilet og lære av feilene sine, slik du sa.

Payson Hall: En av de eneste store reglene for retrospektiver, selv om det finnes mange ulike måter å gjennomføre dem på, er at du som prosjektleder aldri bør gjennomføre ditt eget retrospektiv. Noe av det som ikke gikk bra, skyldtes nemlig ting du selv gjorde. En god fasilitator kan sørge for at det handler om hva som skjedde, når det skjedde, og hva vi lærte av det. Ikke: Vel, Galen, du rotet det virkelig til, ikke sant?

Det er ikke konstruktivt. Folk blir defensive, og prosessen sporer av. Enten du henter inn noen utenfra, eller du har en person internt som du setter pris på og stoler på, og som er en god fasilitator, bør du ha en ekstern part – noen som ikke var involvert i prosjektet og ikke har noe å tape – til å fasilitere samtalen. Da unngår vi at det ligger mye blod på gulvet når vi er ferdige.

Galen Low: Det er rimelig. Og det er faktisk en veldig interessant innfallsvinkel, for jeg vet at mange åpner denne episoden for å finne ut hvordan de skal gjennomføre sitt eget retrospektiv.

Og for all del, jeg vet at det er en realitet for mange prosjektteam, og vi skal gå gjennom noen av tipsene og tingene du har lært underveis. Men jeg liker rådet ditt om at det kan være, og kanskje til og med bør være, noen andre som gir dette perspektivet – noen som kan gjøre det til noe som ikke utvikler seg til et skyldspill. Og da blir det heller ikke så mye blod på gulvet etterpå, som du sier.

Payson Hall: Vel, det bør være noen som kommer inn med et annet sett av antakelser. Tenk på prosjekter du har jobbet med. Mens du gjennomførte prosjektet, gjorde du deg antakelser om hva som var årsakene til problemene. De kan være riktige, eller de kan være feil. Noen som kommer inn uten disse antakelsene, kan være åpne for annen informasjon eller andre måter å tolke situasjonen på.

Galen Low: Det liker jeg. Ja. Jeg liker virkelig det perspektivet fra noen som ikke var med på et langvarig prosjekt i kanskje 12–18 måneder, og som derfor ikke føler seg så tett knyttet til det at de ikke lenger ser skogen for bare trær.

Jeg tenkte kanskje vi kunne begynne med det overordnede. La oss zoome litt ut og gi lytterne et utgangspunkt. Kan du forklare, fra ditt perspektiv, hva et prosjektretrospektiv er, og hvorfor det er verdt å gjennomføre?

Payson Hall: Godt spørsmål. Et retrospektiv betyr å se tilbake. Ideen er at vi kommer til et viktig tidspunkt i prosjektet, eller til slutten av et prosjekt. Vi ser tilbake og sier: Greit, la oss trekke pusten. Hva lærte vi i denne siste delen? Hvilke lærdommer ønsker vi å ta med til neste del? Eller hvilke lærdommer vil vi ikke ta med til neste prosjekt?

Hva gjorde vi som var smart, kanskje ved en tilfeldighet? Eller hva gjorde vi som får oss til å tenke: Hvis jeg skulle gjort dette på nytt? Hvis jeg kunne sende en melding til en tidsmaskin og tilbake til meg selv, er dette noe jeg ville ha ønsket å gjøre annerledes. Ideen er egentlig bare å trekke pusten og se tilbake på prosjektets hendelser i sin sammenheng.

Som du sa: Zoome ut og se helheten, slik at vi forstår hva som er viktig og hva som ikke er viktig. Noen ting er bare svarte svaner. Dette var en uventet hendelse, som covid-19. Jeg kommer ikke til å planlegge for pandemier i de fleste prosjektene som skal gjennomføres, men hvis det skjedde med prosjektet ditt, var det et kraftig slag.

Så jeg vet ikke – det kan hende det finnes noen lærdommer der, men noen ting er bare ikke relevante. Kanskje du trengte et dusin bærbare datamaskiner, så du bestilte 14 i tilfelle et par av dem var defekte ved levering. Det viste seg at én av dem faktisk var defekt ved levering, og det var veldig smart, fordi du hadde en stram tidsplan.

Da tenker du: Å ja, kontrasterer man kostnaden for de to andre bærbare datamaskinene med forsinkelsen man unngikk, kan det være en veldig god lærdom. Og det er ikke slik at den ekstra datamaskinen er avfall. Vi kan kanskje returnere den. Vi kan skrive inn i kontrakten at vi har rett til å returnere den hvis vi ikke åpner den.

Det kan hende at dette var tusen dollar som var svært godt brukt. Det sparte oss for tre ukers forsinkelse. Hvis du har jobbet med maskinvare de siste tre årene, mens forsyningskjedene har vært helt kaotiske, vet du nøyaktig hva jeg snakker om.

Galen Low: Absolutt. Jeg liker det eksempelet veldig godt. Og jeg liker noe annet viktig som jeg tror mange vanligvis ikke tenker på: Retrospektiver kan være en anledning til å reflektere over noe som gikk veldig bra, over den smarte løsningen som fungerte utmerket.

Og i ettertid tenker man noen ganger: Greit, hva gikk bra? Teamet samarbeidet veldig godt, vi kommuniserte godt, og så videre. Men når det gjelder en tydelig lærdom, kan man tenke: Husker du da den personen bestilte det alternative møterommet? Og vårt førstevalg av lokale ble avlyst, eller noe skjedde med det, og vi hadde en reserve? Det var fantastisk. Det er noe vi bør lære av og bygge inn i prosessen vår neste gang.

Og som du sier, sørger vi for at kontrakten inneholder en bestemmelse om at vi kan returnere en ekstra bærbar datamaskin hvis den er uåpnet. Da har vi sikret oss, og vi kan bruke dette i fremtidige prosjekter som en smart lærdom.

En annen ting jeg likte svært godt, var at du sa at retrospektiver enten skjer ved slutten av et prosjekt eller på et viktig tidspunkt underveis. Mange jeg snakker med, tenker at retrospektiv betyr at prosjektet er slutt, og at det derfor er for sent. Vi kan se i bakspeilet, men det ligger en slags trist tone over det: Dette kunne vært bedre, men nå er det for sent. Vi må vente til neste gang. I stedet finnes det andre steder i prosjektet der man kan gjennomføre et retrospektiv. Det vil jeg gjerne komme tilbake til senere.

Payson Hall: Ja, det er faktisk noe av det interessante vi har fått fra smidige arbeidsmetoder, fordi de vanligvis gjennomfører et lite retrospektiv på slutten av hver sprint. Jeg har jobbet med prosjekter der vi gjorde det ved milepæler i større prosjekter, men jeg tror Agile sa: Vent litt, hvorfor gjør vi ikke dette mer regelmessig?

Fordi vi gjør det oftere, blir retrospektivene mindre. Teamet ender opp med å forstå prosessen og kan komme inn i den og gjennomføre den. Jeg synes det var en veldig fin nyvinning at de smidige metodene virkelig tydeliggjorde retrospektiver på slutten av hver sprint.

Galen Low: Jeg liker den endringen i tankesett: at vi faktisk kan gjøre dette mer regelmessig, og at det dermed blir mindre omfattende. For å spille djevelens advokat tror jeg mange, særlig mange organisasjoner, vil si: Ja, vi vil lære av feilene våre. Vi vil feile raskt.

Vi vil gjøre alle disse tingene. Men når det kommer til stykket, er ikke alle organisasjoner villige til å investere i å se bakover. De sier: Hva? Vi lærte det underveis. Vi trenger ikke ha et møte om det. La oss bare gå videre til neste ting. Men når det gjelder den samlede investeringen, og det du sa om å hente inn noen utenfra som fasilitator, hva innebærer det å gjennomføre et ordentlig prosjektretrospektiv? Og er det verdt det? Hvis jeg som organisasjon skulle spille djevelens advokat og si: Jeg vet ikke. Folk kjente på problemene underveis. Vi bør bare gå videre. La oss ikke hente inn Payson. La oss ikke gjennomføre et retrospektiv. Hva ville du svart på det?

Payson Hall: Det er et godt spørsmål. Når vi snakker om prosessforbedring, må vi sørge for at kostnaden ved lærdommene og forbedringen ikke overstiger verdien av forbedringen. Så hva kreves for å gjennomføre et retrospektiv? La meg gi deg et eksempel og ta deg gjennom det. Det første jeg vil si, er at konteksten betyr noe.

Hvis vi snakker om et prosjekt til flere millioner eller milliarder av dollar, vil det kreve mye mer innsats enn et lite prosjekt. Det vil finnes langt mer data. Hvis det er et problemfylt prosjekt, vil det kreve mer innsats enn et prosjekt som gikk relativt greit. Hvis et prosjekt kollapser og brenner, og advokater er involvert, gjennomfører du ikke et retrospektiv. Da gjennomfører du en obduksjon, og det kan være svært kostbart.

Her er et konkret eksempel. Jeg gjennomførte nylig et retrospektiv med et team på omtrent 12 personer for et prosjekt som varte i rundt 18 måneder. Det var et internt prosjekt med et dusin personer på prosjektteamet. Prosjektet varte i omtrent 18 måneder, oppfylte kravene, var litt forsinket, og det var akseptabelt. Ingen advokater var involvert.

Spørsmålet var: Greit, vi er ferdige. La oss trekke pusten. Hva lærte vi av dette? Hva kan vi gjøre annerledes? De enkelte teammedlemmene brukte sannsynligvis fire til seks timer hver på forberedelser, selve møtet og gjennomgangen. Som fasilitator brukte jeg sannsynligvis et dusin timer på forberedelser, fasilitering og oppsummering i etterkant.

Prosjektlederen brukte sannsynligvis 8–12 timer på å gi meg informasjon og gå gjennom ting. Det retrospektivet krevde altså omtrent to personuker med innsats. To personuker. Hvis vi ser for oss et dusin personer pluss prosjektlederen som jobbet i 18 måneder, er det omtrent tusen personuker.

Det vi sier, er at 0,2 % av dette ble brukt på å se tilbake og prøve å forstå hva vi lærte, hva vi kan gjøre annerledes, og hva vi gjorde som var smart. Tenk på det. Alt du trenger å gjøre, er å finne én måte å spare inn to personukers innsats på, så har du allerede fått positiv avkastning på investeringen.

Det kan skje på et par måter. Det kan være strukturelt: Her er en anbefaling til PMO-en om å gjøre denne tingen annerledes, noe som kommer til å spare tid og frustrasjon. Det kan også være organisk. Vi gikk virkelig inn for å gjennomføre en kodegjennomgang i dette prosjektet, for eksempel, og det hjalp oss mye. Vi eksperimenterte med det, og det hjalp oss virkelig. Nå tar alle i teamet dette med seg til neste prosjekt. Mange av dem spres som frø fra en frøkapsel. De går videre, arbeider kanskje sammen på samme prosjekt eller på ulike prosjekter. De tar med seg lærdommene og kan argumentere for dem i neste prosjekt.

Jeg har aldri sett et retrospektiv der vi ikke kom frem til en liste over funn, anbefalinger og forslag, og jeg mener at dette i det minste er verdt de to personukene vi investerer.

Galen Low: Greit nok. Vi snakker om større prosjekter, men finnes det en nedre grense for mindre prosjekter? Hvis prosjektet ditt bare varte i fire uker, kan det virke som om avkastningen på å investere to personuker ikke er til stede. Dropper du det og sier at vi ikke kan eller vil gjennomføre retrospektiver for disse prosjektene? Slår du dem sammen, slik at fem små prosjekter gjennomfører et retrospektiv sammen?

Payson Hall: Nei, det var faktisk en feil jeg gjorde tidlig i karrieren.

Du vil ikke ha noen i et retrospektiv som ikke var involvert i prosjektet. La oss anta at teamet ikke er i krig med seg selv. Hvis dere skal ha en åpen samtale om hva som fungerte og ikke fungerte, og noen skal kunne si: Ja, jeg gjorde dette feil. Jeg kunne ha gjort det annerledes, er folk mye mer komfortable med å gjøre det i et nært team de har arbeidet sammen med enn foran en gruppe fremmede. Derfor ville jeg aldri vurdert å slå sammen prosjekter.

Etter at vi har gjennomført en rekke små retrospektiver, kan det være interessant å samle prosjektlederne og spørre hva de har til felles, hvis PMO-en ønsker det. Men i et retrospektiv vil jeg ikke ha turister. Jeg vil at det bare skal være teamet.

Når det gjelder spørsmålet ditt om vi kan gjøre dette i liten skala: Absolutt. Den formelle prosessen vi skal snakke om om litt, skal jeg gå gjennom. På et 18-måneders prosjekt føler folk at de møter opp hver dag og går inn i hamsterhjulet i 18 måneder. Det skjer viktige ting, men det er lett å miste sammenhengen.

Det er lett, som du sa, å ikke se skogen for bare trær. Derfor kan det være svært nyttig å ta seg tid til å si: Her er noen viktige utviklingstrekk underveis. Og investeringen på to uker vi snakket om, kan på et tre- eller fireukers prosjekt kanskje erstattes av at man samles i en time. Da kan man sannsynligvis håndtere det meste av det som må gjøres.

Jeg ville nok forberedt meg litt og sørget for at jeg forsto prosjektet og hva prosjektlederen kunne være ute etter. Men ja, man kan sannsynligvis gjennomføre et slikt retrospektiv ganske uformelt på én eller to timer.

Galen Low: Du nevnte det tidligere: I en smidig arbeidsmetode kan man gjennomføre en eller annen form for retrospektiv i hver sprint. Kanskje det også krever en refleksjon på slutten av prosjektet for å samle all lærdommen og lage anbefalinger på bakgrunn av den. Men jeg liker tanken på at disse to personukene ikke nødvendigvis må brukes på slutten av prosjektet.

Selv for et prosjekt med et team på 12 personer, og et prosjekt i ganske stor skala, finnes det mindre måter å gjøre dette på. Så ja, jeg vil gjerne gå inn på det når vi kommer til selve prosessen.

Payson Hall: Ja. Hvis du har et team på åtte personer og samler alle i ett rom i én time, er det åtte persontimer. Legg til et par timer med forberedelser og et par timer med prosjektlederen etterpå, så kan du kanskje gjennomføre hele prosessen på 12 timer. Det inkluderer å lage en punktliste på én side over det vi lærte underveis.

Galen Low: Det finnes også en alternativkostnad her. Jeg spilte djevelens advokat tidligere, men hvis du bruker den timen på å avdekke en lærdom som sparer deg en halv million dollar hver gang, har den jo betalt seg selv ti ganger. Det er altså noe å tenke på: kostnaden ved å ikke gjennomføre et retrospektiv.

Du nevnte interne team tidligere som eksempel. Jeg vet at mange som lytter, arbeider i byråer, og dette kommer ofte opp: De arbeider for en kunde, men kunden vil ikke betale for retrospektivet fordi de mener at det er slik dere blir bedre som organisasjon.

Samtidig vil heller ikke ledelsen investere i det, fordi de sier: Dette er ikke fakturerbar tid. Skal vi holde åtte eller tolv personer borte fra arbeidet i en viss tid for å snakke om hvordan prosjektet gikk, uten å tjene penger? Nei, det gjør vi ikke. Jeg har faktisk vært i en slik situasjon. Jeg har opplevd at en administrerende direktør kom inn og sa: Alle ut av rommet. Dette er bortkastet tid. Gå tilbake til fakturerbart arbeid.

Det var en vekker for meg. Jeg skjønte at ikke alle ser verdien av dette i den forretningsmessige hverdagen i et byrå. Men for dem som leder et prosjekt og ser verdien av et retrospektiv: Hvordan kan de argumentere for denne typen læring, og hvordan kan de overbevise eierne og ledelsen i byrået om verdien av et retrospektiv som ikke er fakturerbart?

Payson Hall: Jeg vil være høflig, men hvis jeg jobbet et sted der den administrerende direktøren kom inn og sa at vi ikke trenger å gjennomføre neste prosjekt bedre enn dette, og at det ikke finnes noe mer å lære, ville jeg begynt å skrive CV-en min. Det ville bekymret meg sterkt.

Før jeg startet Catalysis Group, jobbet jeg i fire år med profesjonelle tjenester i IBM, på prosjekter til flere millioner dollar. Og du har rett: Vanligvis betaler ikke kunden for dette. Organisasjonen betaler for det.

Organisasjonen betaler fordi den vil vite om vi kan gjøre noe bedre når det gjelder kundetilfredshet, effektivitet eller prosessforbedring. Særlig konsulentfirmaer bør stoppe opp og tenke over hva de tar betalt per time.

Hvor mange timer må du spare før det gir verdi? Bare for å nevne det for dem som ikke arbeider med rådgivning: Mike, faktureringssatsene er 2000 dollar per dag. Det er ikke det jeg får utbetalt. Når jeg gjør administrativt arbeid, koster det derfor ikke organisasjonen 2000 dollar per dag. Hvis jeg bruker én time på administrativt arbeid sammen med en gruppe på seks personer, og vi finner en måte å spare fire dager på i neste prosjekt, har vi allerede fått enormt mye igjen for retrospektivet.

Jeg kjenner ikke konteksten. Det kan hende organisasjonen du snakker om blødde penger, og at den administrerende direktøren trengte at dere genererte inntekter. Men generelt, basert på min erfaring, er dette ikke vanskelig å selge inn. En ting man kan gjøre, er å begynne i det små. Du sa: Hva om det er et kort prosjekt? Flott. La oss møtes over lunsj. La oss sette av en time.

Da jeg var helt fersk, jobbet jeg i Price Waterhouse, og jeg syntes det var morsomt at partnerne hver måned inviterte de ansatte til en egen frokost som startet klokken sju om morgenen. Vi møtte opp klokken sju, de kjøpte frokost til oss, og vi tenkte: Vi slipper unna. Vi er så privilegerte. De kjøper frokost til oss på et flott sted.

Partnerne tenkte egentlig: Jeg lurte alle disse lettlurte menneskene til å komme to timer tidligere på jobb til et personalmøte. Og de er fornøyde fordi jeg ga dem mat.

Så ja, jeg tror profesjonelle tjenestebyråer vanligvis prøver å bygge opp virksomheten. Det kan finnes formildende omstendigheter. Hvis noe brenner, forstår jeg at den administrerende direktøren sier: Nei, slukk denne brannen først, og kom tilbake etterpå. Men jeg mener at man bør begynne i det små. Verdien av retrospektiver vil vise seg.

En ting som ligner på risikostyring, er at når du får en viktig lærdom fra et retrospektiv eller en risikostyringsøkt som sparer deg for mye bryderi, bør du fortelle folk om det. Si: Vi gjennomførte dette retrospektivet, kom frem til denne ideen, brukte den i neste prosjekt, og den sparte oss for to uker. Slik overbeviser du ledelsen om at det er god bruk av tiden.

Men begynn i det små, slik at det ikke blir en stor investering.

Galen Low: Begynn i det små og samle bevis, ikke sant? Konkrete bevis som viser at dette skapte verdi sist. I noen tilfeller kan man kanskje be om tilgivelse i stedet for tillatelse, og deretter samle dokumentasjonen. Det er enormt viktig.

For ofte handler det bare om at beslutningstakerne ikke har bevis på at dette vil skape verdi. Det ligger penger på bordet som kan hentes, ikke sant? Det foregår et prosjekt akkurat nå, med fakturerbare timer, og alle de åtte personene i rommet kunne ha arbeidet med dette i stedet. De har ennå ikke sett beviset på at et retrospektiv faktisk kan utvikle og optimalisere en virksomhet på en verdifull måte.

Payson Hall: Et vanlig resultat av et retrospektiv er et dokument eller en presentasjon som sier: Her er høydepunktene. Den kan tilpasses ledelsen. Kanskje det finnes en intern versjon og en versjon man deler med andre. Men hvis den er godt utformet, kan den hjelpe ledelsen med å forstå at de noen ganger selv er årsaken til problemene.

Det kan være at ressurser omdisponeres med svært kort varsel, eller at man sparer på feil sted. Vi vil ikke betale for én hotellnatt, så vi sender deg med et nattfly fra dette stedet til østkysten. Greit, men da kommer jeg til å være helt ubrukelig når jeg ankommer.

Det kan hjelpe å beskrive slike lærdommer på en forsiktig måte, slik at ledelsen styres mot mer produktiv samhandling.

Galen Low: Jeg liker det som en form for strategisk kommunikasjon, særlig at de kanskje ikke får nøyaktig samme versjon. Ledelsen får versjonen med lærdommene, men ikke nødvendigvis alt det interne rotet som finnes i teamversjonen.

Payson Hall: Absolutt. Jeg liker ikke helt metaforen om skittentøy. Noe av det klokeste noen har sagt til meg, er at de fleste prøver å gjøre det riktige så godt de kan, med den informasjonen de har tilgjengelig. Det er veldig lett å komme inn og, hvis man vil være en idiot, gjennomføre et retrospektiv på denne måten:

Dere gjorde ikke dette. Dere gjorde ikke dette. Dere unnlot å gjøre dette. Det er ikke poenget. Du må anta at folk gjorde så godt de kunne med den informasjonen de hadde. Spørsmålet er da: Hvilken informasjon hadde dere tilgjengelig? Hvordan kan vi få den til dere tidligere?

Vi må ha en konstruktiv tilnærming, for hvis folk tror at du leter etter noen å korsfeste, kommer du ingen vei. Det vil ikke ha noen verdi.

Galen Low: Greit. Jeg vil gjerne gå videre med prosessen. Vi sa at vi skulle gå gjennom den, så la oss anta at alle er med. Vi skal gjennomføre et prosjektretrospektiv. Hvordan ser prosessen din for et prosjektretrospektiv ut? Kan du gå gjennom den som om jeg var prosjektlederen for det aktuelle prosjektet?

Payson Hall: La oss anta at vi avslutter et prosjekt som har pågått i ett år. Det er altså et stort prosjekt, med et team på 10–12 personer, slik at vi har et visst omfang. Det første jeg vil gjøre, er å ha et møte med deg.

Du er prosjektlederen. Jeg vil ha et møte med deg. I utgangspunktet handler det om å bygge en relasjon. Hvis du inviterte meg inn, er dette enkelt. Hvis jeg ble pålagt deg av ledelsen eller prosjektkontoret, må jeg oppmuntre deg til å stole på meg. Jeg må forklare prosessen, slik at du vet hva du kan forvente.

Jeg kommer til å si: Jeg lover deg én ting. Jeg kommer ikke til å overraske deg. Alle funn jeg gjør, får du se før noen andre gjør det. Du får mulighet til å argumentere. Kanskje du kan endre mening på meg. Du kan gi meg andre data eller en annen måte å se saken på.

Det reduserer mye av stresset for prosjektlederen. Det er bra for oss begge. Jeg trenger ikke at prosjektlederen er redd for meg. Jeg vil ikke at vedkommende skal holde tilbake informasjon. Det er faktisk et av de største problemene jeg kan få, hvis folk begynner å holde tilbake informasjon.

Det er som å snakke med en politibetjent og begynne å oppføre seg veldig mistenkelig. Politibetjentens ører spisses, hårene reiser seg i nakken, og dynamikken blir helt annerledes. Det er mye bedre om vi har en samtale.

Når vi har etablert en god relasjon, forklarer jeg prosessen og sier at det første jeg vil gjøre, er å forstå hva dere satte dere fore å gjøre. Finnes det definisjonsdokumenter? Rapporter eller notater? Hvordan var prosjektet definert?

God prosjektledelsespraksis tilsier at vi bør ha en form for mandat eller prosjektdefinisjon som sier hva vi prøver å oppnå. Noen gjør dette bedre enn andre, men jeg må forstå hva du trodde du skulle gjøre.

Deretter vil jeg forstå hvordan det endret seg. Vanligvis ser jeg etter dokumentasjon. Jeg snakker med deg om hva du trodde du skulle gjøre, og spør: Ble dette skrevet ned noe sted? Fantes det en skriftlig definisjon av hva dere prøvde å gjøre?

Det kan være krav, et prosjektmandat eller noe annet. Jeg spør deg hvordan dette endret seg underveis. Var det endringsordre? Kan du dele dem med meg? Det jeg egentlig prøver å forstå, er hvor dere startet, og hvordan prosjektet utviklet seg over tid.

Alle prosjekter utvikler seg. Jo lenger prosjektet pågår, desto flere verktøy blir byttet ut, og programvareversjoner blir oppdatert. Derfor er det nyttig for meg å ta et steg tilbake og forstå dette.

Hvis du for eksempel arbeidet med et ettårig prosjekt og traff en fartsdump etter tre måneder fordi det måtte gjøres en oppdatering av PeopleSoft, og alle kongens hester og alle kongens menn brukte en måned på å sette alt sammen igjen, er prosjektet ditt én måned forsinket.

Da kan jeg som del av funnene si: Dette skyldtes ikke deg. Det var en uheldig hendelse. I fremtiden bør vi enten avklare om programvaren skal oppdateres under prosjektet, eller sørge for at det er satt av tid til det i tidsplanen.

Jeg kan hjelpe med å sette dette inn i riktig sammenheng på en måte du ikke kan, fordi det kan virke defensivt hvis du sier: Vent litt, de oppdaterte dette midt i prosjektet. Jeg kan komme inn som en utenforstående og si: Dette skjer. Ja, oppdateringen var dårlig, men den var likevel forståelig ut fra informasjonen som var tilgjengelig.

Så jeg snakker med deg, forklarer hva du kan forvente, og begynner med å samle inn så mye forarbeid som mulig, slik at jeg ikke trenger å belaste deg. Definisjon, endringsordre, risikostyring og eventuelle statusrapporter.

Et tips til lytterne dine: En av de beste måtene å lære prosjektledelse på er å sette seg ned med et års statusrapporter. Finn frem kaffe og les gjennom rapportene.

Da ser du at det noen ganger skjer en liten hendelse i måned to. I måned tre er hendelsen litt større. I måned fire viser det seg at den er blitt et fullverdig problem. Det betyr ikke nødvendigvis at folk holdt tilbake informasjon. De forsto ikke betydningen.

Jeg arbeidet med et prosjekt der vi gjennomførte en prosjektgjennomgang. Dette lignet mer på en obduksjon. Jeg arbeidet ikke med teamet, men fikk bare dataene. Det var et sykehus som skulle installere et nytt system. Den første måneden sa de at de skulle flytte til de nye lokalene mot slutten av måneden. Den andre måneden sa de at det var et problem med flyttingen, men at de fortsatt burde kunne flytte ved slutten av måneden.

Den tredje måneden sa de at de hadde møtt enda en hindring. Dette var et ettårig prosjekt, og de trengte lokalene de skulle arbeide i. Prosjektlederen – og jeg kritiserer ikke prosjektlederen – hadde ingen følelse av at det hastet. Vedkommende reagerte bare på omstendighetene.

Hvis jeg hadde vært i den situasjonen, ville jeg kanskje sendt opp nødraketter og ropt høyt: Vi har et problem her. Vi må enten eskalere dette, eller justere forventningene til ettårsprosjektet.

Men altså: Jeg skal se på statusrapportene. Jeg isolerer meg et sted, av en eller annen grunn ser jeg alltid for meg at dette skjer på en lørdag, og går gjennom alt. Jeg noterer avvik. Hvor hoppet tidsplanen? Var det samtaler i statusrapportene, risikologgen eller endringsloggen som forklarte hoppet?

Jeg lager notater ved siden av og bygger en enkel tidslinje i Excel eller Word, slik at jeg kan orientere meg. Jeg var ikke der, så jeg er som en historiker i ettertid som prøver å skrive ned høydepunktene i det som skjedde. Deretter snakker jeg med prosjektlederen for å fylle hullene og få mer informasjon.

Når prosjektlederen forstår at jeg er der for å hjelpe, og jeg selv har fått oversikt, ber vi teamet bruke 60–90 minutter på forberedelser. Jeg vil at de skal tenke på tre ting: Hvilke interessante hendelser skjedde? Det kan være at folk giftet seg eller fikk barn. Hvilke ting skjedde som var heldige eller smarte? Hva gjorde vi som egentlig var tilfeldig, men som viste seg å være en god idé? Eller hvilke fartsdumper møtte vi? Hva var problemene våre?

Det kan være et programvareproblem vi trodde var trivielt, men som viste seg å være svært vanskelig. Programvaren kan ha blitt oppdatert midt i prosjektet og satt oss tilbake. Databaseadministratoren kan ha fått covid og vært borte i to uker på et kritisk tidspunkt. Be teamet identifisere to eller tre interessante hendelser, ting som festet seg hos dem.

Alle kommer til å ha et ulikt perspektiv på hva som skjedde. Det er Rashomon-effekten.

Når det er tid for selve møtet, dekker jeg en vegg med papir og lager en enkel tidslinje med viktige milepæler og hendelser jeg har funnet i statusrapportene. Jeg forklarer prosessen, gir alle noen lapper og spør: Hvilke hendelser husker dere?

Da Susan giftet seg, var det veldig hyggelig. Vi hadde det morsomt i bryllupet. Flott. Det fine med slike hendelser er at de hjelper folk med å orientere seg i tid. Dette skjedde før Susan giftet seg, og dette skjedde etterpå. De husker kanskje ikke at det var i mai, men Susan vet når hun giftet seg. Ting gikk bra, og rett etter at Susan giftet seg, skjedde dette andre.

Vi plasserer hendelsene på tidslinjen. Det er en oppvarming. Vi tillegger dem ingen betydning utover at de er tidspunkter. Deretter kan vi spørre: Hva var de gode tingene som skjedde? Vi ansatte Jim, og han var den nye personen som hadde langt flere ferdigheter enn vi trodde. Det var svært nyttig. Flott, la oss sette det opp.

Hvilke fartsdumper møtte vi? Hva skjedde som bremset oss? Regnværet, strømbruddet eller noe annet. Vi bygger en tidslinje slik at folk visuelt kan se hvordan prosjektet utviklet seg. Det setter i gang flere samtaler.

Jeg kan tenke på et konkret eksempel der vi bygget tidslinjen, og prosjektlederen sa at vi virkelig hadde kjørt oss fast omtrent midtveis. Vi begynte å få mange spørsmål fra noen sentrale interessenter, og det tok mye tid. Da vi snakket om hva annet som foregikk, innså de at de hadde fått en ny interessent midt i prosjektet uten å bruke tid på å orientere vedkommende.

Det er ikke nødvendigvis en feil. Når du unngår kuler og løper i hundre kilometer i timen, er det lett å tenke: Mary Sue er ute, Jim er inne. Greit, jeg må ringe og snakke med ham. Men det kan være nødvendig å bruke en time på å forklare hva vi prøver å oppnå, hva hans rolle er, hva min rolle er, hvor vi står, og hvilke utfordringer vi har.

Det er lett å hoppe over dette, og det kan være svært farlig. Da vi bygget tidslinjen, innså teamet at byttet av interessent skapte ringvirkninger og uro i flere måneder. Teamet ble stadig avbrutt og fikk alle disse ulike spørsmålene uten å forstå hvorfor.

Når man ser tidslinjen og noen sier: Det var da vi byttet sponsor, kan man plutselig forstå sammenhengen. Ideen er at tidslinjen hjelper folk med å orientere seg rundt de viktige hendelsene.

Deretter gjennomfører vi risikostyring i ettertid. Det er den enkleste risikostyringsøkten du kan tenke deg. Vi går til et blädderblock eller en tavle og sier: Her er noen viktige ting som skjedde. Gode eller dårlige nyheter.

Så stiller vi tre spørsmål: Hva kunne vi ha gjort for å oppdage dette tidligere? For å oppdage muligheten, risikoen eller problemet tidligere? Noen ganger er svaret ingenting. Hva kunne vi ha gjort for å øke sannsynligheten for det gode eller redusere sannsynligheten for det dårlige? Noen ganger finnes det heller ikke noe svar.

Og finnes det noe vi kunne gjort for å redusere konsekvensene av det dårlige eller begrense kostnaden ved det gode? Det er her vi sier: Det var bra at vi kjøpte 14 bærbare datamaskiner. I fremtiden bør vi sørge for å ha rett til å returnere dem.

De var helt ubrukte, og vi hadde ikke noe lager igjen ved slutten. Da slipper vi å forklare hvorfor vi brukte de ekstra to tusen dollarene. Resultatet bygger på teamets bidrag. Det er ikke spekulasjon eller fantasi om fremtiden. Det er en måte å si: I ettertid skulle vi ønske at vi kunne sende en melding på flaske til oss selv og gjøre disse tingene annerledes.

Dette blir et førsteutkast til den endelige rapporten: Her er det teamet satte seg fore å gjøre. Her er det de oppnådde. Her er hva det kostet. Her er hvor lang tid det tok. Her er ting de gjorde underveis som var rosverdige. Og her er ting som var uheldige, eller hendelser som skapte press på tidsplan, omfang eller ressurser.

Her er også forslag til hva dere kan gjøre i fremtiden for å avhjelpe eller redusere dette. Rapporten fra et retrospektiv skal ikke være en telefonkatalog. Ingen kommer til å lese den. Den bør være på én eller to sider, eller en kort oppsummeringspresentasjon som sier: Her er noen gode lærdommer vi kan bruke til prosessforbedring.

Galen Low: Fortell meg om detaljnivået, for vi snakker om å få oversikt over alle milepælene og tingene som skjer gjennom prosjektet. Alle orienterer seg rundt tidslinjen. Noen kommer kanskje med 10, 15 eller 20 ting. Diskuterer dere dem grundig mens folk setter dem opp på tavlen, eller handler det hovedsakelig om å identifisere dem og komme tilbake til dem senere for å stille de tre spørsmålene?

Payson Hall: Det blir en skjønnsmessig vurdering. Jeg vil gi folk nok tid til å få en aha-opplevelse, men jeg vil ikke gå ned i et kaninhull som gjør møtet veldig langt eller avbryter samtalen.

Det handler om hvor mye årsaksanalyse vi skal gjøre. Hvis samtalen er nyttig i tre eller fem minutter, er det flott. Når det har gått tre eller fire minutter, eller samtalen slutter å være produktiv, kan man si: Greit, la oss ta dette videre. Vi kan undersøke det litt mer utenfor møtet sammen med dem som kjenner saken best, og bringe resultatet tilbake.

Galen Low: Det er derfor man trenger gode fasiliteringsferdigheter. Vi snakker mye om dette i fellesskapet: Må prosjektlederen, eller noen andre i prosjektteamet, være god til å fasilitere? Jeg kommer stadig tilbake til at det hjelper, for selv om du ikke fasiliterer, forstår du at ikke alle problemer i verden kommer til å bli løst i den økten.

Noe kan tas videre utenfor møtet, men du må kunne snakke om de store tingene, se etter forbedringsområder og finne ut hvordan du kan utnytte ting som gikk bra eller smarte ideer som oppsto under selve prosjektet.

Payson Hall: Absolutt. Det er en av fordelene ved å bruke noen utenfra organisasjonen, eller i det minste noen utenfra prosjektet. Hvis vedkommende er en god fasilitator, vil han eller hun sørge for fremdrift. Jeg er en tidligere ingeniør som er under rehabilitering. Hvis du presenterer et virkelig godt problem, får jeg lyst til å gå i dybden og snakke om det. Jeg har sett dette før, og slik løste vi det. Jeg har en flott bok hjemme.

Men det er ikke nyttig. Du trenger noen som spør: Gjør vi konstruktive fremskritt? Og hvordan passer dette inn i det større bildet av det vi prøver å oppnå?

Galen Low: Jeg liker perspektivet om at dette er et førsteutkast til en rapport som du kan dele med andre som skal ta på seg andre prosjekter, eller med en fremtidig versjon av deg selv som skal se på dette igjen og sannsynligvis ikke ønsker å gå gjennom et stort Ishikawa-diagram for å finne årsaken.

Og så blir det det eneste problemet vi løste i hele økten. Vi fikk én lærdom fra retrospektivet, men vi kjenner i det minste årsaken. Jeg forstår hva du mener med å bruke skjønn når det gjelder detaljnivået. Det liker jeg godt.

Den andre tingen du sa, var at dette er risikostyring i ettertid. Mange ser på risikostyring som noe fremtidsrettet: Hvordan kan vi bidra til at gode ting skjer i fremtiden, og hindre at dårlige ting skjer? Jeg vet ikke om alle alltid kobler retrospektivet til risikostyring, men det du sier om gjentatte retrospektiver, retrospektiver ved bestemte beslutningspunkter i prosjektet eller etter prosjektet, viser at dette egentlig handler om en melding på flaske til deg selv i fortiden, som du i stedet sender til andre i fremtiden. Den skal hjelpe dem med å unngå det dårlige som skjedde, eller dra nytte av noe godt som kan skje.

Payson Hall: Absolutt. Det viktigste her er at det må handle om hva som fungerte og ikke fungerte, ikke om hvem som fungerte eller ikke fungerte.

Det er hele fasilitatorens oppgave. Dette handler ikke om skyld. Det er lett i en podkast å si: La meg fortelle hvor smart jeg er, og hvor mange smarte ting jeg har gjort. Jeg arbeidet med et team som nettopp hadde avsluttet ett prosjekt, og jeg hjalp dem med å starte det neste.

De skulle gjennomføre et retrospektiv om prosjektet de nettopp hadde avsluttet, og jeg gjorde noe veldig dumt. Jeg inviterte meg selv og spurte om det var greit at jeg kom. Jeg har jo sagt at man ikke skal ha turister, bare personer som var involvert. Da jeg snakket med teamet, spurte jeg én av dem om han skulle delta i retrospektivet. Han svarte nei, de kommer bare til å skylde på meg for alt som gikk galt.

Det fikk meg til å spisse ørene. Jeg tenkte at dette var interessant. Jeg gikk inn i retrospektivet, og personen som fasiliterte, siden jeg bare var observatør, var forferdelig. Vedkommende ville vite hvem som hadde ansvaret, og det er ikke spørsmålet man skal stille i et retrospektiv.

Jeg ble imponert over teamet. De snakket om det som hadde skjedd, og fasilitatoren spurte hvem som skulle ha gjort det. Teamet svarte at det ikke var viktig hvem som gjorde det. Dette var det som skjedde. De nektet å kaste personen under bussen.

Senere oppdaget jeg at personen var alkoholiker og hadde et alvorlig problem. Vedkommende var faktisk ansvarlig for mye av dette, men teamet forsto at det ikke var noe man skulle dele med fasilitatoren, og at det ikke var relevant.

Det var et personlig problem som vedkommende måtte håndtere. La oss snakke om det vi lærte av prosjektet. Du vil aldri være avhengig av at en gruppe slitne og irriterte mennesker har så mye disiplin og empati at de ikke korsfester en person som ikke er til stede.

Det var et fantastisk team. Så ja, du vil ikke ha turister, og du vil at fasilitatoren skal vite hva i all verden han eller hun gjør. Dette handler om å forbedre prosessen, ikke om hvem vi skal legge skylden på.

Den overordnede regelen er å anta at alle gjorde så godt de kunne med den informasjonen som var tilgjengelig.

Det kan hende at folk ikke hadde de riktige ferdighetene. Det er prosjektlederens ansvar, med mindre du ga meg en CV som sa at du var ekspert på kunstig intelligens, og jeg ga deg en enkel KI-oppgave som overveldet deg. Da var det prosjektlederens feil. Det var et misforhold mellom oppgaven og ferdighetene.

Vi trenger ikke si at det var prosjektlederens feil. Vi kan si: Vi hadde ikke ferdighetene vi trodde vi hadde på dette området. Det handler ikke om at Simon ikke er høy nok for denne attraksjonen. Vi hadde ikke ferdighetene vi trodde vi hadde på dette området, og vi må styrke dem fremover hvis vi skal gjennomføre et lignende prosjekt.

Galen Low: Mye av dette er vevd inn i måten du har lagt opp prosessen på.

Mange spør meg hvordan de skaper psykologisk trygghet i en økt. En del av svaret er å sette seg ned med dem som kan ha innvendinger før møtet, bygge tillit, bygge en relasjon og forklare prosessen. Man må også gjøre de praktiske avklaringene og si: I økten vi skal begynne på, skal vi ikke spørre hvem. Vi skal spørre hva. Så får man alle med på den ideen og forsterker den underveis.

Hvis du var fasilitator i en slik økt, og personen som egentlig fasiliterte bare var en deltaker som sa at dette sannsynligvis var Brads feil, hvordan ville du snudd samtalen når folk begynner å skylde på hverandre og det utvikler seg til en heksejakt?

Payson Hall: Første gang gir du dem et gult kort. De sier at dette handler om hvem som gjorde hva, og du svarer: Nei, vi skal anta at alle gjorde så godt de kunne. Vi skal snakke om hva som skjedde, og hvilke konsekvenser det fikk.

Andre gang kan du, avhengig av konteksten, gi dem et gult kort igjen. Du kan si: Vet du hva, la oss ta en pause. Ta personen til side og snakk med vedkommende.

Dette handler ikke om hvem som ødela noe. Den samtalen kan dere ta senere. Du og prosjektlederen kan snakke om det etterpå. Men dette møtet handler om hva vi lærte, hva som fungerte og hva som ikke fungerte – ikke om hvem som fungerte eller ikke fungerte. Det er ikke konstruktivt. Vi kan ikke endre fortiden. Alt vi kan gjøre, er å lære av den.

Galen Low: Jeg liker det. Den andre siden handler om hvordan vi rammer inn ting. Vi kan si at vi kanskje ikke hadde de riktige ferdighetene, og ta det inn i rapporten. Så leser noen i ledelsen dette og leser mellom linjene: Det var sannsynligvis Bretts feil.

Finnes det noe man kan gjøre for å unngå den tolkningen?

Payson Hall: Hvis Brett ikke er høy nok for attraksjonen, er det et personlig problem vi må håndtere. Det er ikke noe jeg vil ha inn i rapporten. Jeg overlater det til prosjektlederen.

Det som kommer inn i rapporten, handler ofte om at ledelsen har andre prioriteringer enn prosjektlederen. Hvis et prosjekt med høyere prioritet begynner å koke over, og de henter en av dine beste ressurser for å løse problemet, er det deres rett.

Poenget med retrospektivet er å si: Det fikk konsekvenser for dette prosjektet. Uten å skylde på ledelsen kan vi si at prosjektet hadde en bemanningsplan, og at folk av ulike årsaker ble omdisponert underveis. Kanskje noen fikk covid, eller noen rømte hjemmefra for å gifte seg, og vi fikk ressursproblemer.

I fremtiden må vi sørge for bedre avtaler og tenke gjennom dette. Dette er en personlig fordom fra min side: Hvis tidsplanen din forutsetter at ingen kan bli syke, og at alle må møte opp 40 timer hver uke, lever du allerede i en fantasiverden. Det prosjektet kommer ikke til å gå som planlagt.

Noen blir syke. Barn faller av sykler. Foreldre blir syke. Folk må på avslutninger eller andre viktige begivenheter. Hvis ressursene dine er overbelastet, blir prosjektplanen svært sårbar.

Det kan være et funn. Vi var for aggressive i måten vi fordelte ressurser på. Vi trengte flere ressurser for å gjøre dette. Kanskje visste vi det på dette tidspunktet, men sa ikke fra. Da vi oppdaget det, burde vi ha sendt en endringsordre for å sikre at alle forsto at vi trengte flere ressurser, mer penger, flere personer eller mer tid enn vi først trodde.

Galen Low: Jeg liker det kriteriet for hva som skal inn i rapporten, og at man selvfølgelig tar hensyn til prosjektteamet som var involvert. Det er forskjell på prosjektproblemer vi kan lære av, og for eksempel personalproblemer som ikke hører hjemme i rapporten fordi de ikke handler om hvordan prosjekter gjennomføres. De handler mer om bemanning og vurdering av kandidater.

Payson Hall: Rapporten må også være diplomatisk. Som konsulent får jeg betalt for å si fra hvis keiseren ikke har klær på, men det finnes måter å levere slike nyheter på som ikke gjør situasjonen verre.

Du bør derfor være diplomatisk i språket du bruker for å beskrive lærdommene. Målet er å formulere det så positivt som mulig: Vi gjorde dette, og i fremtiden anbefaler vi at det gjøres annerledes. Ikke: Herregud, dette rotet vi virkelig til. Det hjelper ingen. Folk gjorde så godt de kunne med informasjonen som var tilgjengelig på det tidspunktet.

Galen Low: Jeg liker det. Vi har gått gjennom prosessen med å forberede retrospektivet, se på dokumentasjonen, plassere milepælene på en tidslinje, diskutere dem og snakke om hvordan vi kan utnytte gode hendelser eller unngå dårlige hendelser i fremtiden.

Så blir det til en rapport. Men det jeg ofte hører fra folk, er: Vi kommer ikke til å gjennomføre et retrospektiv, for hva skal vi gjøre? Lage en rapport som ingen leser, eller som blir feiltolket? Så blir den liggende på en hylle, mens andre prosjektteam, inkludert oss selv, fortsetter å møte på de samme problemene.

Hvordan kan du som fasilitator, og hvordan kan organisasjoner generelt, sørge for at anbefalingene faktisk fører til endring i stedet for bare å samle støv?

Payson Hall: La oss pakke ut det du sa. Et stort problem er hvis jeg lager en rapport på 30 sider med funn og anbefalinger. Ingen kommer til å lese den. Derfor må vi være korte. Vi må prioritere.

Hvis du som prosjektleder sier at det er seks ting vi kunne gjort bedre, vil jeg si: Velg to eller tre av dem. Jeg skal forsøke å forbedre dem og få budskapet frem til ledelsen.

Vi må passe på at vi ikke overvelder folk med tiltak. Det er en vanskelig balanse, særlig i unge organisasjoner som fortsatt lærer. Vi må velge ut noe. Vi kan ta resten neste gang, men teamet vil fortsatt kjenne til dem.

Det finnes altså en formell del: PMO-en eller ledelsen får to eller tre funn som organisasjonen kan gjøre bedre. Du må prioritere listen slik at folk ikke blir overveldet og bare legger den til side.

De mer omfattende funnene, om hva dere gjorde smart og hva dere kunne gjort annerledes, tar alle deltakerne med seg til neste prosjekt. Det finnes en formell og en uformell del. Den uformelle delen er etter min mening den viktigste for å endre kurs.

Det finnes en myte om at man gjennomfører retrospektiver, skriver alt ned og legger det inn i en stor database for hele organisasjonen. Jeg har aldri sett dette fungere i noen organisasjon. Det er en idé, men det blir for omfattende og for kontekstavhengig.

Det beste er derfor de to eller tre anbefalingene som ledelsen bør kjenne til. Du nevnte møterom. En vanlig lærdom fra større prosjekter er at de bør ha et eget prosjektrom.

Hvis du har et sted der du kan gjennomføre møter på kort varsel, særlig i kontorer som er fulle og der man må lete etter et opplæringsrom eller møterom, kan et lite, dedikert prosjektrom spare teamet for mye tid.

Tenk på hvor mye tid folk bruker på å gå rundt og finne ut hvor møtet skal være. Bare ved å ha et eget rom kan du raskt spare personuker. Det er den typen tiltak som kan havne øverst på listen. Ledelsen hører kanskje ikke dette første eller andre gang, men tredje eller fjerde gang tenker de kanskje: Vi sier dette hele tiden, men gjør ingenting. Kanskje de endelig forstår poenget.

Galen Low: Jeg liker også dette skillet. Det kan virke logisk for noen, men ja, det finnes strategiske anbefalinger og strategisk kommunikasjon oppover i organisasjonen. Ikke gjør det til en lang roman. Velg ut de viktigste tingene.

Så finnes det også et uformelt nivå av læring som skjer uansett. Jeg vet ikke om alle setter nok pris på dette. Du beskrev det tidligere som at alle som deltok i retrospektivet, tar med seg et frø til neste prosjekt. Det er enormt viktig og kanskje vanskelig å måle, men det må absolutt være en del av prosessen.

Vi skal ha en rapport, men alt vi snakket om, lærer vi også som mennesker og lagrer i hjernen uten nødvendigvis å skrive det ned. Vi bygger på den felles erfaringen. Selv tidslinjen gjør at folk husker ulike ting.

Rashomon-effekten du nevnte, betyr at de også lærer av hverandres perspektiver. De tar med seg denne erfaringen, enten de husker detaljene eller ikke. De fikk muligheten til å diskutere hva som skjedde, hvilken innvirkning det hadde, og hvordan de kan gjøre noe godt med det eller unngå noe dårlig i fremtiden. Jeg synes det er veldig interessant.

Payson Hall: For å knytte samtalen tilbake til risikostyring: I de fleste planleggingsprosesser samler man kjerneteamet i et rom og sier: La oss se fremover. Hvilke risikoer ser dere?

Hvis du nettopp har gjennomført et retrospektiv, er du godt forberedt på å tenke på slike hendelser som risikoer. Du er klar til å si: I det forrige prosjektet gjorde vi dette, og vi innså at vi skjøt oss selv i foten. Vi skulle ønske at vi hadde gjort det på denne måten.

Det ligger øverst i bevisstheten, og det bygger på noe reelt, ikke noe hypotetisk. Du kan si: Vi møtte dette, gjorde dette, og det var en god idé. Vi møtte dette, gjorde dette, og det var en forferdelig idé.

Når disse erfaringene kommer på bordet, skjer to ting. For det første forbedres risikostyringen i prosjektet. For det andre hører alle i rommet historien din, og den sprer seg videre organisk i organisasjonen.

Galen Low: Jeg liker også ordet historie, for det er virkelig det dette er. Databasen er hodet vårt, og det som skjedde i et prosjekt, er en historie vi kan dele og bruke til å dele kunnskap.

Det passer godt som overgang, for jeg tenkte at vi skulle sette av litt tid på slutten til spørsmål fra publikum. Et av spørsmålene handlet om en forhåndsvurdering, eller det noen kaller en forhåndsobduksjon. Jeg tror du egentlig har svart på dette: Ja, det er risikostyring. Man kan ha en forut for prosjektet i stedet for en etterpå.

Men hva tenker du om å gjøre begge deler? Hvordan henger risikostyring sammen med gjentatte retrospektiver? Hvis man arbeider smidig, gjennomfører sprinter og har et retrospektiv, bør man da også ha et eget møte for risikostyring fremover, eller glir det sammen?

Payson Hall: Jeg tror det glir sammen. I et smidig retrospektiv spør man ofte: Hva er hindringene? Hva skulle vi ønske at vi hadde gjort annerledes? Dette gjør vi, men det er ikke effektivt. Slike ting blir oppgaver for å redusere risikoen i neste sprint.

I en konkret smidig sammenheng snakker vi om retrospektiv og risikostyring samtidig. Vi tar lærdommene og spør hvordan vi kan bruke dem i neste sprint. Det synes jeg er sunt.

Galen Low: Absolutt. Samtalene henger sammen, for man går videre inn i neste sprint, og det finnes en fremtid. Det handler ikke bare om å se i bakspeilet, men om den samme samtalen.

Jeg vil også ta opp et annet spørsmål. Vi snakker om ting som skjedde i prosjektet. Noen ganger handler det om valg som personer i prosjektteamet tok, men noen ganger går problemene utover beslutningene teamet tok. De kan være mer miljømessige eller organisatoriske.

Hvis for eksempel den grunnleggende årsaken til et problem var at prosjektteamet ble tappet for ressurser, fordi noen av de viktigste personene ble flyttet til et annet prosjekt, hvordan fanger man opp dette og rapporterer det videre slik at man kan påvirke endring utenfor det enkelte prosjektet?

Payson Hall: Jeg tenker ofte i form av funn. Funnet kan være at prosjektet opplevde ressursutfordringer fordi teammedlemmer ble omdirigert til prosjekter med høyere prioritet.

Det er en ganske nøytral måte å si det på. Samtidig antar man at dette var prosjekter med høyere prioritet, slik at ledelsen får tvilen til gode. Det er funnet: Prosjektet opplevde ressursutfordringer fordi noen ressurser ble omdirigert til andre oppgaver underveis.

Hva er anbefalingen? Det kan være å vurdere å øke bemanningen på prosjektet, slik at man får mer fleksibilitet. En annen anbefaling kan være å sørge for at prosjektlederen får så mye forhåndsvarsel som mulig dersom ressursene må omdirigeres, slik at prosjektlederen får tid til å reagere og finne en erstatter.

Da sier du ikke at noen gjorde noe galt. Du sier at dette skjedde, at det fikk en konsekvens, og at dette er noe vi kan gjøre i fremtiden for å forsøke å unngå det.

Galen Low: Jeg liker tanken på funn. Jeg skal ta ett siste spørsmål. Hva er de viktigste temaene å fokusere på i et retrospektiv? Mange er interessert i økonomi, prosess, gjennomføring og metode, men man har begrenset tid. Hva vil du anbefale at man fokuserer på for å få mest mulig ut av tiden?

Payson Hall: Noe av dette avhenger av konteksten. Men hvis jeg skal ta utgangspunkt i min erfaring, handler mye om hvorvidt det finnes en tydelig definisjon som er delt med og godkjent av interessentene, sponsoren og kunden.

Når dette utvikler seg, har vi da en effektiv endringsstyringsprosess? Det er et bevisst valg. Hvis du vil henge mer pynt på juletreet, vil det koste mer og ta lengre tid.

Dette er ikke den eneste feilen, men det er en av de opprinnelige feilene som skaper mange problemer som senere ser ut som noe annet. Vi undervurderte dette. Nei, dere gjorde en god jobb med å anslå det. Deretter vokste prosjektet, og dere hevet ikke flagget og sa at arbeidsmengden økte uten at dere fikk flere ressurser.

Galen Low: Ja, jeg liker det. Det finnes en sammenheng mellom alt. Jeg liker det du sier om hva interessentene har til felles, og hvilket perspektiv som vil være mest verdifullt i samtalen. Veldig bra.

Jeg tror tiden vår er ute, men Payson, tusen takk for at du var med i dag. Det har vært en stor ære å ha deg med. Før vi slipper lytterne, hvordan kan folk finne ut mer om det du gjør i Catalysis Group?

Payson Hall: Hvis du går til catalysisgroup.com, finner du informasjon om opplæring og rådgivning. Hvis du går til ressursene, finner du også et par artikler du kan laste ned om risikostyring. De handler om hvordan man gjennomfører en risikostyringsøkt, og de kan også være svært nyttige som grunnlag for et retrospektiv.

Galen Low: Flott. Det viser også at Payson er en svært underholdende skribent. Hver artikkel jeg har lest av deg, har fått meg til å le høyt, men jeg har også tatt med meg historien videre. Så hvis noen trodde at retrospektiver og risikostyring var tørt, bør de sjekke ut Paysons materiale. Jeg legger ved lenken i shownotatene nedenfor.

Til lytterne våre: Jeg håper dere fikk mye ut av dette. Det var et par spørsmål vi kanskje ikke rakk å besvare, og vi tar dem opp i fellesskapet og snakker videre om dem der.

Payson Hall: Og hvis dere vil sende meg en e-post med spørsmål, svarer jeg gjerne på spørsmål som dukker opp etter at vi har avsluttet.

Galen Low: Da har dere det, folkens. Som alltid: Hvis du vil bli med i samtalen med over tusen likesinnede forkjempere for prosjektledelse, kan du bli med i fellesskapet vårt. Gå til thedigitalprojectmanager.com/membership for å lære mer. Hvis du likte det du hørte i dag, kan du abonnere og holde kontakten på thedigitalprojectmanager.com.

Til neste gang: Takk for at du lyttet.