Sådan bruger du OKR’er i dit projekt til at øge dets forretningsmæssige effekt

Læs transskriptionen:

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

Galen Low: Det har været en lang dag, og det føles, som om det projekt, du arbejder på, er langt fra at nå sit mål. Teamet føler, at missionen blot er at bygge en app for at bygge en app, uden noget større formål at gå ud fra. Du er klar til at lukke din bærbare computer for dagen, men tænker, at du måske bør gå tilbage til resultaterne fra den strategiske planlægning for at få lidt inspiration.

Måske er det bare, fordi du og dit team er for tæt på projektet og ikke kan se skoven for bare træer. Så med den sidste smule energi, du har, finder du nogle af de mere strategiske dokumenter frem, som du har fået — bare for at genopfriske visionen og målet for projektet. Og dér er det, så tydeligt som dagen er lang. Det store strategiske mål for året var... "at bygge en app".

Hvis du har svært ved at forbinde dine projektmål med strategiske forretningsmål og omvendt, så lyt videre. Vi skal undersøge, hvordan OKR'er — mål og nøgleresultater — kan give dine projekter en ramme til at skabe sammenhæng, måle effekt og motivere dine teams til at arbejde hen imod den større forretningsstrategi.

Hej alle sammen, og tak fordi I lytter med. Jeg hedder Galen Low og er 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 forbundne, så vi kan øge værdien af projektledelse i en digital verden. Hvis du vil høre mere om det, så gå over på thedpm.com/membership. Og hvis du er interesseret i fremtidsorienterede samtaler og praktiske indsigter om digital projektledelse, kan du overveje at abonnere på programmet for at få ugentlige episoder.

I dag taler vi om, hvordan man kan forbinde projektleverancer med bredere organisatoriske mål ved at integrere mål og nøgleresultater — også kærligt kaldet OKR'er — i sin projektledelsespraksis.

Med mig i dag er Carsten Ley — projektledelseskonsulent, OKR-coach og medstifter af både Asia PMO og OKR Asia.

Carsten, tak fordi du er med i dag.

Carsten Ley: Tak, Galen, fordi du inviterede mig med i programmet.

Galen Low: Jeg glæder mig virkelig til at dykke ned i det her, for jeg må indrømme, at det er et område, jeg ikke ved så meget om, så jeg kommer også til at lære med sammen med nogle af mine lyttere. Jeg synes, det er et virkelig interessant emne. Vi har talt meget i mit fællesskab om, hvordan man bliver mere strategisk, hvordan man kobler sig til bredere forretningsmål, hvordan man bliver lidt mere tværfunktionel og ikke bare leverer vores projekter isoleret. Og OKR'er er noget, der bliver ved med at dukke op.

Så jeg tænkte, at vi måske kunne begynde med et centralt spørgsmål: Kan du fortælle os, hvad OKR'er er, og hvorfor projektledere og ledere med ansvar for projektleverancer bør interessere sig for dem? Normalt er det en andens problem at definere den slags, og det er forretningsstrategien, som vi ikke altid er koblet på. Men jeg spekulerer på, hvad det betyder for projektledere — hvorfor bør vi interessere os for OKR'er?

Carsten Ley: Ja. Når virksomheder vil arbejde med OKR'er, bliver de automatisk mere tværfunktionelle. OKR'er er derfor et rigtig godt udgangspunkt for at begynde at tale om projektledelse. Desværre gør mange virksomheder det ikke, og jeg skal fortælle dig hvorfor. Normalt har vi en strategi i virksomhederne, og vi har et mål for ét år. Tidligere havde vi under det årlige mål nogle delmålinger, som vi kaldte KPI'er, ikke?

Måske var nogle af dine projektleverancer, milepæle eller inkrementer forbundet med disse årlige KPI'er, ikke? På en eller anden måde, og du blev målt på dem, ikke? Helt ærligt var jeg også projektleder i et PMO. Nogle gange blev jeg bare målt på, hvor mange projekter jeg leverede på et år, men ikke rigtig på hvordan — og selvfølgelig på projektets magiske trekant: omfang og tid.

Budget, men ikke rigtig på målet, kunden eller på at gøre virksomheden tilfreds, vel? Ofte måler vi i projekter kun, hvordan projektet klarer sig, uden virkelig at se på projektets resultat. Det er det, vi gerne vil ændre her. Alle virksomheder har årlige strategiske mål, og med OKR'er vil mange virksomheder sætte tempoet lidt op og kun planlægge for tre eller seks måneder ad gangen.

Og før covid havde vi mange teknologivirksomheder som kunder, fordi metoden kommer fra Google og Intel, og den er meget kendt i teknologi- og kommunikationsmiljøer. Det passer under alle omstændigheder godt sammen med det, vi kalder agil projektledelse, som også er hurtigere med hensyn til sprint og mere accelereret i leveringen af resultater og i kundefokus.

Så det passer rigtig godt sammen med agilitet. Siden covid er vi blevet kontaktet af mange traditionelle virksomheder, der arbejder med OKR'er. Vi har haft medicinalvirksomheder, offentlige kunder og NGO'er som kunder. De siger, at verden er mere omskiftelig, og at organisationer — uanset om de er agile eller ikke-agile — ikke længere kan planlægge 12 måneder frem.

Så de vil dele det op i en planlægning på tre eller seks måneder med OKR'er. Det er det første, OKR'er gør. Du planlægger ikke for 12 måneder, men for tre eller seks måneder, og derefter planlægger du den næste cyklus på tre eller seks måneder, fordi du vil måle kortere resultater for at blive bedre i den næste planlægning.

Det andet, OKR'er gør, er, at vi ud fra strategien og de årlige mål udvikler mål, og ideelt set handler disse mål om forretningen. Målet kan være at øge salget, forbedre effektiviteten, lancere et produkt eller gøre noget andet. Strategien handler om mål, ikke om afdelinger.

