Sådan afholder du en effektiv retrospektiv og anvender læringen i fremtidige projekter

Læs transskriptionen:

 

Vi prøver at transskribere vores podcasts ved hjælp af et softwareprogram. Bær over med eventuelle stavefejl, da botten ikke er korrekt 100 % af tiden.

Galen Low: Hej alle sammen, og tak fordi I lytter med. Mit navn er Galen Low fra The Digital Project Manager. Vi er et fællesskab af digitale fagfolk med en mission om at hjælpe hinanden med at blive dygtigere, mere selvsikre og bedre forbundet, så vi kan øge værdien af projektledelse i en digital verden. Hvis du vil høre mere om det, så gå over på thedigitalprojectmanager.com.

I dag taler vi om projektretrospektiver: hvordan man afholder dem effektivt, og hvordan man sikrer, at den læring, man indsamler i sine retrospektiver, faktisk omsættes til forbedringer i fremtidige projekter.

Med mig i dag har jeg Payson Hall, grundlægger og ledende konsulent hos Catalysis Group, som i mere end 30 år har hjulpet organisationer med at lære af deres projektfejl.

Payson, det er fantastisk at have dig med i programmet.

Payson Hall: Hej, jeg er glad for at være med og glad for at møde publikum.

Galen Low: Ja, og jeg er faktisk glad for, at du nævnte det, for vi gør noget lidt anderledes i dag. Vi sender live med vores medlemmer som publikum i studiet, og vi tager spørgsmål undervejs via vores Slack-fællesskab. Michael er også i studiet sammen med mig, så han kommer til at udfylde nogle af spørgsmålene. Vi fletter dem ind i samtalen, og alt kan ske. Så lad os gøre det levende.

Okay, lad os dykke ned i det. Jeg tænkte, at jeg ville begynde med et saftigt spørgsmål, fordi vi har talt om det her, og fordi du i årtier har arbejdet som konsulent med projektretrospektiver for alle mulige projekter, herunder softwareprojekter og store systemintegrationsprojekter. Jeg vil gerne spørge dig om dette: Når du kommer ind som ekstern konsulent for at afdække alle projektets beskidte små hemmeligheder, ser projektteams dig så som en ven eller en fjende? Føles det som mentorskab? Føles det som en revision?

Payson Hall: Normalt er det en venlig udveksling. Jeg vil gerne skelne mellem tingene, for en del af min konsulentpraksis består i at lave projektobduktioner. Hvis et projekt kører alvorligt af sporet, og der er bekymring for, at folk vidste, at det var på vej af sporet, men ikke sagde noget, så minder det meget mere om en revision.

Jeg arbejder faktisk sammen med en statsrevisor i Californien, og jeg har revideret it-projekter til en værdi af milliarder af dollars. Her forsøger man normalt at opbygge en sag, som advokaterne kan bruge mod en systemintegrator. Et mere almindeligt og venligt retrospektiv handler bare om, at folk siger: Hej, vi er blevet færdige med dette projekt.

Lad os få nogen ind til at facilitere et tilbageblik, ikke? Det er det, et retrospektiv er. Et tilbageblik, hvor man spørger: Hvad lærte vi? Hvad gjorde vi, som var smart, og som vi måske ikke lagde mærke til på det tidspunkt? Hvad gjorde vi, som vi set i bakspejlet måske ville have gjort anderledes? Det er i virkeligheden en risikostyringssession, hvor man ser i bakspejlet. Hvad kan jeg gøre bedre næste gang? Hvad gjorde jeg, som var smart, og som jeg gerne vil sikre, at jeg gør mere af?

Galen Low: Jeg kan virkelig godt lide den skelnen, for jeg tror, at nogle af dem, der lytter, måske ikke mærker forskellen så tydeligt. For dem føles hvert retrospektiv som en obduktion, som om de skal være beviser i en retssal, eller som om det bliver en form for skyldplacering, i stedet for, som du siger, bare at se i bakspejlet og lære af sine fejl.

Payson Hall: En af de eneste store regler for retrospektiver er, at du som projektleder aldrig bør afholde dit eget retrospektiv. Der findes mange måder at gøre det på, men nogle af de ting, der ikke gik godt, er ting, som du selv gjorde. En god facilitator kan sørge for, at fokus bliver på, hvad der skete, hvornår det skete, og hvad vi lærte af det. Ikke: Nå, Galen, du lavede virkelig en stor fejl, vel?

Det er ikke konstruktivt. Folk går i forsvarsposition, og så kører det af sporet. Uanset om du henter nogen udefra, eller om du har en person internt, som du holder af og stoler på, og som er en god facilitator, har du brug for en ekstern part — en person, der ikke var involveret i projektet og ikke selv har noget på spil — til at facilitere samtalen. På den måde ender vi ikke med en masse blod på gulvet.

Galen Low: Det er fair. Og det er faktisk en interessant måde at se det på, for jeg ved, at mange åbner denne podcast for at finde ud af, hvordan de skal afholde deres eget retrospektiv.

Og det er bestemt virkeligheden for mange projektteams, og vi kommer ind på nogle af de råd og ting, du har lært undervejs. Men jeg kan godt lide dit råd om, at det kan være en anden — og måske ligefrem bør være en anden — der giver det perspektiv og sørger for, at det ikke udvikler sig til en skyldplacering. Og at der ikke ligger en masse blod på gulvet bagefter, som du siger.

Payson Hall: Det skal være en person, der kommer ind med et andet sæt antagelser. Tænk på de projekter, du har været med på. Mens du arbejdede på projektet, gjorde du dig antagelser om, hvad årsagerne til problemerne var. De kan være rigtige, eller de kan være forkerte. En person, der kommer ind uden de antagelser, kan være åben over for andre oplysninger eller andre fortolkninger.

Galen Low: Det kan jeg godt lide. Jeg kan godt lide perspektivet fra en person, der ikke har været involveret i et langt projekt i 12-18 måneder, og som derfor ikke føler sig så tæt knyttet til det, at vedkommende ikke længere kan se skoven for bare træer.

Måske kan vi begynde med det overordnede. Lad os zoome lidt ud og give vores lyttere et udgangspunkt. Kan du forklare, hvad et projektretrospektiv er set fra dit perspektiv, og hvorfor det er værd at afholde?

Payson Hall: Godt spørgsmål. Et retrospektiv betyder at se tilbage. Ideen er, at vi når et vigtigt tidspunkt i projektet, eller at vi når slutningen af et projekt. Så ser vi tilbage og siger: Okay, lad os få vejret. Hvad lærte vi i den seneste fase? Hvilken læring vil vi anvende i den næste fase? Eller hvad vil vi ikke anvende i det næste projekt?

