Slik bruker du OKR-er i prosjektet ditt for å forsterke forretningspåvirkningen

Les transkripsjonen:

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

Galen Low: Det har vært en lang dag, og det føles som om prosjektet du jobber med, ikke er i nærheten av målet sitt. Teamet føler at oppdraget bare er å bygge en app for å bygge en app, uten noe særlig mer å gå ut fra. Du er klar til å lukke PC-en for dagen, men tenker at du kanskje bør gå tilbake til resultatene fra strategiarbeidet for å få litt inspirasjon.

Kanskje er det bare slik at du og teamet ditt er for tett på prosjektet og ikke ser skogen for bare trær. Med den siste energien du har igjen, henter du frem noen av de mer strategiske dokumentene dere fikk – bare for å friske opp visjonen og målet for prosjektet. Og der står det, så tydelig som dagen. Det store strategiske målet for året var ... «å bygge en app».

Hvis du sliter med å koble prosjektmålene dine til strategiske forretningsmål, og omvendt, bør du fortsette å lytte. Vi skal utforske hvordan OKR-er – mål og nøkkelresultater – kan gi prosjektene dine et rammeverk for å skape samordning, måle påvirkning og motivere teamene dine mot den større forretningsstrategien.

Hei alle sammen, og takk for at dere lytter. Jeg heter Galen Low og kommer fra The Digital Project Manager. Vi er et fellesskap av digitale fagfolk med et mål om å hjelpe hverandre med å utvikle ferdigheter, bli tryggere og knytte kontakter, slik at vi kan forsterke verdien av prosjektledelse i en digital verden. Hvis du vil høre mer om dette, kan du gå til thedpm.com/membership. Og hvis du liker fremtidsrettede samtaler og praktiske innsikter om ledelse av digitale prosjekter, kan du abonnere på dette programmet for ukentlige episoder.

I dag snakker vi om hvordan man kan knytte prosjektleveranser til bredere organisatoriske mål ved å innarbeide mål og nøkkelresultater – også omtalt som OKR-er – i prosjektlederarbeidet.

Med meg i dag har jeg Carsten Ley – prosjektledelseskonsulent, OKR-coach og medgrunnlegger av både Asia PMO og OKR Asia.

Carsten, takk for at du er med meg i dag.

Carsten Ley: Takk, Galen, for at jeg fikk komme.

Galen Low: Jeg gleder meg veldig til å gå inn i dette, for jeg må innrømme at dette er et område jeg ikke kan så mye om, så jeg kommer også til å lære sammen med noen av lytterne mine. Jeg synes det er et svært interessant tema. I fellesskapet mitt har vi snakket mye om hvordan man kan bli mer strategisk, knytte seg til bredere forretningsmål, bli mer tverrfunksjonell og ikke bare levere prosjektene våre isolert. Og OKR-er er noe som stadig kommer opp.

Så jeg tenkte at vi kanskje kunne begynne med et grunnleggende spørsmål: Kan du fortelle oss hva OKR-er er, og hvorfor prosjektledere og ledere for prosjektleveranser bør bry seg om dem? Vanligvis er dette andres ansvar å definere, og det er forretningsstrategien vi ikke alltid er koblet på. Men hva er egentlig nytten for prosjektledere, og hvorfor bør vi bry oss om OKR-er?

Carsten Ley: Ja. Når selskaper ønsker å ta i bruk OKR-er, må de automatisk bli mer tverrfunksjonelle. Derfor er OKR-er et svært godt utgangspunkt for å begynne å snakke om prosjektledelse. Dessverre gjør mange selskaper ikke dette, og jeg skal fortelle deg hvorfor. Vanligvis har vi en strategi i selskaper, med et ettårsmål, og under ettårsmålet hadde vi tidligere delmål som vi kalte KPI-er, ikke sant?

Kanskje noen av prosjektleveransene, milepælene eller inkrementene dine var knyttet til disse årlige KPI-ene. På en eller annen måte ble du målt på dette. For å si det rett ut var jeg også prosjektleder i et PMO. Noen ganger ble jeg bare målt på hvor mange prosjekter jeg leverte i løpet av et år, men ikke egentlig på hvordan prosjektets magiske trekant fungerte når det gjaldt omfang, tid og budsjett – og heller ikke på målet, kunden eller om virksomheten ble fornøyd.

I prosjekter måler vi ofte bare hvordan prosjektet presterer, uten å se på om prosjektets resultat faktisk har ønsket effekt. Det er dette vi ønsker å endre. Alle selskaper har strategiske ettårsmål, men med OKR-er ønsker mange selskaper å øke tempoet litt og bare planlegge for tre eller seks måneder om gangen.

Før covid hadde vi mange teknologiselskaper som kunder, fordi OKR-er kommer fra Google og Intel og er svært kjent i teknologi- og kommunikasjonsmiljøer. Dette passer godt med det vi kaller smidig prosjektledelse, som også handler om raskere sprinter, raskere leveranser av resultater og større kundefokus.

Det passer derfor svært godt sammen med smidig arbeidsmetodikk. Etter covid har mange tradisjonelle selskaper tatt kontakt fordi de ønsker å bruke OKR-er. Vi har hatt kunder innen legemiddelindustrien, offentlig sektor og frivillige organisasjoner. Verden er mer ustabil, og virksomheter – enten de arbeider smidig eller ikke – kan ikke lenger planlegge tolv måneder frem i tid.