Det behøver altså ikke straks at blive opdelt i salg, marketing og drift. Vi anbefaler kraftigt, at man ikke laver OKR'er sådan, at man har sine salgs-OKR'er, sine marketing-OKR'er og sine drifts-OKR'er. Mange virksomheder ønsker det, men vi mener ikke, det er godt, for det, OKR'er gør — og nu kommer vi til strukturen — er, at vi har ét mål, og under ét mål kan vi have flere nøgleresultater.

Det betyder, at hvis jeg gør et mål lidt bredere og siger, at vi vil have succes på markedet eller fordoble vores succes på markedet i år, så får marketing et nøgleresultat, salg får et nøgleresultat, produkt får et nøgleresultat, og leverance får et nøgleresultat. Og de skal alle arbejde sammen, og deres nøgleresultater måles samlet op imod målet.

Det er sådan, man undgår opdeling i siloer, fordi man gør alle fire eller fem afdelinger eller de vigtigste personer, der driver deres nøgleresultater, ansvarlige i forhold til målet. Og her kommer projektledelse selvfølgelig ind i billedet, for projekter har allerede mål. Det er indlysende. Alt det, vi har lært i PMI/PMP om, hvordan man opstiller SMART-mål og den slags, kender du fra PMP-verdenen.

Det er allerede det, vi har brug for til OKR'er. Hvis du har et godt projektmål, så indsæt det i OKR'erne. Det eneste, jeg vil bede dig om, er at justere det til tre eller seks måneder. Jeg vil ikke vide, hvad dit projektmål er efter to år, som i et langsigtet projekt, hvor man siger: Vi vil lancere produktet. Jeg siger: Okay.

Men hvad er dit mål for de næste seks måneder? Har du noget forberedende arbejde? Er du allerede ved at lancere noget mindre? Viser du noget til kunden? Får du nogle godkendelser? Jeg ved det ikke. Du kan dele målet op i seks måneder, så det bliver muligt at gennemføre, ikke? Mindre. Nogle gange har vi projektfaser, så vi tager fase ét eller fase to, og inden for disse tre eller seks måneder vil jeg have noget målbart.

Og nu kommer vi til lidt af magien og problemet for projektfolk. Vi er meget vant til at måle vores opgaver og vores arbejde, ikke? Vi har leverancer og milepæle, som består af 20 opgaver. Når de 20 opgaver er færdige, har vi vores leverance eller milepæl, og det kan vi måle i en OKR. Det kalder vi et input- eller arbejdsnøgleresultat.

Det er det, du skaber som arbejdsinput. Problemet er, at vi i OKR'er også har brug for output-nøgleresultater. Vi vil vide, hvordan projektet hjælper virksomheden, selv i den første fase af projektet, de første tre til seks måneder. Hjælper det allerede virksomheden? For i dag synes jeg ikke, at vi bør låse os fast i to år og derefter levere noget til virksomheden.

Projekter skal levere hurtigere og også have mellemliggende resultater, ikke? Funktionsopdateringer, produktudgivelser eller lanceringer efter tre eller seks måneder. Med denne tankegang måler vi ikke kun, hvad projektet laver. Hvis du for eksempel siger, at du har arbejdet på mange produktprojekter.

Jeg har tidligere arbejdet for banker. Så du laver et nyt produkt, for eksempel et kreditkort eller et underskudsprodukt. Projektteamet siger altid: Jeg har ansvaret for at bygge produktet. Men hvad sker der med produktet bagefter? Det er jeg ligeglad med. Jeg giver det til marketing og salg. Det er præcis det, vi vil undgå med OKR'er.

Så vi siger til projektteamet: I har bygget produktets første funktioner. Vi lancerer dem enten med testkunder eller live. Det afhænger af, hvilken type virksomhed du er — hvis du er en fintechvirksomhed eller en bank, forstår jeg, at en traditionel bank måske ikke kan lancere mindre pakker live. Men i en fintechvirksomhed kan man for eksempel godt. Ellers kan man kun lancere dem til testkunder, og derefter skal projektteamet som minimum indhente feedback fra testkunderne.

Og måle, om de kan lide det eller ej, om det er muligt at gennemføre eller ej, eller om det kan sælges eller ej. Derefter skal de sandsynligvis omarbejde det i næste fase. Det er også grunden til, at projektplanlægningen kun kan være på tre eller seks måneder, for hver gang du får et resultat, skal du teste det med nogen på markedet med hensyn til salgbarhed eller forretningsmæssig effekt.

Og hvis det ikke er tilfældet, skal du måske omarbejde fasen igen.

Galen Low: Det er faktisk virkelig interessant. Din pointe om måling — vi er vant til KPI'er, som vi kan måle med det samme og selv, ikke? Vi spørger: Kom projektet i mål inden for budgettet? Lykkedes det os at blive færdige til tiden? Som du sagde tidligere om PMO'et: Har jeg gennemført det antal projekter, jeg skulle?

Og så måler vi det, og det er nemt, øjeblikkeligt, og der er ingen afhængigheder. Men det, du taler om, og som jeg godt kan lide, er for det første kundefokuseringen, men også den tværfunktionelle tilgang. For med andre ord skulle projektteamet for at opnå et nøgleresultat færdiggøre deres sprint eller deres produktinkrementer, aflevere dem og derefter få marketing og salg til for eksempel at tage dem til en gruppe testkunder, gennemføre lidt research og vende tilbage med resultatet.

Det vil afgøre, om vi opnåede nøgleresultatet. Ikke blot om vi færdiggjorde det.

Carsten Ley: Ja, vi ville faktisk gå et skridt videre. Projektmålet kan have projektnøgleresultater, men også salgs- og marketingnøgleresultater.

Vi behøver faktisk ikke at aflevere det. I dag siger vi, at alle arbejder sammen i projektet eller som en del af det overordnede mål. Jeg giver dig et eksempel fra en kunde, vi havde. De var en startup. Før covid lavede de en fantastisk app til arrangementer, og appen fungerede sådan.