Hvad gjorde vi, som ved et tilfælde var smart? Eller hvad gjorde vi, hvor vi bagefter tænker: Hvis jeg kunne gøre det om, hvad ville jeg så have gjort anderledes? Hvis jeg kunne sende en besked tilbage til mig selv gennem en tidsmaskine, hvad ville jeg så have ønsket at gøre anderledes? Ideen er egentlig bare at stoppe op, trække vejret og se tilbage på projektets hændelser i deres sammenhæng.

Som du sagde: Zoom ud og få det store billede, så vi forstår, hvad der er vigtigt, og hvad der ikke er vigtigt. Nogle ting er bare sorte svaner. Det var en uventet hændelse, som covid-19. Jeg kommer ikke til at planlægge efter pandemier i de fleste projekter fremover, men hvis det skete for dit projekt, var det et alvorligt slag.

Der kan måske være noget læring i det, men nogle ting er bare: nej. Måske havde du brug for et dusin bærbare computere, så du bestilte 14, fordi et par stykker kunne være defekte ved levering. Det viste sig, at én faktisk var defekt, og det var smart, fordi du havde en stram tidsplan.

Det er sådan noget, hvor man tænker: Okay, hvis man sammenholder prisen på de to ekstra computere med den forsinkelse, man undgik, kan det være en rigtig god læring. Og det er ikke sådan, at den ekstra computer er spildt. Vi kan måske returnere den. Vi kunne have skrevet en kontrakt, der sagde, at vi havde ret til at returnere den, hvis vi ikke åbnede den.

Det kan være, at de 1.000 dollars var givet virkelig godt ud. Det sparede os for tre ugers forsinkelse. Hvis du har arbejdet med hardware inden for de seneste tre år, hvor forsyningskæderne har været helt kaotiske, ved du præcis, hvad jeg taler om.

Galen Low: Helt sikkert. Jeg kan virkelig godt lide det eksempel. Og jeg kan godt lide noget vigtigt, som mange normalt ikke tænker på: Ja, retrospektiver kan være et øjeblik til at reflektere over noget, der gik virkelig godt — den smarte ting, der fungerede fantastisk.

Når man ser tilbage, spørger man nogle gange: Hvad gik godt? Og så siger folk: Teamet arbejdede virkelig godt sammen, vi kommunikerede godt, og så videre. Men når det gælder en præcis læring, siger man måske: Kan I huske, da den person bookede det alternative mødelokale? Vores første lokale blev aflyst, eller der skete noget med det, og vi havde en reserve? Det var fantastisk. Det er noget, vi kan lære af og bygge ind i vores proces næste gang.

Og som du siger, sørger vi for at have et vilkår i kontrakten, der siger, at hvis vi bestiller en ekstra bærbar computer, kan vi returnere den, hvis den er uåbnet. Så har vi sikret os og kan bruge det i fremtidige projekter som en smart læring.

En anden ting, jeg virkelig godt kunne lide, var, at du sagde, at retrospektiver enten finder sted ved projektets afslutning eller på et vigtigt tidspunkt undervejs. Mange, jeg taler med, tænker, at et retrospektiv betyder, at projektet er slut, og at det derfor er for sent. Vi kan se i bakspejlet, men der er en trist tone: Det kunne have været bedre, men nu er det for sent. Vi må vente til det næste projekt. I stedet kan man faktisk afholde et retrospektiv på andre tidspunkter i projektet. Det vil jeg gerne vende tilbage til senere.

Payson Hall: Ja, det er faktisk en af de interessante ting, vi har fået fra agile tilgange, fordi de typisk afholder et lille retrospektiv ved afslutningen af hver sprint. Jeg har arbejdet på projekter, hvor vi afholdt dem ved milepæle på større projekter, men Agile sagde nærmest: Vent, hvorfor gør vi ikke dette løbende?

Fordi vi gør det oftere, bliver de mindre. Teamet ender med at forstå processen, kan gå ind i den og få den gennemført. Jeg synes, det var en rigtig fin nyskabelse, at de agile folk gjorde det tydeligt, når de talte om retrospektiver ved afslutningen af hver sprint.

Galen Low: Jeg kan godt lide det skift i tankegang: Vi kan faktisk gøre det her mere regelmæssigt, og så bliver det mindre. For at spille djævlens advokat tror jeg, at mange mennesker, især mange organisationer, vil sige: Ja, læring. Vi vil lære af vores fejl. Vi vil fejle hurtigt.

Vi vil gøre alle disse ting. Men når det kommer til stykket, er det ikke alle organisationer, der vil investere i at se tilbage. De siger: Vi lærte det undervejs. Vi behøver ikke holde et møde om det. Lad os bare gå videre til det næste. Men hvad kræver det at gennemføre et ordentligt projektretrospektiv? Og er det umagen værd, hvis man som organisation siger: Jeg ved ikke. Folk mærkede smerten under projektet. Vi bør bare gå videre. Lad os ikke hente Payson ind. Lad os ikke afholde et retrospektiv. Hvad ville du sige til det?

Payson Hall: Det er et godt spørgsmål. Når vi taler om procesforbedring, skal vi sikre, at omkostningen ved læringen og forbedringen ikke overstiger værdien af forbedringen. Hvad kræver det at afholde et retrospektiv? Lad mig give et eksempel og føre dig igennem det. Det første, jeg vil sige, er, at konteksten betyder noget.

Hvis vi taler om et projekt til flere millioner eller milliarder, kræver det en større indsats end et lille projekt. Der vil være langt flere data. Hvis det er et projekt i problemer, kræver det mere arbejde end et projekt, der forløb forholdsvis problemfrit. Hvis et projekt bryder sammen, og advokater er involveret, afholder du ikke et retrospektiv — du laver en obduktion, og det kan være meget dyrt.

Her er et datapunkt. Jeg afholdt for nylig et retrospektiv med et team på omkring 12 personer for et projekt, der varede cirka 18 måneder. Det var et internt projekt. Projektet opfyldte kravene, var en smule forsinket, og det var acceptabelt. Ingen advokater var involveret.

Spørgsmålet var: Okay, vi er nået til slutningen. Lad os få vejret. Hvad lærte vi af det? Hvad kan vi gøre anderledes? De enkelte teammedlemmer brugte sandsynligvis fire til seks timer hver på forberedelse, mødet og opsamlingen. Som facilitator brugte jeg nok omkring 12 timer på at forberede, facilitere og skrive tingene sammen til sidst.

Projektlederen brugte nok 8-12 timer på at give mig oplysninger og gennemgå tingene. Det retrospektiv krævede altså omkring to personuger. Hvis vi forestiller os et dusin personer plus projektlederen, der arbejdede i 18 måneder, svarer det til omkring 1.000 personuger.

Det betyder, at 0,2 % blev brugt på at se tilbage og forsøge at forstå, hvad vi lærte, hvad vi kan gøre anderledes, og hvad vi gjorde, som var smart. Tænk over det. Det eneste, du skal gøre, er at finde en måde at få en værdi svarende til to personugers arbejde, og så har du et positivt afkast af investeringen.