Derfor ønsker de å dele planleggingen opp i perioder på tre eller seks måneder ved hjelp av OKR-er. Det er det første OKR-er gjør. Du planlegger ikke for tolv måneder, men for tre eller seks måneder. Deretter planlegger du neste syklus på tre eller seks måneder, fordi du ønsker å måle kortere resultater for å bli bedre i neste planleggingsrunde.

Det andre OKR-er gjør, er at vi ut fra strategien og de årlige målene utvikler mål, og disse målene bør ideelt sett handle om virksomheten. Et mål kan være å øke salget, forbedre effektiviteten, lansere et produkt eller gjøre noe annet. Målene bør være overordnede temaer og ikke umiddelbart deles inn i salg, markedsføring og drift.

Derfor anbefaler vi sterkt at man ikke lager OKR-er som «våre salgs-OKR-er», «våre markedsførings-OKR-er» og «våre drifts-OKR-er». Mange selskaper ønsker dette, men vi mener ikke at det er en god idé, fordi OKR-er består av ett mål, og under dette målet kan vi ha flere nøkkelresultater.

Hvis jeg gjør målet litt bredere og sier at vi ønsker å lykkes i markedet eller doble suksessen vår i markedet i år, får markedsføring ett nøkkelresultat, salg får ett, produkt får ett og levering får ett. Alle må samarbeide, og nøkkelresultatene måles samlet opp mot målet.

Slik unngår du siloer. Du gjør fire eller fem avdelinger, eller de viktigste personene som har ansvar for nøkkelresultatene, ansvarlige overfor det samme målet. Det er selvfølgelig her prosjektledelse kommer inn, fordi prosjekter allerede har mål. Dette er enkelt å forstå. Det vi lærte i PMI- og PMP-sammenheng om hvordan man lager gode, konkrete mål, er allerede det vi trenger for OKR-er.

Hvis du har et godt prosjektmål, kan du legge det inn i OKR-ene. Det eneste jeg vil be deg om, er å bryte det ned til tre eller seks måneder. Jeg vil ikke vite prosjektmålet ditt etter to år, slik som i et langsiktig prosjekt der man sier: «Vi vil lansere produktet.» Greit. Men hva er målet ditt de neste seks månedene? Har du forberedende arbeid? Lanserer du allerede noe lite? Viser du noe til kunden? Får du noen godkjenninger? Jeg vet ikke. Du kan bryte målet ned til seks måneder, og da blir det gjennomførbart og mindre.

Noen ganger har vi prosjektfaser, og da tar vi bare fase én eller fase to. Innenfor disse tre eller seks månedene ønsker jeg at resultatene skal være målbare.

Her kommer litt av magien – og problemet – for prosjektfolk. Vi er vant til å måle oppgaver og tingene våre. Vi har leveranser og milepæler som består av 20 oppgaver. Når de 20 oppgavene er ferdige, har vi leveransen eller milepælen, og den kan vi måle i en OKR. Dette kaller vi et input- eller arbeidsnøkkelresultat.

Det er det du skaper som arbeidsinput. Problemet er at vi i OKR-er også trenger nøkkelresultater for output. Vi vil vite hvordan prosjektet vil hjelpe virksomheten, selv i prosjektets første fase og i løpet av de første tre til seks månedene. Hjelper det allerede virksomheten?

I dag mener jeg ikke at vi bør låse oss til to år og først da levere noe til virksomheten. Prosjekter må levere raskere og også skape mellomliggende resultater, for eksempel funksjonsoppdateringer, produktlanseringer eller andre lanseringer etter tre eller seks måneder.

Med denne tankegangen måler vi ikke bare hva prosjektet gjør. Hvis du for eksempel sier at du har jobbet med mange produktprosjekter, og at prosjektteamet har fått ansvar for å bygge et nytt kredittkort- eller innskuddsprodukt, kan teamet si: «Jeg har ansvar for å bygge produktet.» Men hva skjer med produktet etterpå? «Det bryr jeg meg ikke om. Jeg gir det videre til markedsføring og salg.» Det er akkurat dette vi ønsker å unngå med OKR-er.

Vi sier til prosjektteamet: Dere har bygget de første funksjonene i produktet. Vi lanserer dem enten med testkunder eller direkte, avhengig av om dere er et finansteknologiselskap eller en bank. I en tradisjonell bank kan man kanskje ikke lansere små pakker direkte, men i et finansteknologiselskap kan man for eksempel gjøre det. Alternativt kan man lansere dem for testkunder. Deretter må prosjektteamet få tilbakemeldinger fra testkundene.

Mål om de liker det eller ikke, om det er gjennomførbart eller ikke, og om det kan selges eller ikke. Deretter må dere sannsynligvis bearbeide løsningen i neste fase. Derfor kan prosjektplanleggingen også bare være på tre eller seks måneder: Når du får et resultat, må du teste det med noen i markedet for å se om det kan brukes og hvilken forretningspåvirkning det har.

Hvis dette ikke fungerer, må du kanskje bearbeide fasen på nytt.