Ved ethvert arrangement får man sandsynligvis tusind, 2.000 eller 3.000 billeder fra et bryllup eller et erhvervsarrangement. I begyndelsen af arrangementet får man et billede af hver deltager, eller man scanner ansigtet på hver deltager, og ud fra disse 3.000, 4.000 eller 5.000 billeder sender appen automatisk de billeder, hvor man selv er med, til én ved arrangementets afslutning.

Det er fantastisk, ikke? Du kender den frustration, når du tager til et arrangement, og de sender dig et link med 800 billeder, som du skal bladre igennem og sige: Hvor er mit billede? Tog de virkelig et billede af mig? Og hvor er jeg? Måske kan du endda finde din forsvundne tvilling på den måde, ikke?

Det er også en sjov funktion. Måske er der nogen, der ligner dig præcis, fordi du pludselig får andre billeder, og det er også sjovt, hvis du forstår, hvad jeg mener. Kundens problem, før vi kom ind i billedet, var, at de havde lavet en app til fotografer. Deres produktteam brugte tre til seks måneder på at udvikle en app til fotografer med meget komplicerede funktioner til billedbehandling og så videre.

Og så kom vi ind, fordi vi også laver lidt rådgivning om kundeoplevelse og brugeroplevelse. De sagde: Nu har vi denne app. Kan I kontakte nogle fotografer og finde ud af, hvordan vi kan markedsføre den? Vi havde mange fotografer i vores fællesskab, fordi vi også arrangerede events, og de sagde: Jeg er fotograf. Jeg betaler ikke for en app, hvor folk kan finde sig selv, og jeg har mine egne programmer på computeren.

Jeg har ikke brug for en app, der hjælper mig med at redigere billeder. Det har jeg allerede. Jeg får betaling for at tage billeder. Jeg får ikke betaling for at distribuere billeder. Det er arrangørens opgave.

Så vi gik tilbage til kunden. Jeg sagde: Jeg ved ikke, hvad der skete i de tre eller seks måneder, før vi kom, men jeres markedsafgrænsning var helt forkert. Vi lavede en undersøgelse med 10 eller 20 fotografer. Ingen ville købe den ting. Samtidig talte vi med mange arrangører, for eksempel par, der skulle giftes, eller virksomheder, og de sagde: Okay, det vil vi sandsynligvis gerne købe.

Så vi gik tilbage til udviklingsteamet og virksomhedens ejer og sagde: De sidste tre eller fire måneder har måske været lidt spildte på jeres udvikling, men nu skal vi skære dette program ned. Alle de komplicerede funktioner til fotografer forstår arrangørerne ikke, og de er ligeglade med dem.

De skal ikke gøre billederne smukkere. Vi skal i stedet lave en app til arrangører, hvor de blot kan uploade billeder og måske få billederne fra deltagerne eller fra ansigtsscanningen og derefter distribuere dem. Jeg ved ikke, hvor mange penge de brugte på udviklingen, men man skal ikke bare udvikle uden markedsundersøgelser og uden virkelig at vide, hvad markedet har brug for.

Du er nødt til at gøre teamet ansvarligt. Udvikleren kan bare sige: Min chef sagde, at jeg skulle udvikle et fotografiprogram. Men så spørger jeg: Hvilket projektteam har I? Hvor er brugeroplevelsespersonen? Hvor er testen efter to eller tre sprints? I behøver ikke en fuldt færdig app endnu.

I skal bare teste og sige: Vi har to grundlæggende funktioner. Har I talt med nogen fotografer? De sagde: Nej, vi har ikke talt med nogen fotografer. Og det er det, OKR'er kan forhindre, hvis man definerer projektmålet ud fra forretningen og ikke ud fra projektmilepæle.

Galen Low: Du nævnte, at OKR'er passer rigtig godt sammen med agilitet, og jeg tror, at nogle af dem, der lytter, måske siger: Men Carsten, vi har ikke brug for OKR'er. Hvis vi har et tværfunktionelt agilt team, er vi kundefokuserede, vi arbejder iterativt, vi bygger inkrementer og viser dem altid til kunden. Hvad gør OKR'er oven i sådan et team? Hvis de allerede får kundeinput undervejs og arbejder tværfunktionelt, føler de, at de har fælles mål. Har de så brug for OKR'er?

Carsten Ley: Ja. På det operationelle niveau klarer de sig meget godt, og det anerkender jeg, men hvordan ser det ud øverst i organisationen med den strategiske sammenhæng? Den første funktion ved OKR'er — og måske gik jeg lidt for hurtigt ind i eksemplet med appen — er, at teams går fra sprint til sprint.

Jeg ved fra min egen erfaring, at mange udviklingsteams har sprintplanlægning med to eller tre sprints fremad. Agile teams planlægger altså typisk tre til seks måneder frem. Det afhænger af, hvor langt et sprint er — to eller fire uger. Så der er en myte om, at agile teams kun planlægger to uger frem.

Det er en myte, fordi de har en funktion, der hedder sprintplanlægning, og den kombinerer planlægningen af sprints. Jeg siger ikke, at I skal lave en masse ekstraarbejde, men I kan kombinere jeres sprintplanlægning for seks uger til tre måneder med OKR'erne og tilpasse den til de strategiske input fra OKR-målene.

Det, jeg altid vil undgå, er, at folk får mere arbejde på grund af en ny metode. OKR'er har en ugentlig eller hver anden uge-baseret opfølgning, hvor vi måler. I har sandsynligvis allerede en sprintgennemgang hver anden uge. Så begynd sprintgennemgangen med OKR'er, begynd med data. Hvis I allerede har data i sprintgennemgangen, så brug den til OKR'erne.