Det kan ske på et par måder. Det kan være strukturelt: Her er en anbefaling til PMO'et om at gøre noget anderledes, som vil spare tid og besvær. Det kan også være organisk. Det kan være: Folkens, vi gjorde en ekstra indsats i dette projekt for at gennemføre en kodegennemgang, bare som et eksempel.

Det hjalp virkelig. Vi eksperimenterede med det, og det hjalp. Nu tager alle i teamet det med til det næste projekt. Ofte spreder de sig som en frøkapsel: De arbejder måske videre på det samme projekt eller på forskellige projekter. De bærer læringen med sig og kan argumentere for den i det næste projekt.

Jeg har aldrig set et retrospektiv, hvor vi ikke endte med at sige: Her er en liste over resultater, anbefalinger og forslag. Og jeg mener, at det mindst er de to personuger værd, som vi investerer.

Galen Low: Fair nok. Vi taler om større projekter, men er der en nedre grænse for mindre projekter? Hvis dit projekt kun varede fire uger, virker det måske ikke som om, afkastet er der, hvis man investerer to personuger. Skrotter man det og siger, at vi ikke kan afholde et retrospektiv for disse projekter? Samler man dem? Hvis man har fem små projekter, afholder man så et fælles retrospektiv?

Payson Hall: Nej, det var faktisk en fejl, jeg begik tidligt i min karriere.

Du bør ikke have nogen med i et retrospektiv, som ikke var involveret i projektet. Hvis vi antager, at teamet ikke er i krig med sig selv, vil det være mere trygt at have en oprigtig samtale om, hvad der fungerede og ikke fungerede, med et nært team, man har arbejdet sammen med, end med en gruppe fremmede. Derfor ville jeg aldrig overveje at slå projekter sammen.

Efter en række små retrospektiver kan det dog være interessant at samle projektlederne og spørge, hvilke fælles tråde der går igen, hvis PMO'et ønsker at gøre det. Men til selve retrospektivet vil jeg ikke have turister. Jeg vil sikre mig, at det kun er teamet.

Kan vi gøre det i mindre skala? Absolut. Den formelle proces, som vi kommer ind på om lidt, kan jeg føre dig igennem. På et projekt, der varer 18 måneder, føler folk, at de hver dag hopper op på hamsterhjulet, og selv om der sker vigtige begivenheder, er det let at miste konteksten.

Det er let ikke at kunne se skoven for bare træer. Derfor kan det være nyttigt at tage en pause og sige: Her er nogle vigtige udviklinger undervejs. På et projekt, der varer tre eller fire uger, kan jeg forestille mig, at man samles i en time og får dækket det meste af det, der skal ske.

Jeg ville nok forberede mig lidt og sikre mig, at jeg forstod projektet, og forstå fra projektlederen, hvad vedkommende måske ville have ud af det. Men ja, man kan sandsynligvis afholde et ret uformelt retrospektiv på en time eller to.

Galen Low: Du nævnte det tidligere: I en agil ramme kan man afholde en form for retrospektiv ved hver sprint, og måske kræver det også en form for refleksion ved projektets afslutning for at samle al læringen og udarbejde anbefalinger. Jeg kan godt lide tanken om, at de to personuger ikke nødvendigvis skal ligge ved projektets afslutning.

Selv på et projekt med et team på 12 personer findes der mindre måder at gøre det på. Så jeg vil gerne dykke ned i det, når vi kommer til processen.

Payson Hall: Hvis du har et team på otte personer og samler alle i et rum i en time, er det otte person-timer. Med et par timers forberedelse og et par timer til projektlederen bagefter kan du måske gennemføre det hele på 12 timer. Det inkluderer, at du udarbejder en punktopstillet liste på én side over, hvad I lærte undervejs.

Galen Low: Der er også en alternativomkostning. Hvis du bruger den time og afdækker en læring, der sparer en halv million dollars hver gang, har investeringen betalt sig selv mange gange. Det er omkostningen ved ikke at afholde et retrospektiv. Det er værd at tænke over.

Du nævnte tidligere interne teams som eksempel. Mange af dem, der lytter, arbejder på bureauer, og det kommer ofte op, at de arbejder for en kunde. Kunden vil ikke betale for retrospektivet, fordi de siger, at det er sådan, man bliver bedre som organisation.

Samtidig ønsker ledelsen heller ikke at investere i det, fordi de siger, at det ikke er fakturerbar tid. Så vi skal tage otte eller 12 personer ud af arbejdet i en periode for at tale om, hvordan et projekt gik, uden at tjene penge? Nej, lad os lade være. Jeg har faktisk selv oplevet det. Jeg har haft et retrospektiv, hvor en administrerende direktør kom ind og sagde: Alle skal ud af lokalet. Det her er spild af tid. Gå tilbage til det fakturerbare arbejde.

Det var en stor øjenåbner for mig. Ikke alle ser værdien af det i et bureaus forretningsmekanik. Men for dem, der leder et projekt og kan se værdien af et retrospektiv, hvordan kan de argumentere for denne form for læring og overbevise ejere og ledelsesteams om værdien af et retrospektiv, der ikke er fakturerbart?

Payson Hall: Jeg vil gerne være høflig, men hvis jeg arbejdede et sted, hvor den administrerende direktør kom ind og sagde, at vi ikke behøver gøre det næste projekt bedre end dette, og at der ikke er mere at lære, ville jeg få mit cv klar. Det ville bekymre mig meget.

Før jeg forlod IBM Professional Services for at starte Catalysis Group, arbejdede jeg der i fire år med projekter til flere millioner dollars. Og du har ret: Typisk betaler kunden ikke for dette. Organisationen betaler for det.

Organisationen betaler, fordi den vil vide: Hvad kan vi gøre bedre med hensyn til kundetilfredshed? Hvad kan vi gøre bedre med hensyn til effektivitet? Hvor trådte vi forkert, så vi kan forbedre processen? Især konsulentvirksomheder bør stoppe op og tænke over, hvad de fakturerer pr. time.

Hvor mange timer skal du spare, før det har værdi? For dem, der ikke arbejder med rådgivning, kan jeg nævne, at min faktureringssats er 2.000 dollars om dagen. Det er ikke det, jeg får udbetalt. Når jeg arbejder med administrative opgaver, koster det ikke organisationen 2.000 dollars om dagen. Hvis jeg bruger en time på administration sammen med en gruppe på seks personer, og vi finder en måde at spare fire dage på det næste projekt, har vi allerede betalt mange gange for retrospektivet.

Jeg kender ikke konteksten. Organisationen kan have blødt penge, og den administrerende direktør kan have haft brug for, at I genererede indtægter. Men generelt er det efter min erfaring ikke svært at sælge. Man kan begynde i det små. Hvis det er et kort projekt, så lad os mødes over frokosten. Lad os sætte en time af.