Galen Low: Det er faktisk veldig interessant. Du snakker om måling, og vi er vant til KPI-er som vi kan måle umiddelbart og på egen hånd. Vi spør om prosjektet holdt budsjettet, om vi klarte å bli ferdige i tide, eller om vi leverte det antallet prosjekter PMO-et forventet.

Vi måler det, og det er enkelt og umiddelbart, uten avhengigheter. Men det du snakker om, liker jeg: For det første kundefokuset, og for det andre den tverrfunksjonelle arbeidsformen. For å oppnå et nøkkelresultat i dette scenariet må prosjektteamet fullføre sprinten eller produktinkrementene sine, overlevere dem og deretter få markedsføring og salg til å ta dem til en gruppe testkunder, gjennomføre undersøkelser og komme tilbake med resultatet. Det avgjør om vi oppnådde nøkkelresultatet – ikke bare om vi fullførte arbeidet.

Carsten Ley: Ja, vi går faktisk enda et skritt videre. Prosjektmålet kan ha prosjektets nøkkelresultater, men også nøkkelresultater for salg og markedsføring.

Vi trenger ikke engang å overlevere det. I dag sier vi at alle arbeider sammen i prosjektet eller som en del av det overordnede målet. Jeg kan gi deg et eksempel fra en kunde. De var en oppstartsbedrift som før covid hadde laget en fantastisk app for arrangementer.

På et arrangement kan du få tusen, to tusen eller tre tusen bilder fra et bryllup eller et forretningsarrangement. I begynnelsen av arrangementet får du et bilde av hver deltaker, eller du skanner ansiktet til hver deltaker. Deretter sender appen automatisk bildene der du er avbildet, til deg når arrangementet er over.

Det er fantastisk. Du kjenner smerten når du er på et arrangement og får en lenke med 800 bilder, og må bla gjennom dem og si: «Hvor er bildet av meg? Tok de faktisk bilde av meg? Hvor er jeg?» Kanskje du til og med finner din bortkomne tvilling.

Det er også en morsom funksjon. Kanskje noen ser akkurat ut som deg, og plutselig får du andre bilder. Du skjønner hva jeg mener. Problemet kunden hadde før vi kom inn, var at de hadde laget en app for fotografer. Produktteamet hadde brukt tre til seks måneder på å utvikle en app for fotografer, med svært kompliserte funksjoner for å redigere bilder.

Vi kom inn fordi vi også arbeider litt med kundeopplevelse og brukergrensesnitt. De sa: «Nå har vi denne appen. Kan dere kontakte noen fotografer og finne ut hvordan vi kan markedsføre den?» Vi hadde mange fotografer i nettverket vårt fordi vi også arrangerte begivenheter. Tilbakemeldingen var: «Jeg er fotograf. Jeg betaler ikke for en app der folk kan finne seg selv. Jeg har allerede egne programmer på datamaskinen. Jeg trenger ingen app som hjelper meg med å redigere bilder. Jeg får betalt for å ta bilder, ikke for å distribuere dem. Det er arrangørens ansvar.»

Så vi gikk tilbake til kunden. Jeg sa at markedsavgrensningen deres tydeligvis hadde vært helt feil. Vi gjennomførte en undersøkelse med 10–20 fotografer, og ingen ønsket å kjøpe løsningen. Samtidig snakket vi med mange arrangører, for eksempel par som skulle gifte seg og selskaper, og de sa: «Dette vil vi sannsynligvis kjøpe.»

Vi gikk tilbake til utviklingsteamet og eieren av selskapet og sa at de foregående tre–fire månedene kanskje hadde vært bortkastet utvikling, men at vi nå måtte fjerne alle de kompliserte funksjonene for fotografer, som arrangørene ikke ville forstå eller bry seg om.

De trenger ikke å gjøre bildene vakrere. Vi må lage en app for arrangører, der de kan laste opp bilder, hente inn bilder fra deltakerne eller bruke ansiktsskanning og deretter distribuere bildene. Jeg vet ikke hvor mye penger de brukte på utviklingen, men de utviklet uten markedsundersøkelser og uten å vite hva markedet faktisk trengte.

Du må gjøre teamet ansvarlig. Utvikleren kan si: «Sjefen min ba meg utvikle en app for fotografer.» Men da spør jeg: Hva slags prosjektteam har dere? Hvor er personen som arbeider med brukergrensesnitt og brukeropplevelse? Hvor er testingen etter to eller tre sprinter? Dere trenger ikke en ferdig app ennå.

Test den og spør: «Vi har to grunnleggende funksjoner. Har dere snakket med noen fotografer?» «Nei, vi har ikke snakket med noen fotografer.» Det er dette OKR-er kan forhindre når du gjør prosjektmålet forretningsorientert i stedet for å basere det på prosjektmilepæler.

Galen Low: Du nevnte at OKR-er passer svært godt sammen med smidig arbeidsmetodikk. Noen som lytter, kan kanskje si: «Men Carsten, vi trenger ikke OKR-er. Vi har et tverrfunksjonelt smidig team, vi er kundefokuserte, vi arbeider iterativt, vi bygger inkrementer og viser dem alltid til kunden.» Hva tilfører OKR-er et slikt team? Hvis de allerede får kundeinnspill underveis og arbeider tverrfunksjonelt, føler de kanskje at de har felles mål. Trenger de OKR-er?