Lad være med at gøre noget andet. Så er I allerede i mål. Desværre ser vi, at nogle sprintgennemgange ikke fokuserer på data. Det er bare lidt snak. Undskyld, at jeg siger det, men vi vil gerne hjælpe dem med at skabe data ved hjælp af OKR'er. Og hvis I har en sprintplanlægning, der går tre til seks måneder frem, bør den hænge sammen med virksomhedens tremånedersmål.

Og hvis de allerede har det, har de så brug for OKR'er? Det ved jeg ikke. Men det giver struktur. Det giver struktur fra strategi til årsmål, til tremånedersmål, til sprintplanlægning og til sprints, så I har klare beviser på, at I med jeres små sprints på to uger faktisk arbejder hen imod strategien. Det kan I dokumentere.

Galen Low: Det er meget tiltalende, for som du nævnte, hører jeg om så mange teams, der er blevet bedt om at bygge noget. De bygger det, og så siger nogen: Ved du hvad, det var ikke det, vi havde brug for. Eller også er det ikke forbundet med forretningsstrategien. For det første er det ikke særlig motiverende for teamet, fordi de tænker: Vi bygger bare ting.

Vi er som en funktionsfabrik for vores produkt. Og for det andet bygger de måske ikke det rigtige, fordi de opstiller deres egne mål i intervaller på to til fire uger uden rigtig at være opmærksomme på eller koblet til de bredere strategiske mål.

Carsten Ley: Der er én ting, jeg gerne vil nævne om motivation.

Vi havde en kunde inden for klimateknologi, en fantastisk kunde. De byggede en app til at måle virksomheders CO2-aftryk. Det er meget meningsfuldt. Men før vi kom med OKR'er, fortalte de udviklerne: I de første seks måneder udvikler vi en app. Og jeg sagde: Det er kedeligt.

Alle startups fortæller deres udviklere, at de bygger en app de første seks måneder. Så hvorfor skulle du være motiveret til at arbejde for en bestemt startup? Jeg forstår godt, hvorfor teknologifolk skifter så meget. Hvis jeg var teknolog og kom til en virksomhed, der sagde: Nu skal du bygge endnu en app efter at have bygget 10 eller 20 apps, ville jeg blive helt uengageret.

Men hvis du fortæller folk i klimateknologivirksomheden: Vi er miljøbevidste. Vi vil have dig til at hjælpe med at bygge en app, som virksomheder kan bruge til at måle deres CO2-aftryk, og du skal gøre det muligt — det er langt mere inspirerende. Det er her, målet kommer ind. Det forplanter sig næsten fra virksomhedens formål eller fra den nordstjerne, man styrer efter.

Galen Low: Det er sjovt, for det får virkelig tingene til at hænge sammen. Man ser børsnoterede virksomheder offentliggøre deres årsrapport eller have den meget højtidelige mission og nogle værdier. Og jeg tror, at mange af dem, der står i skyttegravene og udfører projektet, tænker: Ja, det er det, I fortæller aktionærerne.

Men det, jeg kan lide ved det, du lige sagde, er, at målet forbinder den overordnede mission og strategi med det arbejde, der bliver udført. Det kan bruges til at inspirere folk, fordi det er en håndgribelig vision og ikke bare ord på en side for at gøre aktionærerne tilfredse eller skaffe flere kunder.

Det forudsætter selvfølgelig, at det faktisk er den mission, der er inspirerende.

Carsten Ley: Det er ikke kun inspirerende. Det kan også fungere som beskyttelse for folkene i skyttegravene. Hvis jeg fortæller dig, at vi laver en klimabaseret app, og jeg en dag siger: Nu skal du udvikle et spil, så har jeg magten til at sige: Hvorfor skal jeg gøre det? Jeg kan stille spørgsmål.

Jeg er ikke bare på et lavere niveau, hvor folk siger: Skriv 100 linjer om det. Det er ikke særlig inspirerende på arbejdet. Jeg ved, at jeg skriver denne kode eller programmerer disse funktioner til en klimabaseret løsning til sporing. Jeg kan også udfordre mine chefer lidt. Hvis de siger: Nu skal du udvikle en app til at få kuponer fra McDonald's, som måske ikke er særlig klimavenlig, kan det give bagslag.

Galen Low: Jeg spekulerer på, om du kan fortælle mig om processen, for i teorien er jeg vild med det. Det var ikke tilsigtet med McDonald's-eksemplet, men jeg synes faktisk, det er en interessant idé, der binder det hele sammen.

Som du sagde, tilfører det ikke nødvendigvis mere arbejde, men snarere mere struktur. Mange af de projektledere og PMO'er, jeg taler med, er ikke rigtig involveret i forretningsstrategien. Hvad er nogle eksempler på OKR'er, og hvordan kan man nå frem til dem på en måde, der også er tværfunktionel? Eller bliver de altid bare givet videre ovenfra?

Carsten Ley: Lad os blive ved klimateknologisagen. Virksomheden havde lige fået finansiering. De sagde, at de inden for ét år skulle have denne CO2-aftryksapp klar. Samtidig skulle de programmere appen, finde partnere og skaffe mere finansiering.

Alle de ting og alle de mål, man har i en startup, og man skal også onboarde folk — alle målene. Startups har deres første år, og i en startup er det allerede en strategi på et eller to år, fordi man ikke ved, hvor længe man er der. Man behøver ikke planlægge fem år frem, hvis man lige har fået finansiering. Det er strategien.

Derefter forplanter den sig til årlige mål, som teamlederen måske kender. Som minimum bør teamlederen og stifterne sætte sig sammen og sige: Hvad vil vi opnå næste år? Som et udkast, fordi vi lever i en omskiftelig verden, så det er måske et estimat. Og ud fra det planlægger vi tremånedersmål.

Vi siger for eksempel, at vi i første kvartal vil have en prototype af appen. Dette mål, som sandsynligvis fastlægges mellem stifterne og teamlederne — endnu ikke teamet — er, at vi vil have en prototype i de første tre måneder. Nu går jeg ind i prototypeprojektet, som ikke kun består af udviklingsteamet.