Da jeg var helt ny, arbejdede jeg hos Price Waterhouse. Hver måned holdt partnerne en særlig morgenmad for medarbejderne, og den begyndte klokken syv om morgenen. Vi mødte op klokken syv, de købte morgenmad til os, og vi tænkte: Vi slipper billigt. De køber morgenmad på dette fine sted. Partnerne tænkte derimod: Jeg har lige narret alle disse mennesker til at møde to timer tidligere på arbejde til et personalemøde. Og de er glade, fordi jeg gav dem mad.

Professionelle servicebureauer forsøger generelt at opbygge deres forretning. Der kan være formildende omstændigheder. Hvis noget brænder, kan jeg forstå, at den administrerende direktør siger: Sluk branden først, og kom tilbage bagefter. Men jeg synes, man skal begynde i det små. Værdien af retrospektiver vil vise sig.

En af de ting, der minder om risikostyring, er, at når du får en vigtig indsigt fra et retrospektiv eller fra en risikostyringssession, som sparer dig for en masse besvær, skal du fortælle folk det. Sig: Vi afholdt dette retrospektiv, fik denne idé, anvendte den på det næste projekt, og den sparede os for to uger. Sådan overbeviser du ledelsen om, at det er god brug af tiden.

Men begynd i det små, så det ikke er en stor investering.

Galen Low: Begynd i det små og skaf dokumentation, ikke? Beviser, der viser: Det her skabte værdi, sidste gang vi gjorde det. I nogle tilfælde kan man måske hellere bede om tilgivelse end om tilladelse og derefter skaffe dokumentationen. Det synes jeg er stærkt.

Beslutningstagere har måske ikke beviser for, at det vil skabe værdi, og der ligger penge på bordet, som kan hentes. Der foregår et projekt lige nu, der er fakturerbare timer, og alle otte personer i lokalet kunne arbejde med det i stedet for. De har måske endnu ikke set beviset på, at et retrospektiv faktisk kan udvikle og optimere en virksomhed på en værdifuld måde.

Payson Hall: Et hyppigt resultat af et retrospektiv er et dokument eller en præsentation med højdepunkterne. Den kan tilpasses ledelsen. Måske findes der en intern version og en version, som man deler. Hvis den er godt udformet, kan den hjælpe ledelsen med at forstå, at de nogle gange selv er årsag til problemer.

Det kan være, at ressourcer omplaceres med meget kort varsel, eller at man sparer den forkerte dollar. Vi vil ikke betale for en hotelnat, så vi sender dig med et natfly fra den ene kyst til den anden. Fint, men så er jeg mentalt uarbejdsdygtig, når jeg ankommer. På en diplomatisk måde kan man formidle den slags læring og hjælpe med at styre ledelsens tanker i retning af mere produktivt samarbejde.

Galen Low: Jeg kan godt lide det som strategisk kommunikation, især tanken om, at de måske ikke får den samme version. Ledelsen får versionen med læringen, mens teamversionen måske indeholder mere af det beskidte vasketøj.

Payson Hall: Absolut. Jeg bryder mig ikke så meget om metaforen med beskidt vasketøj. En af de klogeste ting, nogen nogensinde har sagt til mig, er, at de fleste mennesker forsøger at gøre det rigtige så godt, de kan, med de oplysninger, de har til rådighed. Det er meget let at komme ind bagefter og sige: I gjorde ikke dette. I gjorde ikke hint. I undlod at gøre noget andet.

Det er ikke pointen. Man må antage, at folk gjorde det bedste, de kunne, med de oplysninger, der var til rådighed. Spørgsmålet er så: Hvilke oplysninger havde I? Hvordan kan vi få dem til jer tidligere? Vi skal have en konstruktiv tilgang, for hvis folk tror, at du leder efter nogen, der skal korsfæstes, kommer du ingen vegne. Det vil ikke skabe nogen værdi.

Galen Low: Fair nok. Jeg vil gerne dykke ned i processen. Vi sagde, at vi ville gennemgå den, så lad os antage, at alle er med på at afholde et projektretrospektiv. Hvordan ser din proces for et projektretrospektiv ud? Kan du føre mig igennem den, som om jeg var projektleder på det pågældende projekt?

Payson Hall: Lad os antage, at vi afslutter et projekt, der har kørt i et år. Det er et stort projekt med et team på 10-12 personer, så vi har en vis ramme. Det første, jeg vil gøre, er at holde et møde med dig.

Du er projektlederen. Jeg vil holde et møde med dig for grundlæggende at skabe en relation. Hvis du har inviteret mig, er det let. Hvis ledelsen eller projektkontoret har pålagt dig mig, er en af mine opgaver at få dig til at stole på mig. Jeg skal forklare processen, så du ved, hvad du kan forvente.

Jeg vil sige: Jeg lover dig dette. Jeg vil ikke overraske dig. Alle resultater, jeg kommer frem til, ser du, før nogen andre ser dem. Du får mulighed for at argumentere. Du kan ændre min opfattelse. Du kan give mig flere data eller en anden måde at se det på.

Det tager en stor del af presset væk fra projektlederen. Det er godt for os begge. Jeg har ikke brug for, at vedkommende er bange for mig. Jeg ønsker ikke, at personen skjuler noget. Det er faktisk et af de største problemer, jeg kan få, hvis folk begynder at skjule oplysninger.

Når man taler med en politibetjent og begynder at opføre sig mistænkeligt, spidser betjenten ører, hårene rejser sig i nakken, og dynamikken ændrer sig. Det er meget bedre at have en samtale. Når vi har skabt en relation, forklarer jeg processen og siger, at det første, jeg vil forstå, er: Hvad satte du dig for at gøre?

Findes der dokumenter, rapporter eller notater, som definerer projektet? Hvad var projektets definition? God projektledelsespraksis siger, at vi bør have et kommissorium eller en projektdefinition, der beskriver, hvad vi forsøger at opnå. Nogle gør det bedre end andre, men jeg er nødt til at forstå, hvad du troede, du skulle gøre.

Derefter vil jeg forstå, hvordan det ændrede sig. Jeg leder typisk efter dokumentation. Jeg spørger: Hvad troede du, du skulle gøre? Og så: Var det skrevet ned nogen steder? Var der en skriftlig definition? Det kan være krav, et projektkommissorium eller noget andet. Hvordan ændrede det sig undervejs? Var der ændringsordrer? Kan du dele dem med mig?

Jeg forsøger at forstå, hvor I begyndte, og hvordan det udviklede sig over tid. Alle projekter udvikler sig. Jo længere projektet varer, desto flere værktøjer bliver udskiftet, og softwareversioner bliver opdateret.

Det er nyttigt at træde et skridt tilbage og forstå det. Som ekspert kan jeg derefter se, at hvis I arbejdede på et projekt, der skulle vare et år, og ramte en bump efter tre måneder, fordi PeopleSoft skulle opdateres, og det tog en måned at få alt samlet igen, så projektet blev en måned forsinket, kan jeg hjælpe med at placere det i den rigtige sammenhæng.