Carsten Ley: Da gjør de det svært godt på operativt nivå, og det skal de ha. Men hvordan er det på toppen, når det gjelder strategisk samordning? Den første funksjonen til OKR-er er at de kobler team som går fra sprint til sprint, til strategien.

Jeg vet fra egen erfaring at mange utviklingsteam har sprintplanlegging for to eller tre sprinter fremover. Vi vet altså at smidige team planlegger tre til seks måneder frem i tid, avhengig av hvor lange sprintene er. Det er en myte at smidige team bare planlegger to uker fremover.

De har en funksjon som kalles sprintplanlegging, og denne kan kombineres med OKR-er. Du trenger ikke å gjøre mye ekstra arbeid, men du kan kombinere sprintplanleggingen for seks uker til tre måneder med OKR-ene og samordne den med strategiske innspill fra målene.

Jeg ønsker alltid å unngå at folk får mer arbeid på grunn av en ny metode. OKR-er har ukentlig eller annenhver uke oppfølging der vi måler fremdriften. Dere har sannsynligvis allerede sprintgjennomgang annenhver uke. Begynn derfor sprintgjennomgangen med OKR-er og data. Hvis dere allerede har data i sprintgjennomgangen, bruker dere den i OKR-ene.

Ikke gjør noe annet. Da er dere allerede i gang. Dessverre ser vi at noen sprintgjennomganger ikke er datadrevne, men bare består av litt generell prat. Vi ønsker å hjelpe dem med å skape data gjennom OKR-er. Hvis dere har sprintplanlegging som går over tre til seks måneder, bør den knyttes til virksomhetens tremånedersmål.

Hvis de allerede gjør dette, trenger de kanskje ikke OKR-er. Men OKR-er gir struktur – fra strategi til årsmål, videre til tremånedersmål, sprintplanlegging og sprinter. Da får dere tydelige bevis på at de små toukerssprintene faktisk arbeider mot strategien.

Galen Low: Det er svært appellerende. Jeg hører om mange team som blir bedt om å bygge noe, bygger det, og så sier noen: «Dette var ikke det vi trenger.» Eller: «Dette er ikke knyttet til forretningsstrategien.» For det første er det lite motiverende for teamet, fordi de føler at de bare bygger ting.

De blir en funksjonsfabrikk for produktet. For det andre bygger de kanskje feil ting, fordi de setter egne mål i intervaller på to til fire uker uten å følge med på de bredere strategiske målene.

Carsten Ley: Det er én ting jeg vil nevne om motivasjon.

Vi hadde en kunde innen klimateknologi som utviklet en app for å måle karbonavtrykk for selskaper. Det var svært meningsfullt. Men før vi kom inn med OKR-er, sa de til utviklerne: «De første seks månedene skal vi utvikle en app.» Det er kjedelig.

Alle oppstartsbedrifter sier til utviklerne sine at de skal bygge en app de første seks månedene. Hvorfor skulle du være motivert til å arbeide for en bestemt oppstartsbedrift? Hvis jeg var teknolog og kom til et selskap som sa: «Nå skal du bygge enda en app», etter å ha bygget ti eller tjue apper, ville jeg blitt skuffet.

Men hvis du sier til folk i klimateknologiselskapet: «Vi er miljøbevisste. Vi vil at du skal hjelpe oss med å bygge en app som gjør det mulig for selskaper å måle karbonavtrykket sitt», er det mye mer inspirerende. Det er her målet kommer inn. Det sildrer ned fra selskapets formål eller ledestjerne.

Galen Low: Det er morsomt, for det binder virkelig alt sammen. Du ser børsnoterte selskaper som publiserer årsrapporter eller har svært høytidelige misjonserklæringer og verdier. Mange av dem som arbeider med prosjektene, tenker kanskje: «Det er det dere forteller aksjonærene.»

Men det jeg liker ved det du sa, er at målet knytter den overordnede misjonen og strategien til arbeidet som faktisk utføres. Det kan brukes til å inspirere folk. Det blir en konkret visjon, ikke bare ord på en side for å gjøre aksjonærene fornøyde eller få flere kunder.

Carsten Ley: Det er ikke bare inspirerende. Det kan også fungere som beskyttelse for folkene som gjør arbeidet. Hvis jeg sier at vi lager en klimabasert app, og så en dag sier at du må utvikle et spill, kan du spørre hvorfor. Du er ikke bare på et lavere nivå der du blindt gjør det du får beskjed om.

Hvis jeg vet at jeg skriver koden eller programmerer funksjonene for en løsning som skal spore klimaavtrykk, kan jeg også utfordre sjefene mine litt. Hvis de sier at jeg skal utvikle en app for å få kuponger fra McDonald's, som kanskje ikke er særlig klimavennlig, kan det slå tilbake.

Galen Low: Jeg lurer på om du kan snakke litt om prosessen. I teorien liker jeg dette veldig godt. Det legger ikke nødvendigvis mer arbeid oppå det eksisterende, men handler mer om struktur. Mange av prosjektlederne og PMO-ene jeg snakker med, er ikke særlig involvert i forretningsstrategien. Kan du gi noen eksempler på OKR-er, og hvordan de kan utformes på en tverrfunksjonell måte? Blir de alltid gitt ovenfra?

