Erfaringer fra endringsledelse

[00:00:00] Supert. Tusen takk til alle som følger med i dag. Vi skal snakke med dere om endringsledelse. Dette er et tema som har dukket opp mange ganger i chatten vår den siste tiden. Derfor tenkte jeg at nok fikk være nok, og at jeg ville samle noen mennesker i et rom og snakke om noen av tingene som foregikk.

Det jeg ønsker, er at dette skal være et øyeblikk hvor vi kan dele og bidra til å bygge opp den kollektive kunnskapen her, fordi vi alle har vært gjennom endringsledelse i våre egne prosjekter og organisasjoner, og har vært både den som gjennomfører og den som mottar endringer. Jeg ønsket å bruke denne tiden til å dele noen av historiene våre og snakke om tingene vi har lært underveis, slik at vi kan hjelpe andre, uansett hvor de befinner seg i sine egne prosesser eller endringer.

Og det er på en måte det fine med fellesskapet. Det handler om å bygge opp den kollektive kunnskapen. Jeg har bedt et par personer om å ta med historier. Hvis du ikke har en, går det helt fint. Hvis du kommer på en underveis i økten, er det også flott. Det jeg ønsker å gjøre, er ganske enkelt å dele noen av disse historiene.

Når spørsmål dukker opp, må dere gjerne skrive dem i chatten eller rope dem ut. Dette blir i stor grad en diskusjon. Vi kan dele noen av tingene vi har lært underveis. Tanken er at vi når vi avslutter i dag, forhåpentligvis skal ha noen flere verktøy og ideer til hvordan vi kan håndtere endringer i våre egne prosjekter.

En av personene som hadde bedt om å få dele en historie for å komme i gang, var Fred. Fred, hvis du vil starte, setter vi i gang her. Som jeg nevnte, kan dere stille spørsmål i chatten, rekke opp hånden eller bare stille dem, så skal vi ha det hyggelig.

Ja, absolutt. Takk. Først og fremst takk for at dere arrangerer dette. Jeg synes det ikke bare er flott å se arrangementer som dette, men det er enda bedre å se arrangementer som dette som i praksis er et direkte svar på at folk har spørsmål og ting de lurer på, fordi det virkelig bygger fellesskap.

Og takk for invitasjonen til å dele en historie. Bakgrunnen min er innen utforming av opplæringssystemer, og jeg har faktisk doktorgrad i dette. Jeg har sett på all teorien og alle modellene, og en del av utformingen av opplæringssystemer handler om organisasjonsutvikling. Derfor er endringsledelse en stor del av dette.

Selv om jeg ikke har enormt mye erfaring med formell endringsledelse, for eksempel som del av et endringsteam, har jeg gjort litt forskning på området. Peter Senges lærende organisasjon og Den femte disiplin, samt Kotters åttetrinnsmodell og Lewins modell med opptining, endring og nedfrysing, er nyttige modeller.

De er nyttige som måter å tenke på endring på. Hvilke prosesser kan man gå gjennom? Hva kan man gjøre i dette rommet? Det gjelder også implementeringsarbeid.

Everett Rogers har for eksempel skrevet mye om spredning og adopsjon av innovasjoner. Tanken er at man når en kritisk masse når en teknologi tas i bruk. Man har innovatørene som griper tak i nesten hva som helst og bærer fanen en stund. Men når disse personene har mettet markedet, må man nå videre.

Da beveger man seg til tidlige brukere, før man når en kritisk masse hvor omtrent alle vet hva det er og begynner å vurdere det. Deretter beveger man seg mot de sene brukerne. Til slutt bruker alle Microsoft Teams eller et tilsvarende verktøy i organisasjonen.

Og så finnes det alltid noen få etternølere som sier: «Det kommer ikke til å skje.» Jeg kommer fra høyere utdanning, og selv om hele skolen bruker Google eller Microsoft, finnes det alltid tre faglig ansatte som sier: «Jeg bruker ikke den e-posten. Jeg bruker min egen fordi jeg liker den bedre.»

Hvordan vet man da om møter? Hvordan kan studentene bestille avtaler med deg? De må gjennom en slags Rube Goldberg-maskin for å finne ut hvordan de skal koble kalenderen min og sende en e-post med brevdue.

Det finnes modeller og teorier bak dette, men for ikke å bli for langvarig skal jeg dele noe ganske kort. Jeg har hatt mange ulike erfaringer gjennom årene, og den jeg tror passer best her, er at jeg arbeider mye med å hjelpe organisasjoner med å bygge om systemene sine ved hjelp av monday.com og lignende verktøy.