En del af resultatet kan være: Det her var ikke jeres skyld. Det var en uheldig hændelse. Fremover bør vi enten beslutte, om softwaren skal opdateres under projektet, eller afsætte tid i tidsplanen til det. Hvis du selv siger: De opdaterede det midt i projektet, kan det lyde defensivt. Jeg kan derimod komme ind udefra og sige: Det sker. Det var ikke nødvendigvis godt, men det var rimeligt ud fra de oplysninger, man havde.

Jeg taler altså med dig, forklarer, hvad du kan forvente, og forsøger først at indsamle så meget materiale som muligt, så jeg ikke behøver belaste dig. Projektdefinition, ændringsordrer, risikostyring og statusrapporter. Et af de bedste råd til dem, der vil lære projektledelse, er at sætte sig med et års statusrapporter, kaffe og tid til at læse dem.

Du vil se, at der i måned to sker en lille hændelse. I måned tre er den lidt større, og i måned fire viser det sig at være et fuldt udviklet problem. Det betyder ikke nødvendigvis, at folk skjulte noget. De forstod bare ikke betydningen.

Jeg arbejdede på et projekt, hvor jeg gennemgik et projekt. Det var nærmere en obduktion. Jeg arbejdede ikke med teamet, men fik dataene. Det var et hospital, der skulle installere et nyt system. Den første måned sagde de, at de ville flytte til deres nye lokaler ved udgangen af måneden. Den anden måned sagde de, at der var et problem, men at de stadig burde kunne flytte ved udgangen af måneden.

Den tredje måned sagde de, at der var dukket endnu en slange op, men at de ville kunne klare det. Det var et etårigt projekt, og de skulle have den bygning, de skulle arbejde i. Jeg bebrejder ikke projektlederen, men vedkommende havde ikke nogen fornemmelse af, hvor hastende det var. Personen reagerede på fakta og tænkte, at det var uden for vedkommendes kontrol.

Hvis jeg havde været i den situation, ville jeg måske have sendt nødsignaler og råbt vagt i gevær: Vi har et problem. Vi er nødt til at eskalere det, eller også skal jeg nulstille dine forventninger til det etårige projekt.

Jeg gennemgår altså statusrapporter. Jeg isolerer mig et sted, gennemgår materialet og noterer afvigelser. Hvor sprang tidsplanen? Var der noget i statusrapporterne, risikologgen eller ændringsloggen, der forklarede springet?

Jeg laver en grov tidslinje i Excel eller Word for at komme i gang, fordi jeg ikke selv var der. Jeg er som en historiker efter begivenheden, der forsøger at skrive højdepunkterne ned. Derefter taler jeg med projektlederen for at udfylde hullerne og få flere oplysninger.

Når projektlederen forstår, at jeg er der for at hjælpe, og jeg selv er orienteret, beder vi teamet bruge 60-90 minutter på at forberede sig. Jeg vil have dem til at tænke på tre ting: Hvilke interessante begivenheder fandt sted? Hvilke ting var heldige eller smarte? Og hvilke bump på vejen opstod der?

Det kan være, at nogen blev gift eller fik børn under projektet. Det kan være, at vi ved et tilfælde gjorde noget, der viste sig at være en rigtig god idé. Eller at vi tog ud på stedet uden en presenning, men Galen tilfældigvis havde en i bagagerummet. Så er det måske en god idé at medbringe en presenning, når det regner.

Hvilke problemer havde vi? Hvilke ting, vi troede var trivielle, viste sig at være vanskelige? Blev softwaren opdateret midt i projektet og forsinkede os? Blev databaseadministratoren syg med covid og var væk i to uger på et kritisk tidspunkt?

Bed teamet identificere to eller tre interessante begivenheder, som skilte sig ud. Alle har et forskelligt perspektiv på, hvad der skete — Rashomon-effekten.

Når mødet begynder, dækker jeg en væg med papir og laver en grov tidslinje med vigtige milepæle og begivenheder fra statusrapporterne. Jeg forklarer processen, giver alle nogle post-it-sedler og spørger: Hvilke begivenheder fandt sted?

Da Susan blev gift, var det sjovt. Vi havde en god tid ved brylluppet. Fint. Det gode ved sådan en begivenhed er, at den orienterer folk i tiden. Der var ting før Susans bryllup og ting efter. De husker måske ikke, at det var i maj, men Susan ved, hvornår hun blev gift. De kan sige: Tingene gik godt, og lige efter Susans bryllup skete dette.

Vi placerer begivenhederne på tidslinjen som opvarmning. Der tildeles ingen betydning ud over, at de er tidspunkter. Derefter taler vi om de gode ting. Vi ansatte Jim, som var ny, men havde langt flere kompetencer, end vi troede. Det var virkelig nyttigt. Lad os sætte det på tidslinjen.

Hvilke bump på vejen var der? Hvad forsinkede os? Regnvejr, strømsvigt eller noget andet. Vi bygger en tidslinje, så folk visuelt kan se, hvordan projektet udviklede sig. Det sætter gang i flere ting, som folk begynder at tale om.

Jeg kan huske et konkret eksempel, hvor vi byggede tidslinjen, og projektlederen sagde: Vi gik virkelig i stå her. Vi begyndte at få mange spørgsmål fra nogle få vigtige interessenter, og det tog en masse tid. Da vi talte om, hvad der ellers foregik, opdagede de, at en ny interessent var blevet sat ind midt i projektet, uden at teamet havde taget sig tid til at orientere personen.

Det er ikke en fejl. Når man undviger kugler, der flyver med 160 kilometer i timen, er det let at springe over. Man får en besked: Mary Sue er ude, Jim er inde. Man tænker: Fint, jeg ringer til ham. Men måske bør man faktisk bruge en time sammen med ham og forklare, hvad vi forsøger at opnå, hvad hans rolle er, hvad min rolle er, hvor vi er, og hvilke udfordringer vi har.

Det er let at springe over, men det kan være farligt. Da vi byggede tidslinjen, indså teamet, at udskiftningen af interessenten havde skabt uro i et par måneder, fordi teamet hele tiden blev revet væk fra arbejdet og fik forskellige spørgsmål.

Når man ser tidslinjen og nogen siger: Det var, da vi skiftede sponsor, kan man pludselig se sammenhængen. Ideen er, at tidslinjen orienterer folk om de vigtige begivenheder. Derefter laver vi risikostyring set i bakspejlet.

Det er den letteste risikostyringssession nogensinde. Vi kan gå til et whiteboard og sige: Her er nogle vigtige ting, der skete, gode eller dårlige. Derefter stiller vi tre spørgsmål. Hvad kunne vi have gjort for at opdage dette tidligere? Var der noget, vi kunne have gjort? Nogle gange var der ikke.