Carsten Ley: La oss fortsette med klimateknologiselskapet. De hadde nettopp fått finansiering. De sa at de i løpet av ett år måtte ha karbonavtrykksappen klar. Samtidig måtte de programmere appen, finne partnere, skaffe mer finansiering og få folk om bord.

Alle disse målene utgjør strategien det første året. I en oppstartsbedrift er ett eller to år allerede en strategi, fordi du ikke vet hvor lenge du vil være i markedet. Du trenger ikke lage en femårsplan når du nettopp har fått finansiering.

Deretter brytes dette ned til et årlig mål som teamlederen kjenner til. Teamlederen og grunnleggerne bør sette seg sammen og spørre: «Hva ønsker vi å oppnå neste år?» Det kan være et utkast eller et estimat. Derfra planlegger vi tremånedersmål.

I første kvartal ønsker vi for eksempel å ha en prototype av appen. Dette målet bør utvikles av grunnleggerne og teamlederne, men ikke nødvendigvis av hele teamet ennå. Med målet om å lage en prototype går jeg inn i prototypeprosjektet, som ikke bare består av utviklingsteamet.

Ideelt sett lager jeg et prosjekt med markedsfolk og selgere, slik at vi kan få potensielle kunder eller partnere til å teste prototypen. Deretter arrangerer jeg en workshop med teamet, enten som teamleder eller sammen med en ekstern konsulent. Vi spør: «Hva kan være målbare nøkkelresultater de neste tre månedene?» Det er altså ikke en ovenfra-og-ned-prosess.

Det er også den fine delen, og det henger sammen med det de allerede gjør i smidig arbeid og sprintplanlegging: De involverer teamet. Vi vet at vi ønsker å bygge en prototype. Hvordan kan vi måle at vi har lykkes?

Det første nøkkelresultatet kan handle om å kode og utvikle en trådskisse eller prototype. Et annet kan være å teste prototypen med et bestemt antall personer og få en bestemt type tilbakemelding. Dere kan også måle hvilke funksjoner som mangler etter de første tre månedene, slik at de kan utvikles i de neste tre månedene.

Dette kan være nøkkelresultater. Teamet får tremånedersmål som er inspirerende: en prototype for klimateknologi, med nøkkelresultater som viser hvordan den skal måles. Deretter kan de starte sprintplanleggingen. OKR-en fungerer som en overordnet oppgavekø.

Ut fra denne kan dere spørre: «Hvilke oppgaver tar vi inn i de første to eller tre sprintene?» Slik fungerer prosessen. Jeg mener ikke at vi skal legge til stadig mer arbeid. Vi legger litt mer arbeid på teamlederne, fordi vi ønsker at teamledere fra alle team, eller prosjektledere, skal være involvert i den årlige planleggingen.

De trenger ikke utforme strategien, men de bør være involvert i årsplanleggingen. Også i større selskaper sørger vi for at avdelingsledere, prosjektledere og PMO-ledere deltar i diskusjonen om årsplanen.

Galen Low: Hvis jeg forstår deg riktig, anbefaler du at man involverer teamlederne i den årlige planleggingen dersom organisasjonen ikke allerede gjør det.

Carsten Ley: Ja. I OKR-prosessen ønsker vi alltid dette. I noen selskaper har man to eller tre nivåer med OKR-er. Man har selskaps-OKR-er, og dessverre ønsker noen også siloiserte avdelings-OKR-er. Det er vi ikke tilhengere av, men vi kan bygge det for dem hvis de ønsker det.

I tradisjonelle selskaper vil de ofte ha det slik, fordi det er enklere å tildele ansvar etter organisasjonskartet. Det er ikke særlig smidig, men det er slik mange selskaper fungerer.

I noen selskaper har vi selskaps-OKR-er, avdelings-OKR-er og team-OKR-er. Da vil vi alltid ha to lag sammen: Selskaps-OKR-er utvikles av toppledelsen sammen med avdelingslederne. Avdelings-OKR-er utvikles av avdelingslederne sammen med teamlederne. Team-OKR-er utvikles av teamlederne sammen med teamet.

Dette skaper åpenhet og innspill nedenfra. «Nedenfra» betyr ikke at man ber renholdspersonalet om innspill til strategien når toppledelsen diskuterer den. Det betyr at man i det minste eksponerer neste nivå for prosessen.

I smidige selskaper hadde vi en interessant kunde i USA som het Scratch Pay eller Scratch Finance. De var et finansteknologiselskap og senere et programvareselskap som tjeneste. Jeg tror de nå er et finansteknologiselskap igjen, fordi de har endret forretningsmodell litt.

De hadde 150 ansatte, hovedsakelig utviklere over hele verden, mens markedsførings- og salgsteamet satt i California i Silicon Valley. De ønsket å arbeide svært mye nedenfra og opp. Grunnleggerne og topplederne utarbeidet et utkast til strategi og årsmål, og deretter sendte vi ut en undersøkelse til de 150 ansatte over hele verden for å få tilbakemeldinger på strategien og årsmålene.

Dette er flott. Hvis du ønsker reelle innspill nedenfra, kan du bruke en undersøkelse. Jeg lover at ikke alle vil svare. Noen utviklere vil ikke involveres i strategien. Kanskje de ikke får betalt for det. Men noen ønsker å bidra, og da gir du dem muligheten.