Ideelt set bygger jeg det som et projekt sammen med folk fra markedet og salgsfolk, hvor vi får potentielle kunder eller partnere til at teste det. Derefter spørger jeg mit team og afholder en workshop: Hvad kan være de målbare nøgleresultater for de næste tre måneder? Det er altså ikke en top-down-proces.

Det er også den smukke del, og det hænger lidt sammen med det, de normalt gør i agilitet og sprintarbejde, hvor de involverer teamet. Så siger vi: Hvad vil vi opnå? Et mål. Vi ved, at vi vil bygge en prototype. Hvordan måler vi, om vi har bygget en prototype med succes? Så finder man frem til forskellige nøgleresultater.

Det første nøgleresultat handler sandsynligvis om kodning og udvikling af en prototype med trådrammer. Et andet nøgleresultat kan være, at man tester prototypen med et bestemt antal personer og får en bestemt type feedback. Man kan også måle, om man efter de første tre måneder finder ud af, hvilke funktioner der mangler, så man kan arbejde på dem i de næste tre måneder.

Den slags kan være nøgleresultater, og så har teamet sine mål for de tre måneder: en inspirerende prototype til klimateknologi plus nøgleresultater til at måle den. Derefter kan de begynde sprintplanen. De kan sige: Hvilke af disse ting — for OKR'en er som jeres backlog, som jeres overordnede mål-backlog — tager vi med i de første to eller tre sprints?

Det er sådan, processen fungerer. Jeg synes ikke, vi skal lægge mere og mere arbejde oven på. Vi lægger lidt mere arbejde på teamlederne, fordi vi ønsker, at teamlederne fra hvert team eller projektlederne i det mindste skal deltage i årsplanlægningen.

Vi behøver ikke at gøre det til en strategisk øvelse, men de skal som minimum være involveret i årsplanlægningen. Selv i større virksomheder gør vi det sådan, at afdelingsledere, projektledere og PMO-ledere i det mindste deltager i drøftelsen af årsplanen.

Galen Low: Jeg kan godt lide, at du involverer dem. Hvis jeg forstår dig korrekt, vil din anbefaling være, at man bringer teamlederne til bordet i den årlige planlægning, hvis man finder en organisation, der ikke gør det.

Carsten Ley: Ja. Det, vi altid ønsker i OKR-processen, er, at man i nogle virksomheder har to eller tre niveauer af OKR'er. Man har virksomheds-OKR'er, og desværre vil man så have siloer med afdelings-OKR'er, hvilket vi ikke er tilhængere af, men vi kan bygge det for dem. Vi har arbejdet med meget traditionelle virksomheder, der ønsker det sådan.

Det forstår jeg selvfølgelig. Og hvis de bygger afdelings-OKR'er, er det nemmere for dem at tildele ansvaret, fordi de gør det som i organisationsdiagrammet. Det er ikke særlig agilt, men sådan fungerer magtstrukturerne i virksomheder. Så i nogle virksomheder har vi virksomheds-OKR'er, afdelings-OKR'er og team-OKR'er, og vi vil altid have to lag til at arbejde sammen.

Virksomheds-OKR'er er de øverste personer sammen med afdelingslederne. Afdelings-OKR'er er afdelingslederne sammen med teamlederne. Team-OKR'er er teamlederne sammen med teamet. Det skaber lidt gennemsigtighed, hvilket er et vigtigt ord i forbindelse med OKR-sammenhæng, og det giver også input nedefra.

Bottom-up betyder ikke, at man, når man taler om strategi i virksomhedens øverste ledelse, spørger rengøringspersonalet om input. Det er selvfølgelig ikke bottom-up. Det er ikke så ekstremt. Det betyder, at man som minimum inddrager det næste lag.

Agile virksomheder. Vi havde en meget interessant kunde i USA, der hed Scratch Pay eller Scratch Finance. De var en fintechvirksomhed og derefter en SaaS-virksomhed. Jeg tror, at de nu igen er en fintechvirksomhed, fordi de skifter lidt mellem forretningsmodeller.

De havde 150 medarbejdere, hovedsageligt udviklere, over hele verden, mens marketing- og salgsteamet var i Californien i Silicon Valley. De ville gerne være meget bottom-up. De øverste stiftere og ledere udarbejdede et udkast til strategien og de årlige mål, og derefter sendte vi en undersøgelse ud til de 150 personer verden over og bad om feedback på strategien eller de årlige mål.

Det er fantastisk. Det kan man også gøre, hvis man ønsker ægte bottom-up. Man kan lave en undersøgelse. Jeg lover, at ikke særlig mange svarer, helt ærligt. Nogle udviklere vil også sige: Jeg vil ikke involveres i strategien. Hvorfor skulle de det? De bliver måske ikke betalt for det.

Men nogle vil gerne. Så man giver dem mulighed for at give feedback. Vi fik en meget interessant feedback, måske lidt moderne. De havde et mål for virksomheden, der handlede om at knuse konkurrenten eller noget i den stil, og en kvindelig teamleder skrev i undersøgelsen: Lad os ikke bruge så aggressivt et sprog her.

Det var en rigtig god feedback. Nogle mennesker følte sig ikke godt tilpas i virksomheden med al den aggressive retorik fra stifterne, hvor man hele tiden talte om at udslette konkurrenterne. Det er ikke nødvendigt. Det var en god feedback, der hjalp med at tone det lidt ned, så folk kunne identificere sig med det.

Som jeg sagde, hvis vi bygger OKR'er på forskellige niveauer, kommer det næste lag altid med. Hvis man bygger PMO-OKR'er, bør projektlederne være med. Og når vi bygger dem for projekterne, bør projektet og projektteamet gøre det sammen.

Galen Low: Jeg kan godt lide den idé overordnet set.