Jeg hadde en kunde som produserte e-læring. De var et firma som laget opplæring for større selskaper. En av kundene mine hadde brukt Monday tidligere, men det var en av de situasjonene hvor noen hadde kommet inn og implementert det uten at det nødvendigvis var planlagt ordentlig.

Mange av Monday-prosjektene jeg arbeider med, er egentlig ikke Monday-prosjekter. De handler om forretningsprosesser. Det man ofte oppdager, er at folk ikke har utarbeidet standardprosedyrene sine, kartlagt arbeidsflyten eller tenkt gjennom hvordan den ideelle prosessen faktisk burde se ut.

Hvis man ikke vet hvor man befinner seg, kan man heller ikke endre det. Da kommer ingenting til å fungere slik man ønsker. For denne kunden tok det omtrent ett år, men jeg arbeidet grundig med dem for å bygge om systemene deres. Det forbedret mye av ytelsen og prosjektleveransene deres og reduserte kvalitetsproblemene.

Det handlet i hovedsak om mange iterative runder med spørsmålene: Hvordan burde dette egentlig se ut? Hvordan ser det ut nå? Hvordan kan vi slå sammen de to slik at vi kommer nærmere ønsket situasjon?

Jeg tror denne prosessen er så enkel som den kan bli, men det er sannsynligvis nettopp denne prosessen alle endringsmodellene forsøker å beskrive. Den er ganske universell. Enten man prøver å gå ned i vekt, bli sterkere, lære en ferdighet eller gjøre noe med huset sitt, handler det om analyse: Hvordan ser idealet ut, og hvor er vi nå?

Noen praktiske ting jeg tok med meg fra prosjektet, var at utfordringen ofte var at problemet ikke var definert. Da kunne vi heller ikke løse det. Jeg så også på hvordan de ulike prosjektarbeidsflytene var satt opp, men ikke nødvendigvis koblet sammen.

Det kunne for eksempel oppstå situasjoner hvor hun hadde konsulenter og spurte: «Hvor er dette prosjektet?» Jeg svarte: «Jeg overleverte det til kunden.» «Når var det?» «For tre uker siden.» «Hvor er det nå?» «Jeg har ikke hørt fra dem.» «Fulgte du opp?» «Ikke ennå.»

Det handler om å kartlegge overleveringene og være bevisst på prosessen. Lærdommen jeg tok med meg, er at jeg alltid prøver å definere problemet ordentlig i starten med en ny kunde. Jeg vil forsikre meg om at problemet er analysert, og at jeg vet nøyaktig hva de forsøker å oppnå.

Jeg begynner ikke engang med Monday eller hvilket verktøy vi skal bruke. Programmering fungerer på samme måte. Man åpner ikke bare et kodeprogram og begynner å skrive uten å vite hva man prøver å oppnå. Planlegging er ikke det jeg naturlig faller inn i, men jeg har tvunget meg selv til å lære det, og det er svært nyttig.

Deretter må man få kunden til å formulere prosessen de ønsker. Hvis man sier «vi vil at dette skal skje», må man spørre: Hva betyr det? Hvem går det videre til? Hvor sendes det? Hva skjer etterpå? Hvor kommer inputen fra? Målet er egentlig bare å lage et kart.

Jeg vet ikke om dette er litt på siden av det vi prøver å oppnå, men jeg kan utdype det. Jeg vil bare ikke bruke for mye tid. Jeg er nysgjerrig på det første spørsmålet.

Når du kommer inn i dette rommet og egentlig må begynne å lage standardprosedyrer for disse menneskene fordi de ikke har noe på plass, møtte du motstand? De har sannsynligvis sine egne personlige prosedyrer som de følger. Hvordan får du dem med på dette?

Det er et veldig godt poeng. I dette tilfellet arbeidet jeg hovedsakelig med eierne. Det var nyttig fordi hun var den viktigste interessenten og personen som satt på all informasjonen. En av utfordringene var at alt dette fantes, men bare inne i hodet hennes. Det ble ikke nødvendigvis praktisert eller fulgt.

I dette tilfellet var de andre personene konsulenter, ikke heltidsansatte. Interessen deres var å komme inn, levere prosjektet så raskt og effektivt som mulig og gå videre. De var ikke nødvendigvis investert i virksomheten utover å levere et godt produkt.

De hadde også sin egen måte å gjøre ting på. Det kunne være en standardprosess som var godt definert, eller kanskje ikke. Det avhang av hvor lenge de hadde arbeidet som konsulenter. Men disse to tingene passet ikke alltid sammen.