Var der noget, vi kunne have gjort for at øge sandsynligheden for de gode ting eller mindske sandsynligheden for de dårlige? Nogle gange var der heller ikke. Vi kan tale om det og tage noter.

Var der noget, vi kunne have gjort for at reducere virkningen af de dårlige ting eller begrænse gevinsten ved de gode ting? Her kan vi sige: Det var godt, at vi købte 14 bærbare computere. Fremover bør vi sikre os retten til at returnere dem. De var uåbnede, og vi havde ikke brug for dem bagefter.

Resultatet kommer fra teamet og er ikke spekulativt. Det handler ikke om at forestille sig fremtiden, men om at sige: Hvis vi kunne sende en besked tilbage til os selv, ville vi gøre disse ting anderledes.

Det er det første udkast til den endelige rapport. Her er, hvad teamet satte sig for at gøre. Her er, hvad de opnåede. Her er, hvad det kostede, og hvor lang tid det tog. Her er nogle ting, de gjorde undervejs, som var rosværdige. Og her er nogle uheldige ting eller begivenheder, der skabte pres på tidsplan, omfang eller ressourcer.

Her er, hvad man kan overveje at gøre fremover for at afhjælpe eller reducere det. Rapporten skal ikke være en telefonbog, som ingen læser. Den skal være en side eller to eller en kort opsummerende slide: Her er et par gode pointer, som vi kan bruge til procesforbedring.

Galen Low: Tal med mig om dybden, for vi taler om at få alle milepæle og begivenheder gennem projektet med. Alle orienterer sig på tidslinjen. Nogle kommer måske med 10, 15 eller 20 ting. Drøfter I dem i dybden, mens folk sætter dem op på tavlen, eller handler det mest om at identificere dem og vende tilbage til dem senere, når I stiller de tre spørgsmål?

Payson Hall: Det ender med at være en vurderingssag. Jeg vil give folk nok tid til at få en aha-oplevelse. Jeg vil ikke gå ned ad et kaninhul, der gør mødet meget langt eller afbryder samtalen.

Hvor meget årsagsanalyse skal vi lave? Hvis samtalen er produktiv i tre eller fem minutter, er det fint. Når den ikke længere er produktiv, siger vi: Lad os tage dette med og undersøge det offline sammen med de personer, der er tættest på det. Derefter kan vi bringe resultatet tilbage.

Galen Low: Det er derfor, man har brug for facilitering. Vi taler meget om, hvorvidt en projektleder eller nogen på et projektteam skal være god til facilitering. Selv hvis du ikke faciliterer, hjælper det at forstå, at alle verdens problemer ikke bliver løst i den ene session.

Noget af arbejdet foregår offline, men man skal kunne tale om de store ting og se på forbedringsområder eller på, hvordan man kan udnytte de ting, der gik godt, og de smarte idéer, der opstod under projektet.

Payson Hall: Absolut. Det er en af fordelene ved at hente nogen udefra organisationen eller blot udefra projektet. Hvis vedkommende er en god facilitator, er jeg som tidligere ingeniør fristet til at gå i dybden, når nogen præsenterer et virkelig godt problem. Jeg kan fortælle, at jeg har set det før, og hvordan det blev løst, eller anbefale en bog. Men det hjælper ikke. Man har brug for en person, der spørger: Gør vi konstruktive fremskridt? Og hvordan passer det ind i det større billede af det, vi forsøger at opnå?

Galen Low: Jeg kan godt lide perspektivet på, at dette er et første udkast til en rapport, som kan deles med andre, der skal overtage andre projekter — eller med dit fremtidige jeg, som skal vende tilbage til det og sandsynligvis ikke ønsker at dykke ned i et stort Ishikawa-diagram for at finde årsagen.

Den anden ting, du sagde, var, at dette er risikostyring set i bakspejlet. Mange ser risikostyring som noget fremadrettet: Hvordan får vi gode ting til at ske i fremtiden, og hvordan forhindrer vi dårlige ting i at ske? Ikke alle forbinder retrospektiver med risikostyring, men det, du siger om løbende retrospektiver, ved bestemte faseovergange eller efter projektet, giver mening.

Det er en besked i en flaske til ens fremtidige kolleger om, hvordan man undgår noget dårligt, der skete, eller udnytter noget godt, der kan ske.

Payson Hall: Absolut. Det afgørende er, at det skal handle om, hvad der fungerede, og hvad der ikke fungerede — ikke om, hvem der fungerede, og hvem der ikke gjorde.

Det er facilitatorens opgave. Dette handler ikke om skyld. Jeg arbejdede med et team, der netop havde afsluttet et projekt, og jeg hjalp dem med at begynde på det næste. De skulle afholde et retrospektiv om det projekt, de netop havde afsluttet, og jeg gjorde noget dumt: Jeg inviterede mig selv og spurgte, om jeg måtte komme.

Jeg havde lige sagt, at man ikke skulle have turister med. Jeg talte med teamet, og en person sagde, at han ikke ville deltage i retrospektivet, fordi de bare ville give ham skylden for alt, hvad der var gået galt.

Det fangede min opmærksomhed. Jeg gik med til retrospektivet som observatør, og personen, der faciliterede det, var forfærdelig. Vedkommende ville vide, hvem der var ansvarlig for hvad, hvilket ikke er det spørgsmål, man stiller i et retrospektiv.

Teamet talte om, hvad der skete, og da facilitatoren spurgte, hvem der skulle have gjort noget, sagde teamet, at det ikke var vigtigt, hvem der gjorde det. De forklarede, hvad der skete, og nægtede at kaste personen under bussen.

Jeg fandt senere ud af, at personen var alkoholiker og havde et alvorligt problem. Han var faktisk ansvarlig for meget af det, men teamet forstod, at det ikke var relevant for facilitatoren eller for retrospektivet. Det var et personligt problem, som nogen skulle håndtere. Samtalen skulle handle om, hvad vi lærte af projektet.

Man bør aldrig stole på, at en gruppe trætte og irriterede mennesker har så meget disciplin og empati, at de ikke korsfæster den, der ikke er til stede. Det var et fantastisk team. Man bør undgå turister og sikre sig, at facilitatoren ved, hvad vedkommende laver. Det handler om at forbedre processen, ikke om at finde nogen at bebrejde.

Den vejledende regel er igen at antage, at alle gjorde det bedste, de kunne, med de oplysninger, de havde. Måske havde de ikke de rigtige kompetencer. Det er projektlederens ansvar, medmindre man fik et cv, hvor der stod, at personen var ekspert i kunstig intelligens, gav vedkommende en enkel opgave inden for kunstig intelligens, og personen blev overvældet. Så var det projektlederens ansvar, fordi der var et misforhold mellem opgaven og kompetencerne.

Man behøver ikke sige, at det var projektlederens skyld. Man kan sige: Vi havde ikke de kompetencer, vi troede, vi havde på dette område. Vi skal styrke dem fremover, hvis vi skal gennemføre et lignende projekt.