Mine tanker går næsten i retning af uddannelse. Jeg har arbejdet i mange organisationer, der bad om feedback, men når feedbacken kom tilbage, sagde de: De forstår det ikke.

Så tænker jeg: Hvis jeg var en person, der svarede på en undersøgelse, eller en person på et team, eller en teamleder, der skulle få mit team til at finde nøgleresultater, men de ikke helt forstod det, så ville jeg måske føle, at deres nøgleresultater ikke passede til målet, eller at de ikke var målbare nok.

Hvordan giver man uddannelse i hele organisationen, så folk forstår, hvad et godt nøgleresultat er? Og så ledere ved, at feedbacken fra teamet ikke bare er tilfældige ting, de kan ignorere, men at alle faktisk forstår det, forstår rammen og strukturen og har tilstrækkelig uddannelse eller træning til at give meningsfuldt input, så inputtet bliver taget alvorligt? Går man ind og træner folk i OKR'er, eller skal de på en måde selv forstå det?

Carsten Ley: Normalt tilbyder vi træning på forskellige niveauer, når vi begynder at arbejde med en virksomhed, der ikke har arbejdet med OKR'er før. Vi gør det også på leveranceniveau, fordi OKR-træningen også handler om at skabe opbakning.

Som du sagde før, vil nogle projektledere og PMO'er ikke arbejde med OKR'er, fordi de tror, at agilitet allerede dækker det hele. Måske kan vi i træningen vise, at det ikke er fuldt dækket. Der er to eller tre ting, de ikke behøver at ændre hele deres proces for, men de kan gøre lidt mere, især med hensyn til resultatet og den forretningsorienterede side.

Vi og selvfølgelig mange andre OKR-udbydere har en klar struktur for, hvordan man bygger et inspirerende mål, der bør være forbundet med strategien. Der bør altid være et hvorfor: Hvorfor gør vi det? Hvorfor bygger vi en app? Ikke fordi vi bare er en startup, der bygger en app, men fordi der er et formål bag, og ideelt set et godt formål, der inspirerer folk.

Og med hensyn til nøgleresultater kan vi som sagt måle arbejdet med nøgleresultater, som næsten er som en KPI. Hvor mange projekter gennemførte du? Hvor mange funktioner udviklede du? Men det er ikke de rigtigt gode nøgleresultater. Det rigtigt gode nøgleresultat handler om effekten af vores arbejde. Kan testkunden lide funktionerne?

Blev nogle af de fem projekter, jeg gennemførte i år, lanceret og tjente penge til virksomheden? Det er måske et godt spørgsmål. Det er det, vi bør måle. Det, vi ud over struktur og opsætning uddanner folk i, er tankegangen: Jeg er ikke kun ansvarlig for mit lille område, hvor jeg får 400 linjer kode.

Jeg er også ansvarlig for, hvordan denne kode påvirker produktet, og om produktet sælger. Der er nogle gange lidt modstand. Det er forandringsledelse. Man får altid modstand, når folk siger: Jeg er bare udvikler. Jeg er ikke ansvarlig for, hvordan produktet klarer sig.

Det er lidt den ånd, vi skal skabe i virksomheden. Derfor vil vi ikke opdele salg, marketing og produkt i siloer. Det er faktisk projektets kerne, ikke? At bringe mennesker sammen, at bringe en udvikler sammen med en brugeroplevelsesperson og en sælger og sige: Vi er fælles om det her.

Det er ikke sådan, at alle sidder i projektmødet og er ligeglade med de andre dele.

Galen Low: Det interessante ved siloer er, at de føles trygge, fordi man kender folkene i sin silo, og man opbygger tillid omkring at nå et mål sammen. Men så snart man træder ud af siloen, tænker man: Jeg ved ikke, om jeg kan stole på de her mennesker.

Det er interessant, at du nævner forandringsledelse, for det, jeg tænkte på, var denne kulturændring, hvis man kommer fra en teamkultur, der ikke gjorde det her, og som var mere opdelt i siloer. Måske effektiv, men sandsynligvis også kulturelt opdelt. Og så bevæger man sig over i en mere tværfunktionel model på tværs af afdelinger.

Oplever du, at det skaber lidt mere konflikt, når man går i gang?

Carsten Ley: Vi ser kun konflikter på afdelingsniveau, hvis nogle af lederne forsøger at dominere. Mellemledelsen kan være lidt af et problem. Når de vil bygge deres små kongedømmer, som jeg kalder det, og siger: Nej, jeg vil ikke have, at produktet blander sig i mine salgs-KPI'er.

Det er kun mine tal. De vil ikke dele succesen med deres tal på teamniveau. Vi ser ikke så mange problemer på teamniveau, fordi vi i en OKR-struktur måler i et system, hvor alle normalt kan se tallene fra de forskellige teams. Der findes også tusindvis af OKR-værktøjer på markedet.

Vi har ikke vores eget, fordi der er så mange. Der findes OKR-værktøjer til Jira, Microsoft og alt muligt andet. I dag har næsten alt en integration til OKR'er. Så vi kan virkelig følge tallene. Hvis alle tjekker ind hver anden uge efter en sprintgennemgang på et teammøde og indtaster tallene eller beskriver, hvordan arbejdet går, og hvordan det påvirker forretningen eller resultaterne, kan vi måle det og vise det meget gennemsigtigt.

Så jeg tror ikke, der er mange konflikter, fordi folk er bange. De bliver måske lidt mere bekymrede, når de siger, at de ikke kan påvirke noget, og det er rigtigt. Men der er også én ting, vi bør nævne: OKR'er er ikke præstationsmål som KPI'er. Vi har også noget, der kaldes et ambitiøst nøgleresultat, hvor man måske sigter efter mellem 70 og 100 procent.

Der er altså også plads til, at man ikke rammer 100 procent, uden at man straks bliver straffet i sin bonus. Hvis man gør det, og det samme gælder i agil ledelse, bliver folk bange for at arbejde tværfunktionelt sammen og for at være modige og prøve ting af.