Da oppstår en situasjon hvor eieren sier: «Dette er prosessen. Nå har vi kartlagt den, og det er dette jeg vil at du skal følge.» Konsulenten er kanskje enig, kanskje ikke. Da kommer man inn på ting som prosjektbaserte timer: «Jeg gir deg et bestemt antall timer til dette prosjektet. Dette er prosessen, portene og kontrollpunktene du skal gjennom.»

Hvis man ikke når et kontrollpunkt, kan man stoppe prosessen tidlig. Mye handler om kontroll og balanser.

Det finnes motstand. Jeg tror det alltid finnes motstand. Det henger sammen med modellen for spredning av innovasjoner. Noen vil støtte ideen, mens andre har autoritet til å bestemme prosessen. Noe må dikteres, mens noe må være åpent for forslag, slik at folk kan være medforfattere av prosessen. Den riktige balansen varierer fra sak til sak og avhenger av hva man kan forhandle frem.

Jeg tror det er en god måte å gå frem på. Jeg vil gjerne høre hvordan dette stemmer med erfaringene til andre i samtalen, hvilke lignende utfordringer og tilnærminger dere har sett eller brukt, og hva som er annerledes.

Hvis dette ikke gjelder dere, har dere kanskje en helt unik erfaring som ingen andre har møtt. Jeg har i alle fall vært borti situasjoner hvor folk har vært motvillige til nye ideer, endringer eller prosesser.

Vi har noen kameraer som er slått av, så det kan hende folk bare lytter mens de arbeider. Det er helt greit.

Jeg har et spørsmål til deg, Fred. Du fortalte om kvinnen som hadde alt inne i hodet, og som du måtte hente informasjonen ut fra. Hvordan forklarer du at dette er viktig, og at hun må sette av tid til å gi deg informasjonen, slik at du kan lære andre opp?

Jeg arbeider med mennesker som er kaotiske og travle. De sier: «Jeg har ikke et minutt. Nå gjør du ting jeg ikke ba deg om å gjøre.»

Det er mye som dukker opp i hodet mitt. En del av dette handler om å vite hvilken rolle man har. Jeg sier ofte at vi som prosjektledere ikke holder i rattet. Vi sitter i passasjersetet med kartet og sier: «Du må ta til venstre. Det kommer om en halv mil. Sett på blinklyset.» Men hvis de kjører forbi svingen, holder du ikke i rattet.

Da blir jobben din å si: «Det ser ut som vi passerte svingen vi virkelig måtte ta. Det beste vi kan gjøre nå, er å snu og ta den andre veien.» Men du holder fortsatt ikke i rattet.

På slutten av reisen kan de spørre hvorfor det tok tre timer ekstra, og se på deg som om det var ditt ansvar. Da kan du si: «Alle gangene jeg ba deg ta til venstre og du ikke gjorde det, måtte vi kompensere og kjøre rundt.»

Det er analogien jeg vanligvis bruker. Det kan hende de ikke vet, eller at de er travle og ikke har alt kartlagt. Men det tar tid å kartlegge ting. Ofte tror de at prosessen er ferdig og at folk forstår den, men det er ikke nødvendigvis tilfelle.

I dette tilfellet brukte vi mye av møtene på at hun gikk gjennom alt hun hadde å gjøre, sendte meldinger og forsøkte å håndtere alt som lå på bordet hennes. Det var vanskelig å få et helt minutt.

Det beste jeg kunne håpe på, var å oppsummere mot slutten: «Du sa dette, så jeg kan gjøre disse oppgavene.» Eller: «Jeg har noen ideer. Jeg tror dette er det beste for meg å arbeide med. Er du enig?»

Noen ganger møttes vi i en hel time, og det beste jeg fikk ut av møtet, var å foreslå to eller tre ting jeg kunne arbeide med og få tilbakemelding på. Det var en lang prosess.

Hvis man fakturerer per time, fungerer det slik. Hvis prosjektet er fastpriset, må man gå frem på en annen måte. Jeg sier noen ganger at jeg er en dyr terapeut eller venn. Hvis du vil bruke opp timene dine på den måten, kan vi gjøre det, men jeg må samtidig si at dette er måten vi bør arbeide på.

Hvis du ikke tar til venstre, blir jeg med på turen. Hjalp dette, Robin? Forhåpentligvis var jeg ikke helt på villspor.

Jo, det hjalp absolutt. Jeg ønsker meg en ny stillingstittel: dyr terapeut.

Noen ganger er det faktisk treffende. Jeg har sett situasjoner hvor folk sier: «Jeg vil at du skal gjøre A.» Du arbeider med A en stund, og så sier de: «Egentlig vil jeg at du skal gjøre B.» Du gjør B, og så spør de hvorfor du gjorde B. Du svarer at det var det de ba deg om, og at dere burde gjøre A. Da går dere tilbake til A.