Vi fikk én svært interessant tilbakemelding. De hadde et selskapsmål som handlet om å knuse konkurrenten. En kvinnelig teamleder skrev i undersøkelsen at de burde unngå så aggressivt språk.

Det var en svært god tilbakemelding. Noen følte seg ikke vel i selskapet på grunn av den aggressive retorikken fra grunnleggerne. Det var nyttig å tone det litt ned slik at folk kunne identifisere seg med målet.

Hvis vi bygger OKR-er på ulike nivåer, følger neste nivå med. Hvis vi bygger PMO-OKR-er, bør prosjektlederne delta. Når vi lager OKR-er for prosjektene, bør prosjektet og prosjektteamet utvikle dem sammen.

Galen Low: Jeg liker den ideen.

Jeg tenker nesten på opplæring. Jeg har arbeidet i mange organisasjoner som ber om tilbakemeldinger, men når de får dem, sier de: «Disse menneskene forstår det ikke.»

Hvis jeg var en person som svarte på en undersøkelse, eller teamleder som skulle få teamet til å utforme nøkkelresultater, men teamet ikke helt forsto oppgaven, hvordan sørger man for opplæring i hele organisasjonen? Hvordan lærer folk hva et godt nøkkelresultat er? Og hvordan vet lederne at tilbakemeldingene fra teamet ikke bare er tilfeldige forslag de kan ignorere, men at alle faktisk forstår rammeverket og strukturen godt nok til å komme med meningsfulle innspill?

Går dere inn og lærer folk om OKR-er, eller må de finne ut av det selv?

Carsten Ley: Når vi starter med et selskap som ikke har brukt OKR-er tidligere, tilbyr vi opplæring på flere nivåer. Vi gjør også dette på leveransenivå, fordi OKR-opplæring samtidig skaper forankring.

Som du sa tidligere, ønsker noen prosjektledere og PMO-er ikke å bruke OKR-er fordi de mener at smidig arbeidsmetodikk allerede dekker alt. I opplæringen kan vi vise at det ikke er helt dekket. De trenger ikke å endre hele prosessen, men kan gjøre enkelte ting bedre, særlig når det gjelder resultatet og den forretningsorienterte siden.

Vi og mange andre OKR-leverandører har en tydelig struktur for hvordan man lager et inspirerende mål som er knyttet til strategien. Det bør alltid være en forklaring på hvorfor vi gjør det. Hvorfor bygger vi en app? Ikke bare fordi vi er en oppstartsbedrift som bygger en app, men fordi det finnes et formål bak – helst et godt formål som inspirerer folk.

Når det gjelder nøkkelresultatene, kan vi måle arbeidet: Hvor mange prosjekter gjennomførte vi? Hvor mange funksjoner utviklet vi? Dette ligner nesten på en KPI, men det er ikke de beste nøkkelresultatene. De beste nøkkelresultatene viser hvilken påvirkning arbeidet vårt har. Liker testkunden funksjonene? Ble noen av de fem prosjektene vi gjennomførte i år lansert og bidro til inntekter for selskapet?

Dette er spørsmålene vi bør måle. I tillegg til struktur og oppsett lærer vi også bort tankesettet om at man ikke bare er ansvarlig for sitt lille område eller for de 400 kodelinjene man skriver.

Man er også ansvarlig for hvordan koden påvirker produktet, og for om produktet selger. Det kan oppstå motstand. Det er endringsledelse. Folk sier: «Jeg er bare utvikler. Jeg er ikke ansvarlig for hvordan produktet presterer.»

Dette er en del av kulturen vi må etablere. Derfor ønsker vi ikke å lage siloer mellom salg, markedsføring og produkt. Det er selve kjernen i prosjekter: å samle mennesker, sette en utvikler, en person som arbeider med brukergrensesnitt og brukeropplevelse, og en selger sammen og si: «Vi gjør dette sammen.»

Ikke at alle sitter i prosjektmøtet og ikke bryr seg om de andre delene.

Galen Low: Det interessante med siloer er at de føles trygge. Du kjenner menneskene i din egen silo og bygger tillit rundt et felles mål. Så snart du går ut av siloen, tenker du: «Jeg vet ikke om jeg kan stole på disse menneskene.»

Det er interessant at du nevner endringsledelse. Jeg tenker på kulturendringen som skjer når man kommer fra en mer siloorganisert kultur og går over til en mer tverrfunksjonell og avdelingsoverskridende modell.

Opplever du at dette skaper mer konflikt mens endringen pågår?

Carsten Ley: Vi ser hovedsakelig konflikter på avdelingsnivå når enkelte ledere ønsker å dominere. Mellomledelsen kan være en utfordring når de vil bygge sine egne små kongedømmer og sier: «Jeg vil ikke at produktavdelingen skal blande seg inn i salgsmålene mine.»

De ønsker ikke å dele suksessen med andre på teamnivå. Vi ser ikke like mange problemer på teamnivå, fordi vi i en OKR-struktur måler i et system der alle kan se tallene fra de ulike teamene.

Det finnes tusenvis av OKR-verktøy på markedet. Vi har ikke vårt eget, fordi det finnes så mange. Det finnes OKR-verktøy for Jira, Microsoft og nesten alt annet. Vi kan følge tallene. Hvis alle oppdaterer status annenhver uke etter sprintgjennomgangen og legger inn tallene, hvordan arbeidet går og hvordan det påvirker virksomheten eller resultatene, kan vi måle dette og vise det svært transparent.