Det er det, vi ønsker i OKR'er og agilitet: at folk prøver ting af, og at de har idéer i projektet. Det lukker man fuldstændigt ned for, hvis man kobler en bonusbaseret præstationsmåling på. Det er meget vigtigt kulturelt, at man giver folk plads.

Vi siger altid, at der også er et trick, som fungerer rigtig godt. De første tre måneder med OKR'er i en virksomhed kalder vi altid en OKR-pilot. Enten gør vi det på ledelsesniveau for at skabe opbakning, eller også gør vi det i et enkelt team for at teste det. Hvis man siger pilot, kan folk stadig håbe, at det forsvinder, selv om det selvfølgelig ikke gør det. Det lyder stadig, som om det kan forsvinde.

Det forsvinder normalt ikke, men det kan forsvinde. For det andet lyder pilot også, som om vi kan påvirke tingene, og at det endnu ikke er så alvorligt. Lad os lege lidt med det. Så vi siger altid til vores kunder: Hvorfor ikke starte med en OKR-pilot? Og så fortæller I medarbejderne: Vi prøver OKR'er først. Jeg ved, at de fleste virksomheder allerede har besluttet sig for at indføre dem.

Det forsvinder ikke, men i det mindste kan man gøre overgangen lidt lettere i begyndelsen.

Galen Low: Det kan jeg godt lide. Som du siger, bruger nogle det som en mulighed for at indsamle input. Måske har de allerede besluttet sig for at gøre det, men de indsamler i det mindste input og feedback om, hvordan de skal gøre det. Det synes jeg faktisk er meget interessant.

For at spille lidt djævlens advokat ved jeg, at nogle siger, at OKR'er er ved at gå af mode. Det var bare en dille eller trend, som organisationer kastede sig over, og nu undgår mange dem. Men som du også siger, er der en masse organisationer, der endnu ikke er begyndt at bruge dem.

Hvordan kan teams af projektledere — eller teams generelt — argumentere for at bruge OKR'er til deres projekter og deres samarbejde, hvis ledelsen måske ikke er med på idéen eller trækker fødderne efter sig? De bliver ved med at sige, at de vil gøre det, men de gør det ikke endnu.

Kan et team på teamniveau argumentere for at gennemføre denne ændring?

Carsten Ley: Man kan nogle gange køre OKR'er på teamniveau som en pilot. Hvis ledelsen ikke følger piloten, starter vi med ét team. Vi kigger selvfølgelig efter et mere agilt team, for eksempel et produktteam, hvor det fungerer godt.

Hvis man har et projektteam eller endda et funktionelt team, er det eneste, teamet skal gøre, at bruge de KPI'er eller nøgleresultater, som de allerede måler, ikke? Det er ikke noget nyt. Man er nødt til at måle noget. I dag er der et dataark, eller man bruger et system som Microsoft Planner, Monday.com eller noget tilsvarende.

Alle bruger den slags. Hvis ikke, bruger de Excel. Men man skal rapportere hver uge, hver anden uge eller mindst én gang om måneden om, hvad man laver, om det går godt eller ej, og måske producere nogle tal. Det er ikke raketvidenskab. Så vi bruger disse tal som nøgleresultater og tilføjer, som jeg sagde, nogle mere forretningsorienterede nøgleresultater, der rækker lidt ud over teamet eller handler om effekten efter projektets afslutning.

På den måde skal man altid stille sig selv det rigtige spørgsmål. Hvorfor laver vi dette projekt? Hvorfor lancerer vi dette produkt? Som projektleder og projektteam får vi selvfølgelig betaling for at lancere produktet og derefter aflevere det til drift og salg. Men hvis man vil leve efter OKR'er, spørger man: Hvorfor lancerer vi produktet?

Jeg spørger salg, og salg siger: Vi forventer at tjene mindst 10.000 i de første måneder. Så ville jeg skrive det ind i mit projekt og lave en fase efter implementeringen. Jeg ville sige: Lad os sammen med salg tage ansvar for de første to måneder efter implementeringen. Vi vil mindst opnå 10.000 dollar om måneden.

Og selvfølgelig siger projektteamet: Det afhænger ikke kun af os, men også af salg. Men vi arbejder sammen med salg. Vi tager dem med ind i projektet, hvilket også er sjovt, fordi man lærer noget af salg. Salg kan så give feedback allerede i de første uger: Kunden kan ikke lide denne funktion. Det er præcis det, man ønsker. Man vil ikke længere bare afslutte projektet.

Og hvis man ønsker at være langsigtet medarbejder og tale om medarbejderengagement, vil man ikke bare afslutte projekter. Man vil se, at ens projekter har en effekt på virksomheden — eller, hvis vi taler om klimateknologi, måske endda på samfundet.

Hvis vi tager det et skridt videre, kan man begynde med det i ethvert team, også et operationelt eller funktionelt team, fordi teamlederen bør kende målene og den langsigtede planlægning. Hvis ikke, skal man som teamleder være modig nok til at gå til sine chefer og stille disse spørgsmål, fordi man har ret til at kende projektmålet.

Projektmålet er at lancere et produkt. Så jeg går til mine PMO-kolleger og siger: Hvorfor skal vi lancere dette produkt? Hvordan hænger det sammen med strategien? Forhåbentlig fortæller de, at det hænger sammen med strategien, og ikke at de bare prøver noget mærkeligt, som ingen rigtig interesserer sig for. Det ville være meget demotiverende.

Med informationen ovenfra kan man nemt bygge sit mål, og med det, man allerede måler, har man sine første nøgleresultater, der måler projektets succes. Derefter skal man også måle forretningseffekten og se, om teamet ønsker at gøre det.

Jeg siger ikke, at alle skal bruge OKR'er. Nogle virksomheder har det fint med at sige: Lad projektfolkene gennemføre deres projekt og aflevere det til salg og drift. Vi vil ikke besvære jer med mere. Det er helt fint for mig. Men prøv det med et team og se, hvordan folk reagerer, og om de er interesserede.