Som konsulent kan jeg gjøre dette hele dagen hvis jeg fakturerer per time. Jeg sier at vi ikke burde gjøre det, men hvis det er det du trenger, gjør vi det. Hvis prosjektet er fastpriset, må jeg stoppe det med en gang, fordi jeg har kastet bort 150 timers arbeid når kunden halvveis i prosessen bestemmer at det de ønsker, ikke ligner på det vi startet med.

Noen ganger sier kunder at de vil ha en rask bil, men de vet ikke om det er en Porsche eller Lamborghini før de ser den og sier: «Dette er det jeg vil ha.»

Det hjelper å være tydelig. Noen mennesker må snakke hele tiden for å bearbeide ting. Da kan man la dem snakke, og til slutt si: «Dette er det jeg tar med meg. Korriger meg hvis jeg tar feil. Dette er de fem tingene jeg skal arbeide med, og dette er de tre tingene du skal levere til meg.»

Jeg prøver alltid å oppsummere i en e-post etterpå. Jeg skriver hva du skal gjøre, og hva jeg skal gjøre. Da kan jeg to uker senere hente frem e-posten og si: «Dette var det vi arbeidet med. Jeg minnet deg på det på onsdag, men du sendte det ikke. Jeg har fått dette, men kan ikke gjøre dette før jeg får informasjonen fra deg.»

Opptak er nyttige, særlig når det gjelder oppfølgingspunkter.

Robin, jeg er nysgjerrig på spørsmålet ditt om personen som hadde alt inne i hodet og trengte å få det skrevet ned. Handler dette om noe du arbeider med akkurat nå, eller om noen av utfordringene du har møtt når du skulle håndtere endringer i prosjektet?

Jeg tror vi noen ganger lever i et kaotisk prosjekt og ønsker å lage prosesser eller standardprosedyrer som kan være nyttige hvis det samme skjer igjen. Men noen ganger har vi ikke et minutt til å hente informasjonen fra personen.

Jeg er også litt usikker på forskjellen mellom endringsledelse og prosjektledelse, fordi alt kan være et prosjekt. Kan du forklare det?

Det er et fantastisk spørsmål. Jeg kan prøve å svare, men jeg har snakket mye. Kanskje noen andre vil ta det.

Hvis man ser på definisjonene, er et prosjekt et midlertidig arbeid som fører til et produkt eller et resultat. Endringsledelse er prosessen med å håndtere endringen.

Siden vi er digitale prosjektledere, kan vi ta en ny nettside som eksempel. Du overleverer en ny nettside til noen. Hva skjer da? Det vil nødvendigvis oppstå endringer i prosessen deres. Kanskje du har bygget om kontaktskjemaet, slik at henvendelser kommer inn på en annen måte. Kanskje du har koblet nettsiden til CRM-systemet med nye felt, slik at de får ny informasjon.

Alt dette er gode ting, men de er endringer. Derfor må vi tenke på hvordan vi kommuniserer endringen, og hvordan vi gjør folk klare for den. Fred gjorde en god jobb tidligere da han snakket om mennesker som kan være motvillige til endringen.

Jeg arbeider med et prosjekt nå hvor jeg overtok etter en annen prosjektleder. På den første dagen måtte jeg fortelle kunden at de hadde gjort en feil til en verdi av seks eller syv sifre tidlig i prosjektet. Lanseringen ville bli forsinket, og de måtte finne mer penger for å rette feilen.

De erstattet omtrent 20 år gammel programvare som folk hadde bygget videre på over tid. Det var også en annen leverandør involvert, og vi fikk beskjed om at vi bare kunne snakke med en svært liten gruppe interessenter. Denne gruppen ga oss informasjon som teamet arbeidet ut fra, men under brukertestingen oppdaget vi at informasjonen faktisk var feil.

Dermed måtte vi gjøre alt arbeidet på nytt. Det var dette som førte til kostnaden på flere millioner. Det fantes gode grunner til at de ikke ville åpne slusene og snakke med brukerne for tidlig. Hvis den andre leverandøren ble sint og fjernet programvaren før vi var klare til å bytte, ville kunden ikke kunne drive virksomheten.

I ettertid gir det mening, men hvis jeg hadde vært der fra starten, ville vi sannsynligvis ha diskutert bedre måter å gjøre det på. Jeg ville også ha fått dem til å signere et risikoregister som sa: «Jeg forstår risikoen ved å gjøre det på denne måten. Jeg vet at dette kan bli et problem senere fordi teamet ikke får riktig informasjon. Jeg forstår dette og godkjenner at det er slik prosjektet skal gjennomføres.»