Jeg tror derfor ikke det oppstår mye konflikt. Folk kan likevel bli redde når de føler at de ikke kan påvirke resultatet, og det er en reell bekymring. Men OKR-er er ikke resultatmål på samme måte som KPI-er. Vi har også det som kalles ambisiøse nøkkelresultater, der man kanskje forventer å nå mellom 70 og 100 prosent.

Det finnes altså et visst spillerom. Hvis du ikke når 100 prosent, blir du ikke umiddelbart straffet gjennom bonusen. Hvis man gjør det, blir folk redde for å arbeide tverrfunksjonelt og for å prøve nye ting.

I OKR-er og smidig arbeid ønsker vi at folk skal prøve ting og komme med ideer i prosjektet. Dette stenger man helt ned hvis man knytter bonusen til resultatmålingen. Det er viktig kulturelt at man gir folk handlingsrom.

De første tre månedene med OKR-er i et selskap kaller vi alltid en OKR-pilot. Vi kan gjøre det på ledernivå for å skape forankring, eller i ett team for å teste det. Hvis du kaller det en pilot, håper folk fortsatt at det kan forsvinne, selv om det vanligvis ikke gjør det.

En pilot høres også ut som noe vi kan påvirke, og at tingene ikke er helt alvorlige ennå. Vi kan prøve det ut. Derfor sier vi alltid til kundene våre: «Hvorfor starter vi ikke med en OKR-pilot?» Da kan dere si til de ansatte: «Vi prøver OKR-er først.» De fleste selskaper har allerede bestemt seg for å gå videre, men dette gjør starten litt enklere.

Galen Low: Jeg liker det. Noen ganger bruker folk det som en mulighet til å samle innspill. Selv om beslutningen om å ta det i bruk allerede er tatt, samler de inn tilbakemeldinger om hvordan det bør gjennomføres.

For å være litt djevelens advokat: Jeg vet at noen mener OKR-er er på vei ut. Det var bare en trend som mange prøvde, og nå unngår mange organisasjoner dem. Samtidig finnes det mange organisasjoner som ikke har begynt å bruke dem ennå.

Hvordan kan prosjektlederteam eller team generelt argumentere for å bruke OKR-er i prosjektene og samarbeidet sitt hvis ledelsen ikke er overbevist, eller fortsetter å utsette det?

Kan et team på teamnivå bidra til å få til denne endringen?

Carsten Ley: Noen ganger kan man kjøre OKR-er på teamnivå som en pilot. Hvis ledergruppen ikke følger opp piloten, begynner vi med ett team. Vi ser gjerne etter et mer smidig team, for eksempel et produktteam, der det fungerer godt.

Hvis du har et prosjektteam eller funksjonelt team, har teamet allerede KPI-er eller nøkkelresultater som de måler. Det er altså ikke noe helt nytt. I dag finnes det gjerne et regneark eller et system som Microsoft Planner eller Monday.com. Hvis ikke bruker de Excel.

De må rapportere hver uke, annenhver uke eller minst én gang i måneden på hva de gjør, om det går bra eller ikke, og kanskje også på noen tall. Det er ikke rakettforskning. Vi bruker disse tallene som nøkkelresultater, og legger til noen mer forretningsorienterte nøkkelresultater som viser påvirkningen etter at prosjektet er ferdig.

Da må du stille deg de riktige spørsmålene: Hvorfor gjør vi dette prosjektet? Hvorfor lanserer vi dette produktet? Som prosjektleder og prosjektteam får vi selvfølgelig betalt for å lansere produktet og deretter overlevere det til drift og salg. Men hvis du vil arbeide etter OKR-prinsippene, spør du hvorfor produktet lanseres.

Du spør salgsteamet, og de sier kanskje: «Vi forventer å tjene minst 10 000 dollar de første månedene.» Da legger jeg dette inn i prosjektets nøkkelresultater og lager en fase etter implementeringen. Jeg sier at vi sammen med salg skal ha ansvar for de to første månedene etter implementeringen, og at vi skal oppnå minst 10 000 dollar hver måned.

Prosjektteamet vil selvfølgelig si at dette ikke bare avhenger av dem, men også av salg. Derfor arbeider vi sammen med salg og involverer dem i prosjektet. Det er også lærerikt, fordi du lærer av salg. Salg kan allerede de første ukene fortelle deg at en funksjon skaper problemer eller at kunden ikke liker den.

Dette er det du ønsker. Du ønsker ikke lenger bare å avslutte prosjektet. Hvis du ønsker langsiktig engasjement som ansatt, vil du se at prosjektet ditt har en påvirkning på virksomheten.

I et operativt eller funksjonelt team kan man også begynne med dette. Teamlederen bør kjenne de langsiktige målene. Hvis ikke, bør du som teamleder være modig nok til å gå til sjefene dine og stille spørsmålene, fordi du har krav på å vite prosjektmålet.

Prosjektmålet kan være å lansere et produkt, men da spør jeg PMO-lederen: Hvorfor skal vi lansere dette produktet? Hvordan henger det sammen med strategien? Forhåpentligvis kan de forklare det. Hvis de sier at de bare prøver noe merkelig som ingen bryr seg om, er det svært demotiverende.