Galen Low: Meget af dette er vævet ind i den måde, du har tilrettelagt processen på.

Mange spørger mig, hvordan man skaber psykologisk tryghed i en session. En del af svaret er, at man inden sessionen taler med de personer, der måske har forbehold, opbygger tillid og relationer, forklarer processen og gør det klart, at vi i sessionen ikke spørger hvem, men hvad.

Hvis du var facilitator, og en deltager begyndte at sige: Det var nok Brads skyld, hvordan ville du så genoprette fokus, når folk begynder at placere skyld og gøre det til en heksejagt?

Payson Hall: Første gang giver du dem et gult kort. Du siger: Det her handler ikke om, hvem der gjorde hvad. Vi antager, at alle gjorde det bedste, de kunne. Vi vil tale om, hvad der skete, og hvilke konsekvenser det havde.

Anden gang kan du, afhængigt af konteksten, give endnu et gult kort. Du kan sige: Lad os tage en pause. Tag personen til side og tal med vedkommende. Sig: Dette handler ikke om, hvem der ødelagde noget. Den samtale kan vi tage senere, projektlederen og jeg. Dette møde handler om, hvad vi lærte, hvad der fungerede, og hvad der ikke fungerede — ikke om, hvem der fungerede, og hvem der ikke gjorde. Det er ikke konstruktivt, og vi kan ikke ændre fortiden. Vi kan kun lære af den.

Galen Low: Jeg kan godt lide det. Den anden side handler om indramningen. Vi taler om, at vi måske ikke havde de rigtige kompetencer, og det kommer med i rapporten. Så læser en fra ledelsen den og tænker, at det nok var Bretts skyld. Kan man gøre noget for at undgå den fortolkning?

Payson Hall: Hvis Brett ikke har de rigtige forudsætninger, er det et personligt problem, som skal håndteres. Det skal ikke med i rapporten. Projektlederen må håndtere det.

Det, der kommer med i rapporten, er typisk, at ledelsen har andre prioriteter end projektlederen. Hvis et projekt med højere prioritet begynder at koge over, og de trækker en af dine bedste folk væk for at løse problemet, er det deres ret. Retrospektivet skal sige: Der var en konsekvens for dette projekt.

Uden at bebrejde ledelsen kan man sige: Projektet oplevede ressourceproblemer, fordi teammedlemmer blev omplaceret undervejs. Fremover skal vi sikre bedre aftaler og give projektlederen så meget varsel som muligt, hvis ressourcer skal flyttes, så der er tid til at finde afløsere.

Hvis din tidsplan forudsætter, at ingen bliver syge, og at alle møder op 40 timer om ugen, er planen allerede urealistisk. Nogen bliver syge. Et barn falder af cyklen. En forælder bliver syg. Nogen skal til en dimission. Hvis ressourcerne er overbelastede, bliver projektplanen skrøbelig.

Det kan være et resultat: Vi var for aggressive i vores ressourcefordeling. Vi havde brug for flere ressourcer. Måske vidste vi det ikke i starten, men da vi opdagede det, burde vi have sagt det og indsendt en ændringsordre, så alle vidste, at vi ville få brug for flere ressourcer, flere penge, flere mennesker eller mere tid.

Galen Low: Jeg kan godt lide kriteriet for, hvad der skal med i rapporten. Der er forskel på projektproblemer, vi kan lære af, og personaleproblemer, som ikke hører hjemme i rapporten, fordi de handler om bemanding og vurdering af mennesker. Det er en nyttig måde at se det på.

Payson Hall: Rapporten skal også være diplomatisk. Som konsulent bliver jeg betalt for at fortælle folk, hvis barnet er grimt, men der findes måder at levere den nyhed på, som ikke optrapper situationen. Man skal bruge et diplomatisk sprog til at beskrive læringen.

Forsøg grundlæggende at formulere det så positivt som muligt: Vi gjorde dette. Fremover anbefaler vi, at det gøres anderledes. Ikke: Vi ødelagde virkelig det her. Det hjælper ikke. Folk gjorde det bedste, de kunne, med de oplysninger, de havde på det tidspunkt.

Galen Low: Jeg kan godt lide det. Vi har gennemgået processen: forberedelse, gennemgang af dokumentationen, milepæle på en tidslinje og en samtale om, hvordan vi enten kan udnytte gode ting eller undgå dårlige ting i fremtiden.

Derefter bliver det til en rapport. Men mange siger: Vi vil ikke afholde et retrospektiv, for hvad skal vi bruge det til? Vi producerer en rapport, ingen læser den, eller den bliver misforstået, og så ender den på en hylde. Imens ser vi andre projektteams, også os selv, støde ind i de samme problemer igen og igen.

Hvordan kan man som facilitator, og hvordan kan organisationer generelt, sikre, at anbefalingerne faktisk fører til forandring i stedet for bare at samle støv?

Payson Hall: Lad os pakke det ud. Et stort problem er, hvis jeg producerer en rapport på 30 sider med resultater og anbefalinger. Ingen læser den. Derfor skal man være kortfattet og prioritere.

Hvis du som projektleder siger: Her er seks ting, vi kunne gøre bedre, vil jeg sige: Vælg to eller tre. Jeg vil forsøge at gøre dem skarpere og få budskabet frem til ledelsen. Vi må ikke overvælde folk med handlingspunkter. Det er en vanskelig balance, især i unge organisationer, der stadig lærer.

Vælg ud. Vi kan tage de andre næste gang, men teamet vil stadig kende dem. Formelt kan man sige til PMO'et eller ledelsen: Her er to eller tre resultater, som organisationen kunne håndtere bedre.

Den mere omfattende læring — hvad I gjorde smart, og hvad I kunne gøre anderledes — tager alle deltagere med sig som forslag til deres næste projekt. Der er en formel og en uformel del. Den uformelle del er efter min mening den måde, man virkelig får vendt skuden på.

Der findes en myte om, at man afholder retrospektiver, skriver dem ned og lægger dem i en stor database for hele organisationen. Jeg har aldrig set det fungere i nogen organisation. Det er for overvældende og for kontekstafhængigt. Det bedste er to eller tre anbefalinger til ledelsen.

Du nævnte mødelokaler. En almindelig læring fra større projekter er, at de bør have et dedikeret projektrum. Et sted, hvor man hurtigt kan holde møder. I mange kontorer skal man lede efter et trænings- eller mødelokale. Et lille dedikeret projektrum kan spare et team enormt meget tid.

Tænk på, hvor meget tid folk bruger på at finde ud af, hvor mødet er. Man kan spare personuger ved at have et fast lokale. Det er den slags, der kan komme øverst på en liste. Måske hører ledelsen det ikke første eller anden gang, men tredje eller fjerde gang tænker de: Vi siger hele tiden det her, men gør ikke noget ved det. Måske forstår de det til sidst.