Nå nærmer vi oss slutten av prosjektet og begynner å tenke på lanseringen. Kunden gikk gjennom en myk lanseringsprosess, som egentlig var en utvidet brukertest som del av endringsledelsen. Det ga dem også mulighet til å gi tilbakemeldinger, noe jeg mener er en svært viktig del av endring. Hvis du føler deg hørt, aksepterer du vanligvis endringen lettere enn hvis den blir presset på deg.

Kunden ønsket først å gi programvaren til disse menneskene og si «kjør». Etter første forsøk forsto vi at det var en svært dårlig idé. Derfor har vi gått over til en mer formell prosess for oppstart av myk lansering.

Vi samlet resten av gruppene som skulle teste, og laget det jeg kaller kommunikasjon basert på vennlig gruppepress. Det er bokstavelig talt en e-posttråd hvor alle i gruppen deltar. De kan se når andre stiller spørsmål, og vi kan se hvem som deltar og hvem som ikke gjør det.

Det har vært mange bevegelige deler: endringer i programvaren, endringer i prosjektteamet og nå endringer i selskapet til kundens kunde.

Fred spurte om man toner ned situasjonen og beskytter seg selv når man må fortelle noen om så store feil. Det morsomme er at jeg og Galen hadde en hel samtale om kontraktsbasert prosjektledelse tidligere i dag. Jeg er kontraktsansatt prosjektleder, og alle – også kunden – vet det.

Siden jeg var en nøytral tredjepart, kunne jeg komme inn og si: «Dette er situasjonen vi er i. Vi må finne ut hvordan vi kommer oss ut av den.» Jeg hadde vært rådgiver i omtrent seks måneder før jeg tok over prosjektet. Derfor var ikke alle beslutningene mine, selv om jeg fortsatt mener noen av dem var fornuftige på det tidspunktet.

Jeg kunne si til kunden: «Dette gjorde vi. Dette var grunnen. Nå er vi her. Jeg ser alternativ A, B og C for å komme ut av situasjonen, og de fleste vil kreve en stor sum penger.»

Føler du at du fikk et tydelig svar på forskjellen mellom prosjektledelse og endringsledelse?

Jeg synes det var nyttig å redusere det til noe så konkret som at man har fullført en nettside, og deretter må forstå hvordan den skal oppdateres og forvaltes.

På samme måte som prosjektledelse handler om å lede prosjekter og alt som inngår i dem, handler endringsledelse om å lede en endring. Prosjekter er ikke drift, men en særegen midlertidig situasjon. Derfor finnes det mye overlapp mellom prosjektledelse og endringsledelse.

Jeg lurer på om noen har arbeidet sammen med et endringsledelsesteam samtidig som de har arbeidet som prosjektleder.

Jeg gjorde det en periode hos et av de store konsulentselskapene. Der hadde vi et tilbud hvor endringsledelsesfolk drev endringsledelsen for kundene. Mye handlet om kommunikasjon, innspill og forankring.

Vanligvis handlet det om å sy sammen tingene. Når man redesigner en nettside, lanserer en ny nettapplikasjon eller gjennomfører en stor markedskampanje, er det ofte bare én del av helheten. Noen må ha oversikt over hvordan hele helheten innføres med tanke på endring.

Det var interessant å se, fordi det kunne bli slik at alle spurte: «Hva gjør dere her?» De andre arbeider med sitt, mens endringsledelsesteamet følger med overalt. Men verdien var tydelig. Noen måtte sy tingene sammen og sørge for at endringen ble prioritert.

I mange prosjekter jeg har arbeidet med, er det ingen som tenker på endringsledelse. Da faller ansvaret ofte på prosjektlederen, eller prosjektet lanseres og mislykkes fordi ingen tenkte på endringen. Ingen av delene er bra.

Jeg hadde en lignende erfaring da jeg arbeidet i Aramark. Vi gjennomførte en overgang til et nytt CRM-system. Jeg var kommunikasjonsansvarlig i prosjektet, og vi hadde også en endringsansvarlig.

Sjefen min spurte hvorfor endringsledelsen bestemte at noe skulle være en e-post, et møte eller opplæring. Jeg forklarte at den endringsansvarlige skulle anbefale tiltakene, og at jeg deretter skulle gjennomføre dem. Hvis hun mente det burde være en serie e-poster, skrev jeg e-postene. Hvis hun mente det burde være et nettseminar, produserte jeg nettseminaret.