Galen Low: Det er interessant. Jeg kan godt lide den bottom-up-baserede, græsrodsorienterede samarbejdstilgang. Det er: Lad os tale med salg og se, hvad deres mål er, og så måle det. Selvom vores projekt teknisk set, eller vores sprint, inkrement eller release, er afsluttet, er vi stadig interesserede i, hvad det gør efterfølgende uden for vores team.

Vi kommer sandsynligvis fortsat til at arbejde på det. Der er en form for kontinuitet og lang levetid i missionen, som er knyttet til virksomheden og ikke kun til dette ene projekt eller sprint.

Carsten Ley: Når vi gør det, sker forbedringer efter en projektfase normalt på en god og samarbejdsorienteret måde.

Det, der normalt sker, især i en PMI-sammenhæng, er, at man laver et hårdt snit ved projektets afslutning og afleverer det. Da jeg arbejdede i banker, var vi kun projektteamet, og derefter afleverede vi det. Vi opfyldte alle milepæle og leverancer. Men måske havde nogen givet os de forkerte oplysninger allerede i begyndelsen af projektet.

Eller måske skiftede salgslederen fra begyndelsen til slutningen af projektet. Så afleverer man det til den nye salgsleder. Efter to måneder går de til ens chefer og eskalerer problemet voldsomt, og man får en masse problemer, og alle konflikterne begynder. Det er ikke en særlig god måde at arbejde sammen på. Hvis tingene ikke lykkes, vil projektets resultat før eller siden give projektteamet problemer.

Galen Low: Det er en interessant måde at se på det.

Carsten Ley: Hvorfor ikke forebygge det mere proaktivt og arbejde sammen med de rigtige mennesker allerede under projektet eller i forbindelse med overdragelsen for at sikre, at det bliver en succes?

Galen Low: Det kan jeg godt lide.

Du nævnte én sidste ting, som jeg tænkte, at jeg ville slutte med, fordi vi har talt om top-down på ledelsesniveau og om bottom-up. Et projektteam er måske bare nysgerrigt efter at prøve det. Måske er det en teampiloten. Du nævnte PMO'er, som ligger midt imellem, og tidligere sagde du, at selv da du drev et PMO, handlede jeres målinger nogle gange bare om, hvorvidt I havde gennemført det rigtige antal projekter. Men det virker, som om OKR'er kunne være en god mulighed for PMO'er, der ikke rigtig sidder med ved bordet, til at blive mere strategiske.

Måske er det et helt andet afsnit, men jeg tænkte på, hvordan PMO'er kan bruge OKR'er til at blive forbundet med forretningen, så de ikke bare bliver en projektfabrik.

Carsten Ley: PMO'er bør være en del af den strategiske drøftelse eller i det mindste af årsplanlægningen.

Det er det første, vi skal sikre. Derefter kan PMO'er ligesom afdelinger have OKR'er og forretnings-OKR'er. Ikke kun projekt-OKR'er. Man skal ikke kun tale om antallet af projekter, hvor mange projektledere man skal ansætte, eller hvor mange projekter man skal etablere. Man kan allerede her koble PMO'et på og sige: Hvad er målet for året?

Et årligt mål kan være en produktlancering. Et andet kan være en markedsintroduktion. Et tredje kan være effektivitet. Så kan PMO'et brainstorme og sige: Hvilke projekter kan vi foreslå bottom-up eller fra midten som PMO for at lancere produkter, erobre markedet eller gøre virksomheden mere effektiv?

Især når man taler om effektivitet, kommer de bedste forslag ofte fra teams eller projektledere. De kommer ikke nødvendigvis ovenfra. Ledelsen ved ofte ikke så meget om, hvad der foregår længere nede. Men du forstår, hvad jeg mener.

PMO'et er en meget tværfunktionel afdeling, der også har en styringsfunktion. Da jeg senere drev et PMO i en fintechvirksomhed efter banken, brugte vi PMO'et meget til undersøgelser. Vi undersøgte teammedlemmer fra forskellige teams om deres krav, og hvad de havde brug for fra projekter eller lanceringer.

Vi spurgte ikke altid kun de oplagte teamledere om deres krav og input. Vi spurgte flere mennesker. Vi drev også PMO'et. Nogle gange kan PMO'et gøre mere, og det kan vi tale om i en anden episode. Vi havde en forslagskasse i PMO'et. PMO'et havde virksomhedens digitale forslagskasse, ikke? Alle kunne komme fra hvor som helst og sige: Jeg har en idé til et projekt, fordi det her ikke fungerer særlig godt.

Vi havde også et lille budget til at belønne det, hvis forslaget blev taget op, og vi skabte et vellykket projekt ud af det. PMO'et kan med denne tværfunktionelle styrke gøre meget. Folk har tillid til PMO'et. Vi driver ikke politik. Vi er meget neutrale i OKR-processen. At være en del af den strategiske årsplanlægning, komme med forslag og koordinere processen til sidst er fantastisk.

Galen Low: Jeg elsker den idé, og jeg vil helt sikkert gerne dykke mere ned i den. Vi laver en anden episode om OKR'er for PMO'er. Det lyder virkelig interessant.

Carsten Ley: Det bliver fantastisk. Ja.

Galen Low: Det kan jeg godt lide. Carsten, tusind tak, fordi du tog dig tid til at være med i dag. Jeg har haft det rigtig sjovt. Jeg har lært en masse. Det har været fantastisk.

Carsten Ley: Mange tak. Det var en fornøjelse at være her. Tak, Galen.

Galen Low: Sådan, folkens. Så har I det. Som altid: Hvis du vil deltage i samtalen med over tusind ligesindede forkæmpere for projektledelse, så kom med i vores fællesskab! Gå over på thedpm.com/membership for at læse mere. Og 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.