Med informasjonen ovenfra kan du enkelt lage målet ditt. Med det du allerede måler, har du de første nøkkelresultatene som viser prosjektsuksessen. Deretter må du også måle forretningspåvirkningen og se om teamet ønsker å arbeide slik.

Jeg sier ikke at alle må bruke OKR-er. Noen selskaper er fornøyde med at prosjektfolk gjennomfører prosjektet og overleverer det til salg og drift. Det er helt greit for meg. Men prøv det med ett team og se hvordan folk reagerer.

Galen Low: Det er interessant. Jeg liker den nedenfra-og-opp-baserte samarbeidsformen. La oss snakke med salg om målene deres og måle dem. Selv om prosjektet, sprinten eller leveransen vår teknisk sett er ferdig, er vi fortsatt interessert i hva som skjer med den videre.

Vi kommer sannsynligvis fortsatt til å arbeide med den. Det er en kontinuitet og varighet i oppdraget som er knyttet til selskapet, ikke bare til dette ene prosjektet eller denne ene sprinten.

Carsten Ley: Når vi gjør dette, skjer forbedringer etter en prosjektfase vanligvis på en god og samarbeidsorientert måte.

Det som ofte skjer, særlig i en tradisjonell prosjektstyringssammenheng, er at man avslutter prosjektet brått og overleverer det. Vi oppfyller alle milepælene og leveransene, men kanskje fikk vi feil innspill helt i begynnelsen. Eller kanskje salgslederen ble byttet ut fra begynnelsen til slutten av prosjektet.

Du overleverer til den nye salgslederen, og etter to måneder går de til sjefene dine og eskalerer problemene. Da begynner all konflikten. Det er ikke en god måte å samarbeide på. Hvis prosjektresultatet ikke lykkes, vil det før eller siden slå tilbake på prosjektteamet.

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

Carsten Ley: Hvorfor ikke forebygge dette mer proaktivt og samarbeide med de riktige personene allerede under prosjektet, slik at dere sikrer at det blir en suksess?

Galen Low: Det liker jeg.

Du har berørt én siste ting som jeg tenkte vi kunne avslutte med. Vi har snakket om ovenfra-og-ned på ledernivå og nedenfra-og-opp. Et prosjektteam kan være nysgjerrig på å prøve dette, kanskje som en teampilot. Du nevnte PMO-er, dette mellomnivået, og at målene dine da du ledet et PMO, noen ganger bare handlet om hvor mange prosjekter dere leverte.

Det virker som om OKR-er kan være en god mulighet for PMO-er som ikke er med ved bordet, til å bli mer strategiske. Hvordan kan PMO-er bruke OKR-er til å knytte seg til virksomheten, slik at de ikke bare blir en prosjektfabrikk?

Carsten Ley: PMO-er bør være en del av strategidiskusjonen, eller i det minste av den årlige planleggingen.

Det er det første vi må sørge for. Deretter kan PMO-er, på samme måte som avdelinger, ha OKR-er som handler om virksomheten og ikke bare om prosjekter. Ikke snakk bare om antall prosjekter, hvor mange prosjektledere dere har eller hvor mange prosjekter dere må sette opp.

Hvis ett årsmål er produktlansering, et annet er markedslansering og et tredje er effektivitet, kan PMO-et diskutere hvilke prosjekter de kan foreslå nedenfra eller fra mellomnivået for å lansere produkter, erobre markedet og gjøre selskapet mer effektivt.

Særlig når det gjelder effektivitet, kommer de beste forslagene ofte fra teamene eller prosjektlederne. De kommer ikke nødvendigvis ovenfra, fordi toppledelsen ofte ikke vet så mye om hva som skjer lenger ned i organisasjonen.

PMO-et er en svært tverrfunksjonell avdeling som også har en styringsfunksjon. Da jeg ledet et PMO i et finansteknologiselskap etter å ha arbeidet i bank, brukte vi PMO-et mye til undersøkelser. Vi spurte teammedlemmer fra ulike team om behovene deres og hva de trengte fra prosjekter eller lanseringer.

Vi spurte ikke bare de åpenbare teamlederne om innspill, men også flere andre personer. PMO-et kan gjøre mer. Vi hadde en forslagskasse i PMO-et, selskapets digitale forslagskasse. Alle kunne komme fra hvor som helst og si: «Jeg har en idé til et prosjekt», eller fortelle om noe som ikke fungerte så godt.

Vi hadde også et lite budsjett til å belønne forslag dersom de ble tatt videre og resulterte i et vellykket prosjekt. PMO-et kan gjøre mye med denne tverrfunksjonelle kraften. Folk stoler på PMO-et. Vi driver ikke med politikk, men er nøytrale.

Å være en del av den strategiske årsplanleggingen, komme med forslag og koordinere arbeidet til slutt er fantastisk.

Galen Low: Jeg elsker den ideen, og jeg vil definitivt gå mer inn i den. Vi lager en ny episode om OKR-er for PMO-er. Det høres veldig interessant ut.

Carsten Ley: Det blir fantastisk.

Galen Low: Flott. Carsten, tusen takk for at du tok deg tid til å være med meg i dag. Jeg har hatt det veldig gøy og lært mye. Dette har vært flott.

Carsten Ley: Tusen takk. Det var en glede å være her. Takk, Galen.

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