Det er omtrent der grensen mellom rollene går. Verdien var stor, og det var en enorm luksus å lære av henne og hele endringsledelsesgruppen i selskapet.

Jeg ønsket virkelig å ta en sertifisering innen endringsledelse. Hvis jeg hadde fortsatt i næringslivet, ville jeg nok ha fått arbeidsgiveren til å betale for den, men den kostet omtrent fire tusen dollar, og jeg har ikke særlig lyst til å betale det selv.

Jeg vil gjerne ta opp en annen historie med en litt annen erfaring fra endringsledelse. Sarah, hvis du har en kort historie, kan du gjerne dele den.

Eksempelet mitt er fra et byrå jeg arbeidet i. De fleste vet sikkert at jeg hovedsakelig har arbeidet i ganske små kreative byråer, med 20 ansatte eller færre. De fleste hadde mellom fem og ti ansatte.

Dette byrået hadde gått gjennom flere runder med oppsigelser. Etter oppsigelsene hadde vi ikke lenger et kreativt team. Byrået hadde gått fra store kreative prosjekter og redaksjonelt arbeid med fotograferinger til mer forskning og strategi, fordi kundenes behov hadde endret seg.

Verktøyene og dokumentasjonen for verktøyene var allerede utdaterte på grunn av rask vekst. De var ikke lenger nyttige for det gjenværende teamet. Driftsavdelingen hadde vært tre personer på det meste, deretter to og til slutt én – meg.

Jeg hadde ikke tid. Når teamet blir mindre, endres behovene. En prosess som fungerte da teamet besto av 20 personer, fungerer ikke nødvendigvis når du er én person. Da blir det enda viktigere å arbeide smartere, ikke hardere.

Et av problemene var at teamet ikke visste hvordan de skulle bruke Asana, som var det viktigste prosjektstyringsverktøyet vårt. Det ble uklart hva som skulle skje i Slack, og hva forventningene var til bruken av Asana.

Derfor ble det et kvartalsmål å lage et opplæringsprogram. Første steg var å se på hva vi faktisk hadde og definere hva som var viktig for teamet. Som Fred sa, må man definere problemet før man bestemmer neste steg.

Moralen var ganske lav fordi det pågikk oppsigelser. Oppmerksomheten var begrenset. Teamet arbeidet hjemmefra, og pandemien føltes fortsatt nær. Folk ville ikke sitte i møter, og de ville i hvert fall ikke lese et 40 siders Google-dokument om hvordan Asana og Slack skulle brukes.

Derfor måtte opplæringen være kort, relevant og enkel. Alt som var overflødig, måtte bort. Jeg kunne selv ønske alle detaljene, men målet var å lage et opplæringsprogram og definere hvordan byrået skulle bruke verktøyene.

Deretter undersøkte jeg hva som allerede var tilgjengelig. Siden jeg var en avdeling på én person, spurte jeg om Asana eller en blogg hadde laget noe jeg kunne sende videre. Jeg visste at jeg måtte plukke ut deler og sette dem sammen.

Til slutt laget jeg et lite opplæringsprogram. Siden vi brukte Asana, opprettet jeg et prosjekt der og kopierte det for hver person. De skulle gå gjennom det ovenfra og ned. Hver oppgave var en kort del på omtrent fem minutter, slik at de ikke måtte gjøre alt på én gang.

Teamet visste for eksempel ikke hvordan Asana fungerte. Det var nyttig å se gjennom ressursene som allerede fantes. Asana hadde laget en utmerket video på fem minutter som forklarte det grunnleggende, så jeg lot dem se den først.

Deretter forklarte jeg forventningene: hvordan man kommenterer oppgaver, hvordan man setter opp profilen, hvordan man slår av varsler og arbeider fra innboksen. Hvis man er ny i Asana, vet man kanskje ikke at man kan unngå e-postvarsler og kobling mot Slack. Man trenger ikke fire varsler for den samme saken.

Jeg satte dette sammen før jeg lanserte det for teamet.

Hvordan sørget du for at folk faktisk gjorde dette? Du kan gi dem instrukser, men de kan velge å ignorere dem. Da oppstår problemer, fordi ikke alle arbeider så effektivt som de kunne. Hvor går grensen mellom å følge opp og kontrollere folk, samtidig som man gir dem frihet og ikke ødelegger forholdet?

Før alle gikk gjennom opplæringen, holdt jeg en kort introduksjon på kanskje fem eller ti minutter. Jeg sa: «Dette er det jeg har laget, og slik bruker dere det. Si fra hvis dere har spørsmål.»