Galen Low: Jeg kan også godt lide opdelingen. Der er strategiske anbefalinger, som skal kommunikeres strategisk, og som ikke bør være en lang roman. Vælg de vigtigste ting. Og så er der den uformelle læring, der sker uanset hvad.

Alle, der deltager i retrospektivet, tager et frø med sig til deres næste projekt. Det er måske svært at måle, men det er vigtigt at tale om som en del af processen. Vi får en rapport, men vi lærer også som mennesker og føjer til vores fælles erfaring, uden nødvendigvis at skrive alt ned.

Payson Hall: For at vende tilbage til risikostyring: I de fleste planlægningsprocesser samler man kerneteamet og spørger: Hvilke risici ser I fremadrettet?

Hvis teamet netop har gennemført et retrospektiv, er det klar til at tænke på disse hændelser som risici. Man kan sige: I vores sidste projekt gjorde vi dette og indså, at vi skød os selv i foden. Vi ville ønske, at vi havde gjort det på en anden måde.

Det er ikke hypotetisk. Det er noget, man selv har oplevet. Man kan tale med autoritet: Vi stødte på dette, gjorde sådan, og det var en god idé. Vi stødte på noget andet, gjorde sådan, og det var en dårlig idé.

Det gør to ting. For det første forbedrer det risikostyringen på det aktuelle projekt. For det andet hører alle i lokalet historien, og læringen spreder sig organisk gennem organisationen.

Galen Low: Jeg kan også godt lide ordet historie, for det er virkelig det, det er. Databasen er vores hukommelse, og det, der skete i et projekt, er en historie, vi kan dele og bruge til at udveksle viden.

Det er en god overgang til et spørgsmål fra publikum. En af dem spurgte om en præmortem. Jeg tror, du allerede har svaret på det ved at sige, at dette er risikostyring. Man kan have en før- i stedet for en efter-session. Hvad tænker du om at gøre begge dele? Hvordan hænger risikostyring sammen med løbende retrospektiver? Hvis man arbejder agilt med sprints og retrospektiver, afholder man så også et særskilt møde om risikostyring, eller flyder det sammen?

Payson Hall: Jeg tror, det flyder sammen. I et agilt retrospektiv taler man ofte om barrierer, om ting man ville ønske, man havde gjort anderledes, eller om ting, der ikke er effektive. De bliver til opgaver, der skal reducere risici i den næste sprint.

I en agil kontekst taler vi derfor om retrospektiv og risikostyring samtidig. Vi tager læringen og spørger, hvordan vi kan anvende den i den næste sprint. Det er sundt.

Galen Low: Helt sikkert. Det er ikke kun bakspejlet, for der findes en fremtid i den næste sprint, men det er stadig den samme samtale.

Et andet spørgsmål handler om ting, der sker under projektet. Nogle gange er det valg, projektteamet træffer, men andre gange er problemerne miljømæssige eller organisatoriske. Hvis et projektteams vigtigste ressourcer bliver trukket over på et andet projekt, hvordan dokumenterer og rapporterer man det, så man kan påvirke forandring uden for det enkelte projekt?

Payson Hall: Jeg tænker i resultater. Resultatet kan formuleres neutralt: Projektet oplevede udfordringer, fordi teammedlemmer blev omdirigeret til projekter med højere prioritet.

Anbefalingen kan være at øge bemandingen, så projektet har større fleksibilitet. En anden anbefaling kan være at give projektlederen så meget varsel som muligt, hvis ressourcer skal omdirigeres, så vedkommende får tid til at reagere og finde afløsere.

På den måde siger du ikke, at nogen gjorde noget forkert. Du siger: Dette skete, det havde en konsekvens, og her er, hvad vi kan gøre i fremtiden for at forsøge at undgå det.

Galen Low: Jeg kan godt lide tanken om resultater. Jeg tager ét sidste spørgsmål. Hvilke emner er vigtigst at fokusere på i et retrospektiv? Mange er interesserede i økonomi, proces, udførelse og metode, men tiden er begrænset. Hvad vil du anbefale, hvis man vil få mest muligt ud af den begrænsede tid?

Payson Hall: Det afhænger af konteksten. Men ud fra min erfaring handler meget om, hvorvidt der er en klar definition, som er delt med og godkendt af interessenterne, sponsoren og kunden.

Når definitionen udvikler sig, har vi så en effektiv forandringsstyringsproces? Det skal være et bevidst valg. Hvis du vil sætte mere pynt på juletræet, kommer det til at koste mere og tage længere tid.

Det er ikke den eneste fejl, men det er en af de oprindelige fejl, der skaber mange følgeproblemer, som senere forklæder sig som andre problemer.

Vi undervurderede virkelig dette. Nej, det gjorde I ikke. I lavede et fint estimat, men projektet voksede, og I gjorde ikke opmærksom på, at arbejdsbyrden steg, uden at ressourcerne blev øget.

Galen Low: Jeg kan godt lide det. Der er en sammenhæng mellem det hele. Hvad er det fælles grundlag med de involverede interessenter, og hvilken vinkel vil være mest værdifuld i samtalen?

Jeg tror, det var alt, hvad vi nåede i dag. Payson, tusind tak fordi du ville være med. Det har været en ære at have dig med i programmet. Før vi giver slip på vores lyttere, hvordan kan folk få mere at vide om det, du laver hos Catalysis Group?

Payson Hall: Hvis du går til catalysisgroup.com, finder du oplysninger om kurser og rådgivning. Hvis du går til ressourcerne, er der også et par artikler, du kan downloade om risikostyring. De beskriver, hvordan man afholder en risikostyringssession, og de vil også være nyttige som materiale til et retrospektiv.

Galen Low: Det kan jeg godt lide. Det viser også, at Payson er en meget underholdende skribent. Hver artikel, jeg har læst fra dig, har fået mig til at grine højt, men jeg har også taget historien med mig bagefter. Hvis nogen troede, at retrospektiver og risikostyring var tørre emner, så tjek Paysons materiale. Jeg inkluderer linket i shownoterne nedenfor.

Til vores lyttere håber jeg, at I fik meget ud af samtalen. Der var et par spørgsmål, vi måske ikke nåede, og dem tager vi op i fællesskabet.

Payson Hall: Hvis nogen vil sende mig en e-mail med spørgsmål, svarer jeg gerne på dem, også hvis de først kommer i tanke om dem lige efter, vi har afsluttet samtalen.

Galen Low: Så har I det, folkens. Som altid: Hvis du vil deltage i samtalen med over tusind ligesindede mestre i projektledelse, så kom med i vores fællesskab! Gå til thedigitalprojectmanager.com/membership for at få mere at vide. Hvis du kunne lide det, du hørte i dag, så abonnér og hold kontakten på thedigitalprojectmanager.com.

Indtil næste gang — tak fordi du lyttede.