Jeg la det frem som noe som skulle gi stabilitet og gjøre hverdagen enklere. Vi hadde nettopp gått gjennom mange endringer. Hvis alle var samkjørte og brukte mindre enn en time på opplæringen, ville det gjøre ting lettere.

Jeg ble kopiert på alle oppgavene, så jeg visste når ting var merket som ferdige. Jeg sa at de skulle krysse av etter hvert som de gikk gjennom programmet. Hvis noe var uklart, skulle de ikke krysse det av, men kommentere slik at vi kunne diskutere det privat.

Teamet var lite og godt, så jeg hadde ikke mange problemer. Da det kreative teamet fortsatt var der, var det vanskeligere å få folk til å fullføre slike administrative oppgaver. Strategene og forskerne likte sjekklister, mens det kreative teamet ikke ønsket oppgaver eller påminnelser.

Det hjalp også at opplæringen var en del av kvartalets oppgaver. Jeg laget programmet, og de måtte fullføre det i løpet av den neste måneden.

Jeg liker ikke å være den som må sende påminnelser, men det er en del av jobben. Jeg prøver å være så vennlig som mulig. Det er nyttig å legge igjen et skriftlig spor og kunne si: «Jeg merket deg i en kommentar for to måneder siden og fulgte opp for én uke siden. Vi må sørge for at dette blir gjort.»

Et skriftlig spor er nyttig når man skal håndheve noe. Hvis man bare sier at man fortalte noen noe, uten å kunne vise til det, blir det vanskeligere.

Det som sto ut for meg, var at du brukte et system som teamet allerede likte fordi de var orientert mot sjekklister. Du bygget opplæringen på en måte som passet dem, og det gjorde det enklere. De måtte ikke endre arbeidsmåten sin fullstendig.

Opplevde du noen gang at folk falt fra det nye systemet og gikk tilbake til den gamle måten å arbeide på, eller at oppgaver hopet seg opp? Hvordan håndterte du det?

I dette eksempelet fikk jeg stort sett gode tilbakemeldinger. Folk sa at de aldri hadde forstått forskjellen mellom det som skulle publiseres i Asana, og det som skulle tas i Slack. Ting gikk litt raskere.

Tidligere hadde vi en prosjektkoordinator som sørget for at ting som skjedde i Slack, også ble registrert i Asana, og at oppgavene ble oppdatert. Vi hadde ikke lenger en koordinator. Hvis jeg som prosjektleder skulle vite hva som skjedde, hadde jeg ikke tid til å lese alle kommentarene eller lete etter e-poster jeg ikke var kopiert på.

I dette eksempelet opplevde jeg ikke så mye tilbakeslag. Det var litt i Slack, fordi noen mennesker bare ikke liker verktøy, og det er greit. Slack kan føles som tekstmeldinger, noe alle kjenner.

Jeg har et spørsmål til gruppen. Dette er noe som ofte dukker opp i min verden, og sannsynligvis også i deres: endringstretthet.

Man kan ha et prosjekt som trekker ut i tid, hvor prioriteringene endres hele tiden og kunden kommer hver dag med nye behov. Jeg vet ikke om noen andre opplevde den store omorganiseringen etter pandemien, men mange ble sagt opp eller flyttet rundt.

Har noen opplevd mye endringstretthet, eller har dere metoder for å hjelpe teamene eller dere selv med dette?

Tenker du kortsiktig eller langsiktig?

Begge deler. Jeg har et team som håndterer begge deler.

I høyere utdanning finnes det ofte kortvarige kriser og endringer. De skjer ikke ofte, men når de skjer, blir alt snudd på hodet. Faglig ansatte kan være spesielt utfordrende å arbeide med.

Da pandemien kom, måtte de plutselig undervise på nett. Mange var helt imot ideen. Det finnes en langvarig oppfatning om at enkelte fag ikke kan undervises på nett, selv om jeg mener at nesten alt kan undervises på avstand med riktig kompetanse og riktige ressurser.

I slike situasjoner er det beste jeg har funnet, å hjelpe folk med å finne det som er kjent i det nye. Man underviser fortsatt, gjør de samme tingene og følger opp studentene. Forskjellen er bare at det skjer på nett.

Det er en oversettelse, men man diskuterer fortsatt, holder studentene ansvarlige og underviser. Å finne likhetene i situasjonen hjelper folk med å forholde seg til det nye.

På lengre sikt blir det en samtale. Når man stadig endrer teknologi og verktøy, oppstår det en ustabilitet. Folk investerer ikke i å lære nye verktøy fordi de antar at verktøyet kanskje ikke finnes om seks måneder.

Da blir det en reell utfordring. Hvis kulturen innebærer stadig endring, bryter man tillit. Folk finner en grunnmur i hvordan de arbeider, uavhengig av verktøyene som stadig skifter.

Det blir vanskelig å få dem til å tro på det nye verktøyet eller den nye praksisen, fordi de tenker at det bare er noe en ny leder har funnet på, og at det vil vare i tre måneder før man går tilbake til det gamle – bare med mer bortkastet energi.

Da må det bli en kulturell samtale. Det er i alle fall mitt syn.

Jeg tenkte at jeg skulle skrive, fordi noe av det Fred sa, traff meg. Jeg synes endringstretthet var svært reell i teamet jeg snakket om. Selskapet hadde vokst og krympet flere ganger.

Da pandemien kom, var kundene våre hovedsakelig store teknologiselskaper. Teamet var lite og finansiert av to store kunder. Hvis budsjettene deres ble halvert, måtte man sannsynligvis si farvel til halvparten av teamet. Det var realiteten.

Selv om situasjonen var vanskelig, hjalp det å forklare hvorfor endringen skjedde. Før man innfører noe, kan man si: «Jeg vet at dette er vanskelig, at det vil ta tid, og at det er forståelig om du trenger litt ekstra tid til å fokusere.»

Det handler om å ta med de menneskelige sidene. Man kan si at man forstår at situasjonen ikke er god, og at ingen ønsker å endre hvordan prosjekter leveres eller verktøy brukes.

I eksempelet mitt gjorde endringen faktisk arbeidsdagene enklere. Den varte dessverre ikke så lenge, og jeg ble selv sagt opp til slutt, men i mellomtiden gjorde den arbeidet mindre forvirrende og mindre spredt.

Som prosjektleder kan du sette tonen internt, og kanskje også eksternt hvis du arbeider sammen med en kundeansvarlig. Hvis teamet merker at du synes alt er dumt, vil de også føle det slik. Derfor må man filtrere egne tanker og følelser før man kommuniserer dem.

Det krever energi og bevissthet, men det er svært nyttig når teamet er slitent og urolig og bare ønsker noe stabilt.

En ting jeg vil understreke, er at når folk har vært gjennom mange endringer, vil ting ta lengre tid. Det tar tid å lære nye prosesser, og det går ut over tiden man ellers kunne brukt på det vanlige arbeidet.

Når mange endringer kommer samtidig, vil ting gå saktere og produktiviteten kanskje synke. Det må man kunne akseptere til man kommer tilbake til en situasjon med færre endringer.

Det går i bølger. Det er sesongavhengig, akkurat som mye annet.

Det kan også påvirke tankesettet. Hvis man føler at man får gjort mindre, kan det være demotiverende, særlig hvis man sammenligner det med tidligere perioder hvor man oppnådde mer eller kom lengre mot målene.

Med mange endringer kan man begynne å føle at endringen gjør mer skade enn nytte. Derfor er det viktig å sette forventninger og forklare at det er greit å bremse mens folk orienterer seg og arbeider mot en bedre prosess.

Dette kunne vært en interessant samtale i seg selv: hvordan man setter riktig tempo og avgjør hva som er et godt tempo. Folk sammenligner ofte farten sin med det de tror andre gjør.

Hvis du setter deg tre oppgaver for dagen, må du også gi deg selv rom til å si at det er nok. Legg arbeidet fra deg og aksepter at du har gjort nok i dag.

Ja, jeg ble nesten overrasket da hun sa at hun bare hadde tre ting. Men tre ting er faktisk ganske mye.

Vi nærmer oss slutten av samtalen. Tusen takk til alle som deltok og engasjerte seg. Det var flott å høre historier om hvordan andre arbeider og hvilke utfordringer de har møtt.

For det første er det betryggende å høre at andre har de samme utfordringene. For det andre er det nyttig å ta med seg ideer og prosesser tilbake til sitt eget arbeid.

Jeg håper dere har fått noen konkrete ting dere kan ta med tilbake til egne systemer, organisasjoner og prosesser.

Neste arrangement blir 23. mai. Da skal vi ha et åpent forum. Ta med utfordringer som står øverst på listen din, uansett hva du møter på i arbeidet. Vi tar utfordringene opp til diskusjon med alle, på en måte som ligner på dette, men som er litt mer åpen.

Det handler altså ikke bare om endringsledelse. Vi håper mange av dere kan delta.

Flott. Takk igjen, og ha en fin dag videre. Håper resten av dagen blir bra. Vi snakkes i Slack. Ha det bra alle sammen. [00:55:00] [00:56:00] Takk.