Lärdomar från förändringsledning

[00:00:00] Fantastiskt. Tack så mycket allihop för att ni deltar i dag. Vi ska prata med er om förändringsledning. Det här är ett ämne som har kommit upp många gånger i vår chatt den senaste tiden. Därför tänkte jag att det var dags att samla några personer i ett rum och prata om en del av det som pågår.

Jag vill att det här ska vara ett tillfälle att dela med oss och bygga upp den gemensamma kunskapen här, eftersom vi alla har gått igenom förändringsledning i våra egna projekt och organisationer och har varit både de som genomfört förändringar och de som tagit emot dem. Jag ville använda den här tiden till att dela några berättelser och prata om sådant vi har lärt oss under vägen, så att vi kan hjälpa andra oavsett var de befinner sig i sina egna processer eller i sin egen förändring.

Det är på sätt och vis det fina med gemenskapen: att bygga upp den gemensamma kunskapen. Jag har bett några personer att ta med sig berättelser. Om du inte har någon är det helt okej. Om du kommer på en under sessionen går det också bra. Jag vill bara att vi ska kunna dela några av de här berättelserna.

När frågor dyker upp får ni gärna skriva dem i chatten eller ställa dem högt. Det här kommer i hög grad att vara en diskussion. Vi kan dela med oss av en del av det vi har lärt oss längs vägen. Tanken är att vi när vi lämnar mötet förhoppningsvis ska ha fler verktyg och idéer för att hantera förändring i våra egna projekt.

En av personerna som hade bett om att få inleda med en berättelse var Fred. Fred, om du vill får du gärna börja här, så sätter vi igång. Som jag nämnde går det bra att ställa frågor i chatten eller räcka upp handen och ställa dem högt, så ska vi ha det trevligt.

Tack. Först och främst tack för att ni ordnade det här. Jag tycker att det inte bara är roligt att se sådana här evenemang, utan ännu roligare att se evenemang som är ett direkt svar på att människor har frågor och funderingar, eftersom det verkligen bygger gemenskap. Tack också för att jag fick dela en berättelse.

Min bakgrund är inom design av undervisningssystem och jag har faktiskt en doktorsexamen inom design av undervisningssystem. Jag har tittat på all teori och alla modeller, och en del av området handlar om organisationsutveckling. Därför är förändringsledning en stor del av det.

Även om jag inte har enormt mycket erfarenhet av formell förändringsledning, till exempel att ingå i ett förändringsteam, har jag gjort en del forskning inom området. Den lärande organisationen är ett verkligt mål som många strävar efter. Peter Senges Den femte disciplinen, Kotters åttastegsmodell och Lewins modell med upptining, förändring och återinfrysning är alla användbara. De fungerar som tankemodeller för förändring: vilka processer kan man behöva gå igenom och vad kan man behöva göra inom det området, även när det gäller implementeringsarbete.

Everett Rogers har till exempel gjort mycket arbete kring spridning och införande av innovationer. Tanken är att man når en kritisk massa när en teknik börjar införas. Det finns innovatörer som tar till sig nästan vad som helst och driver det framåt ett tag. Men när den gruppen har mättat marknaden behöver man nå längre än så.

Då går man vidare till tidiga användare och når sedan en kritisk massa där nästan alla känner till vad det är och börjar överväga det. Därefter rör man sig mot de sena användarna. Till slut använder alla Microsoft Teams eller motsvarande i organisationen.

Sedan finns det alltid några få eftersläntrare som säger: ”Det där tänker jag inte göra.” Jag kommer från högre utbildning, och även när hela skolan använder Google eller Microsoft finns det alltid några lärare som säger: ”Jag använder inte den e-postadressen. Jag använder min andra, för jag gillar den bättre.” Hur får man då reda på möten? Hur kan studenter boka tider med dig? De måste gå igenom någon form av Rube Goldberg-maskin för att koppla ihop mitt schema och skicka ett e-postmeddelande med brevduva och allt sådant.

Det finns alltså modeller och teorier bakom det här. För att inte bli alltför långrandig ska jag dela en erfarenhet. Jag arbetar mycket med att hjälpa organisationer att bygga om sina arbetssätt med monday.com och liknande verktyg. Jag hade en kund som producerade e-lärande, alltså ett företag som skapade utbildningar åt större företag. En av kunderna hade använt Monday tidigare, men det var en sådan situation där någon kom in och införde det utan att arbetssättet nödvändigtvis hade kartlagts.

Många av de Monday-projekt jag arbetar med är egentligen inte Monday-projekt utan projekt för verksamhetsprocesser. Ofta upptäcker man att organisationen inte har fastställt sina standardiserade arbetssätt, kartlagt arbetsflödet eller tänkt igenom hur den ideala processen ska se ut. Om man inte vet var man befinner sig kan man inte förändra det. Då kommer inget att fungera som man vill.

Det tog ungefär ett år, men jag arbetade ganska ingående med den kunden för att bygga om systemen. Till slut förbättrade vi mycket av deras prestation och projektleverans och minskade kvalitetsproblemen. Allt bestod egentligen av många iterativa cykler: Hur borde det faktiskt se ut? Hur ser det ut just nu? Hur sammanför vi de två så att vi kommer närmare dit vi vill?

Jag tror att den processen är så enkel som den kan bli, men det är förmodligen den process som alla förändringsmodeller och andra verktyg försöker beskriva. Den är universell. Oavsett om man försöker gå ner i vikt, bli starkare, lära sig en färdighet eller renovera huset handlar det om analys: Hur ser det ideala läget ut och var befinner vi oss nu?

Några praktiska saker jag tog med mig från projektet var att verkligen definiera problemet i början, analysera det och vara säker på vad kunden försöker göra innan jag rör Monday eller något annat verktyg. Programmering fungerar på samma sätt. Man öppnar inte bara en kodredigerare och börjar skriva utan att veta vad man försöker åstadkomma. Planering är inte något jag naturligt faller in i, men jag har tvingat mig att lära mig det och det är mycket hjälpsamt. Det är som att göra en disposition för en text.

Sedan gäller det att få kunden att formulera den process som den vill ha. Om man vill att något ska hända, hur ser det ut? Vem går det till sedan? Vart förs det vidare? Vad händer efter det? Varifrån får man underlaget? Målet är att skapa en karta.

Jag vet inte om det här ligger lite vid sidan av det vi försöker prata om, men jag kan utveckla det. Jag vill dock inte ta för mycket tid. Jag är nyfiken på den första frågan.

När man kommer in i en sådan situation behöver man alltså i praktiken börja skapa standardiserade arbetssätt åt personer som inte har något på plats. Fanns det personer som motsatte sig det? De hade förmodligen sina egna personliga arbetssätt som de följde. Hur får man dem att ställa sig bakom förändringen?

Det är en mycket bra fråga. I det här fallet arbetade jag främst med ägarna, vilket var bra eftersom hon var den viktigaste intressenten och personen som hade allt. En av utmaningarna var att all information faktiskt fanns, men bara i hennes huvud. Den praktiserades eller genomfördes inte nödvändigtvis.

De andra personerna var konsulter, inte heltidsanställda. Deras intresse var att komma in och leverera projektet så snabbt och effektivt som möjligt. De var inte nödvändigtvis investerade i företaget och dess framgång utöver att leverera en bra produkt. De hade också sitt eget sätt att göra saker på, kanske en standardprocess som var väl definierad eller kanske inte. Det berodde på hur länge de hade arbetat som konsulter.

De två sakerna stämde inte alltid överens. Då säger ägaren: ”Det här är processen. Nu har vi kartlagt den och det här vill jag att du följer.” Konsulten kanske håller med eller kanske inte. Då kommer man in på policyfrågor, till exempel projekttimmar. ”Du får ett visst antal timmar för projektet. Det här är processen i fasta steg som du ska gå igenom, med kontrollpunkter. Om du inte klarar det kan vi stoppa processen tidigare.” Mycket handlar om kontroller och balans.

Det finns motstånd. Jag tror att det alltid finns motstånd. Det går tillbaka till modellen för spridning av innovationer: några personer kommer att ställa sig bakom förändringen, en auktoritet beskriver processen och en del av arbetet handlar om att säga ”så här blir det”. Samtidigt måste man vara öppen för förslag och låta människor vara med och utforma det tillsammans med en. Den rätta balansen beror på situationen och på vad man kan förhandla fram.

Jag skulle gärna vilja höra hur det här känns igen för några andra i samtalet. Vilka liknande utmaningar och angreppssätt har ni sett eller använt i era egna miljöer? Eller vad skiljer sig åt?

Det finns säkert situationer där människor har varit motståndare till nya idéer, förändringar eller processer.

Vi har några kameror avstängda, så det kan vara så att människor lyssnar vid sidan av sitt skrivbord och gör annat samtidigt. Det är helt okej.

Jag har en fråga till Fred. Du pratade om kvinnan som hade allt i huvudet och att du behövde få ut informationen ur henne. Hur förklarar du för en sådan person att det här är viktigt och att hon behöver avsätta tid för att ge dig informationen? Hur kan du fortsätta lära människor att fiska när de säger att de är kaotiska och överbelastade, att de inte har en minut och att du gör saker de inte har bett om?

Det är mycket som kommer upp i huvudet. En del handlar om att förstå sin roll. Jag brukar säga att vi som projektledare inte håller i ratten. Vi sitter i passagerarsätet med kartan och säger: ”Du behöver svänga vänster här. Det är en halv mile kvar. Sätt på blinkersen så att vi svänger.” Men om de kör förbi svängen håller du inte i ratten.

Då blir ditt jobb att säga: ”Det verkar som att vi passerade svängen vi behövde ta. Det bästa vi kan göra nu är att vända och ta den andra vägen.” Men du håller fortfarande inte i ratten.

Sedan kommer de fram och frågar varför resan tog tre timmar extra och tittar på dig som om det vore ditt ansvar. Då kan du säga: ”Alla gånger jag sa att du skulle svänga vänster och du inte gjorde det behövde vi kompensera för det och ta omvägar.”

Det är den analogin jag brukar använda. En del av problemet är att de kanske inte vet eller är upptagna. De kanske inte har kartlagt allt, och det tar tid att göra det. Ofta tror de att det är färdigt, men det är det inte. De tror att människor förstår processen, men det behöver inte vara så.

I det här specifika fallet ägnade vi mycket tid åt möten eftersom hon hade så mycket på sitt bord. Jag satt ofta och lyssnade på allt hon behövde hantera samtidigt som hon skickade meddelanden till människor. Det var svårt att fånga en enda minut.

Det bästa jag kunde hoppas på var att säga: ”Okej, jag hörde några saker som jag kan omvandla till åtgärdspunkter. Jag tar hand om dem.” Eller: ”Jag har några idéer. Jag tror att det här vore bäst för mig att arbeta med. Håller du med? Om inte, vad vill du att jag ska arbeta med?”

Ibland träffades vi en hel timme och det bästa jag fick ut av det var att säga vilka två eller tre saker jag tyckte att jag borde arbeta med, genomföra dem och sedan be om återkoppling. Det var en lång process.

Om man arbetar på timbasis fungerar det så. Om arbetet är projektbaserat måste man använda ett annat angreppssätt. Jag brukar säga: ”Jag är en dyr terapeut eller vän. Om du vill använda dina timmar på det sättet kan vi göra det, men jag måste tala om för dig hur vi behöver arbeta med detta.” Om du inte svänger vänster följer jag med på resan.

Hjälpte det, Robin? Förhoppningsvis var jag inte helt ute och cyklade.

Ja, det hjälpte verkligen. Jag skulle gärna vilja ha den nya yrkestiteln ”dyr terapeut”.

Ibland är det faktiskt en träffande beskrivning. Jag har sett situationer där någon säger: ”Jag vill att du gör A.” Man arbetar med A ett tag och sedan säger personen: ”Egentligen vill jag att du gör B.” Man börjar med B och får sedan frågan: ”Varför gjorde du B?” Då svarar man: ”För att du bad mig göra B. Vi borde göra A.”

Som konsult kan jag göra det hela dagen om jag arbetar på timbasis. Jag kommer att säga att vi inte borde göra det, men jag kan ändå göra det om det är det du behöver. Är arbetet projektbaserat måste man stoppa det direkt, eftersom man annars kan kasta bort hundratals timmars arbete när kunden halvvägs igenom processen säger att det man bygger inte alls liknar det de egentligen ville ha.

Ibland säger kunder att de vill ha en snabb bil men inte vet om det är en Porsche eller Lamborghini förrän de ser den. Då kan de säga: ”Det här är vad jag vill ha” eller ”Det där är inte rätt.”

Vissa människor behöver prata hela tiden för att bearbeta saker. Då kan man låta dem prata och sedan sammanfatta: ”Det här tar jag med mig från samtalet. Rätta mig om jag har fel. Det här är de fem sakerna jag ska arbeta med och det här är de tre sakerna du ska leverera till mig.”

Jag försöker alltid sammanfatta det i ett e-postmeddelande efteråt. Jag skriver vad den andra personen ska göra och vad jag själv ska göra. Då kan jag två veckor senare säga: ”Det här var det vi arbetade med.” Jag kan också ta fram det före nästa möte och säga: ”Förra mötet skulle vi arbeta med detta. Jag påminde dig i onsdags, men du har inte skickat det. Jag fick däremot det här, så jag kan inte göra den här delen eftersom jag väntar på underlag från dig.”

Inspelningar är också användbara, särskilt tillsammans med åtgärdspunkter.

Jag är nyfiken på hur frågan om personen som hade allt i huvudet hänger ihop med något du arbetar med just nu. Handlar det om en aktuell situation eller om tidigare utmaningar med förändringsledning i dina projekt?

Jag tror att vi ibland arbetar i kaotiska projekt och vill skapa processer eller standardiserade arbetssätt som kan vara till hjälp om samma sak händer i framtiden. Ibland har vi inte en minut över för att samla in informationen från personen. Jag är också osäker på skillnaden mellan förändringsledning och projektledning, eftersom nästan vad som helst kan vara ett projekt. Kan du förklara det?

Det är en fantastisk fråga. Om man ser på definitionerna är ett projekt ett tillfälligt arbete som leder till en produkt eller ett resultat. Förändringsledning är processen att hantera förändringen.

Om vi tar ett digitalt projekt och en ny webbplats som exempel: man överlämnar en ny webbplats till någon. Vad händer då? Deras processer måste förändras. Kanske har man byggt om kontaktformuläret så att leads kommer in på ett annat sätt. Kanske har man kopplat webbplatsen till deras CRM-system med nya fält och de får ny information.

Allt detta är bra saker, men det är förändring. Därför måste vi fundera på hur vi kommunicerar förändringen och gör människor redo för den. Vad händer med personer som är motståndare till förändringen?

Jag arbetar just nu med ett projekt som jag tog över från en annan projektledare. Redan första dagen behövde jag meddela kunden att de hade gjort ett misstag värt flera miljoner kronor tidigt i projektet. Lanseringen skulle försenas och de behövde hitta mycket mer pengar för att åtgärda problemet.

De ersatte tjugo år gammal programvara som människor hade byggt vidare på under lång tid. En annan leverantör var inblandad och vi fick instruktioner om att bara prata med en mycket liten grupp intressenter. Den gruppen gav oss information och teamet arbetade utifrån den. När vi kom till användartesterna upptäckte vi att informationen faktiskt var fel, och nu måste vi göra om allt arbete.

Det fanns giltiga skäl till att de inte ville öppna informationsflödet och prata med användarna för tidigt. Om den andra leverantören hade blivit arg och tagit bort programvaran innan vi var redo att byta över skulle kunden inte ha kunnat driva sin verksamhet.

I efterhand blev det begripligt, men om jag hade varit med från början hade vi förmodligen diskuterat bättre sätt att göra det på. Jag hade också kunnat få dem att skriva under ett riskregister där det stod att de förstod risken med detta arbetssätt: att teamet inte fick den information och åtkomst som behövdes, och att de ändå godkände projektets upplägg.

Nu närmar vi oss slutet av projektet och börjar tänka på lanseringen. Kunden fick genomföra en mjuklansering. Det var i praktiken fortsatta användbarhetstester som en del av förändringsledningen. Det gav dem också möjlighet att lämna återkoppling, vilket är en viktig del av förändring. Om man känner sig lyssnad på brukar man acceptera förändringen bättre än om den tvingas på en.

Kunden ville först bara lämna över programvaran till användarna och säga ”kör”. Efter ett försök insåg vi att det var en mycket dålig idé. Vi har därför gått tillbaka till en mer formell process för att starta den mjuka lanseringen.

Vi grupperade de återstående testgrupperna och skapade en kommunikationskanal som jag kallar vänligt grupptryck. Det är bokstavligen en e-posttråd där alla i gruppen ingår. De kan se när andra ställer frågor, vilket gör att vi kan se vilka som deltar och vilka som inte gör det.

Det har varit många delar i rörelse: förändringar i programvaran, förändringar i projektgruppen och snart förändringar inom min kunds kunds företag.

När man behöver meddela någon att det har begåtts stora fel, ska man då mildra situationen och skydda sig själv så att man inte blir budbäraren som skjuts?

Jag är kontrakterad projektledare och alla vet att jag är konsult. Därför kunde jag komma in som en relativt neutral tredje part. Jag hade arbetat som rådgivare i ungefär sex månader innan jag tog över projektet. När jag kom tillbaka kunde jag säga: ”Det här är situationen som jag ser den. Vi måste hitta ett sätt att ta oss ur den.”

Jag kunde beskriva vad vi hade gjort, varför vi hade gjort det och var vi befann oss nu. Sedan kunde jag presentera väg A, B och C för att ta oss ur situationen, samtidigt som jag var tydlig med att de flesta alternativen skulle kräva en stor summa pengar.

Jag vill gärna veta om det blev tydligare var projektledning slutar och förändringsledning börjar.

När jag söker på förändringsledning på Google får jag upp stora ramverk och många certifieringar som jag inte förstår. Därför uppskattade jag exemplet med att man har färdigställt en webbplats och sedan måste förstå hur den ska uppdateras och hanteras framöver.

Det fungerar på samma sätt som projektledning. Projektledning är processen att hantera projekt och allt som ingår i dem. Förändringsledning är samma typ av angreppssätt, men med fokus på att genomföra och förankra förändringen.

Jag är nyfiken på om någon här har arbetat som projektledare tillsammans med ett förändringsledningsteam. Det finns förmodligen mycket överlappning, och jag undrar om det är möjligt att undvika känslan av att trampa någon annan på tårna.

Jag arbetade en period på en av de fyra stora konsultbyråerna. Där fanns en avdelning som erbjöd kunder förändringsledning. Arbetet handlade mycket om kommunikation, att samla in synpunkter och att skapa förankring. Ofta handlade det om att knyta ihop allt, eftersom en webbplatsombyggnad, en ny webbapplikation eller en stor marknadsföringskampanj vanligtvis bara är en del av helheten.

Någon måste övervaka hur hela helheten lanseras ur ett förändringsperspektiv. Det var intressant att se, eftersom många undrade vad förändringsledningsteamet egentligen gjorde. Men värdet fanns där: någon behövde knyta ihop delarna och se till att förändringen prioriterades.

I många projekt är det ingen som tänker på förändringsledning. Då hamnar ansvaret ofta på projektledaren. Alternativet är att projektet lanseras och misslyckas eftersom ingen tänkte på förändringen.

Jag hade en liknande erfarenhet när jag arbetade på Aramark. Vi genomförde en övergång till ett nytt CRM-system. Jag var kommunikationsansvarig i projektet och vi hade också en förändringsansvarig. Min chef frågade varför förändringsledningen bestämde att något skulle vara ett e-postmeddelande, ett möte eller en utbildning. Jag svarade att det var förändringsansvarigens jobb att avgöra vad som behövdes och att jag sedan skulle skapa det: e-postmeddelanden, webbinarier eller annat kommunikationsmaterial.

Det var gränsen mellan våra roller. Ibland kunde vi vara oense, men då fick vi diskutera det. Förändringsledningsteamet var en stor tillgång och jag lärde mig mycket av dem.

Jag skulle gärna vilja ta upp en annan berättelse med en närliggande erfarenhet av förändringsledning. Sarah, om du har en kort berättelse får du gärna dela den.

Exemplet kommer från en byrå där jag arbetade. De flesta vet vid det här laget att jag främst har arbetat på ganska små kreativa byråer, ofta med tjugo personer eller färre. På den här byrån hade vi gått igenom flera uppsägningsvågor. Vi hade inte längre något kreativt team. Verksamheten hade gått från stora kreativa projekt och redaktionellt arbete med fotograferingar till mer forskning och strategi.

Vi hade redan problem eftersom verktygen och dokumentationen hade blivit inaktuella efter en period av snabb tillväxt. De var inte längre användbara för det aktuella teamet. Även verksamhetsfunktionen hade minskat från tre personer till två och sedan till en, och jag var den som var kvar.

Jag hade inte tid att göra allt. När teamet minskar förändras behoven. En process som fungerade när teamet bestod av tjugo personer fungerar inte nödvändigtvis när man är ensam. Då blir det ännu viktigare att arbeta smartare, inte hårdare.

Ett problem var att teamet inte visste hur man använde Asana, som var vårt huvudsakliga projektledningsverktyg. Det blev otydligt vad som skulle ske i Slack och vad som skulle ske i Asana. Ett av mina kvartalsmål blev därför att skapa ett utbildningsprogram.

Det första steget var att gå igenom vad vi faktiskt hade och definiera vad som var viktigt för teamet. Som Fred sade måste man först definiera problemet innan man bestämmer nästa steg. Annars kan hela den fortsatta processen bli ineffektiv.

Moralen var låg efter uppsägningarna. Uppmärksamhetstiden var begränsad och teamet arbetade helt på distans. Ingen ville sitta i möten eller läsa ett fyrtio sidor långt Google-dokument om hur Asana och Slack skulle användas.

Därför behövde utbildningen vara uppdelad i små delar och vara relevant. Sådant som kanske var användbart för en verksamhetsavdelning men inte för teamet behövde tas bort. Jag kunde ha egna resurser med alla detaljer, men jag ville inte överbelasta teamet med information de inte behövde.

Efter att ha definierat problemet undersökte jag vad som redan fanns. Asana hade exempelvis gjort en utmärkt femminutersvideo som förklarade grunderna. Jag kunde låta teamet se den i stället för att skapa allt från början.

Sedan skapade jag ett litet utbildningsprogram i Asana. Jag gjorde ett projekt som kunde dupliceras för varje person. Varje uppgift innehöll ett kort avsnitt som tog ungefär fem minuter. De behövde inte göra allt på en gång. Det handlade om sådant som hur man kommenterar uppgifter, hur man skapar sin profil, hur man stänger av överflödiga meddelanden och hur man arbetar från inkorgen.

När man inte är van vid processer kanske man inte vet att man kan stänga av e-postmeddelanden eller undvika dubbla och tredubbla aviseringar från Asana och Slack.

Innan jag släppte utbildningen helt gjorde jag en kort genomgång. Jag förklarade att syftet var att skapa stabilitet och göra arbetsdagen enklare. Om alla arbetade på samma sätt skulle teamet kunna fungera bättre efter alla förändringar.

Jag kopierades in på alla uppgifter så att jag kunde se när de markerades som klara. Jag sade att de skulle markera varje del när de gått igenom den, men att de inte skulle göra det om något var oklart. Då kunde vi kommentera fram och tillbaka privat.

Eftersom teamet var litet och fungerade bra hade jag inte särskilt stora problem. När det kreativa teamet fanns kvar var det svårare att få människor att genomföra administrativa uppgifter. Strategi- och researchpersonerna uppskattade checklistor, medan det kreativa teamet inte ville arbeta med uppgifter eller påminnelser.

Det var också en del av deras arbetsuppgifter under kvartalet att genomföra utbildningen. Jag försöker inte vara personen som hela tiden skickar påminnelser, men det ingår ibland i jobbet. Jag försöker vara så vänlig som möjligt och lämnar alltid en tydlig dokumentation. Då kan jag visa att jag nämnde något i en kommentar för två månader eller en vecka sedan och att vi behöver få det gjort.

Det är särskilt användbart när man genomför förändringar. Om man bara säger att man har informerat någon men inte kan visa när eller hur blir det svårare att följa upp.

En sak som stod ut var att du använde ett system som teamet redan kunde relatera till. Eftersom de tyckte om checklistor byggde du förändringen på ett sätt som passade deras befintliga arbetssätt. Det skapade inte en större barriär och tvingade dem inte att ändra hur de naturligt arbetade.

Föll människor någon gång tillbaka till sina gamla arbetssätt efter att de nya systemen hade införts? Började saker samlas i backloggen, och hur hanterade du det?

I det här exemplet fick jag mestadels mycket bra återkoppling. Någon sade att den aldrig hade förstått skillnaden mellan vad som skulle publiceras i Asana och vad som skulle diskuteras i Slack. Arbetet verkade gå lite snabbare.

Tidigare hade vi en projektkoordinator vars roll var viktig, särskilt när det kreativa teamet fanns kvar. Koordinatorn såg till att sådant som hände i Slack också hamnade i Asana och att uppgifterna uppdaterades. När koordinatorn försvann hade projektledaren inte tid att gå igenom alla kommentarer eller e-postmeddelanden.

I just det exemplet såg jag inte mycket återgång till gamla arbetssätt. Det förekom lite i Slack eftersom vissa människor helt enkelt inte tycker om verktyg, och det är förståeligt. Slack känns lite som att skicka sms och är något människor redan är vana vid.

Jag har en fråga till gruppen. Något som ofta kommer upp är förändringströtthet. Man har ett projekt som drar ut på tiden, prioriteringarna förändras hela tiden och kunden kommer varje dag med något nytt som plötsligt måste göras. Har någon varit med om sådan förändringströtthet, och finns det något ni gör för att hjälpa teamet eller er själva?

I högre utbildning uppstår ibland kortsiktiga förändringar som innebär en fullständig omvälvning. Lärare kan vara särskilt utmanande att arbeta med. När pandemin kom behövde de plötsligt gå över till distansundervisning. Många motsatte sig idén och sade att deras kurser inte kunde genomföras på distans.

I sådana situationer har jag upptäckt att det bästa är att hjälpa människor att hitta det bekanta i det nya. De undervisar fortfarande, gör samma saker som i klassrummet och engagerar fortfarande studenterna. Skillnaden är att det sker på nätet. Om man hittar likheterna i situationen kan människor lättare relatera till förändringen och fokusera på det som är bekant.

På längre sikt blir det mer av ett kulturellt samtal. Om man ändrar teknik och arbetssätt hela tiden slutar människor att tro på nya verktyg, eftersom de antar att verktyget kanske inte finns kvar om sex månader. Varför skulle de då lägga mycket tid och energi på att lära sig det?

När förändringstakten är hög bryter man i praktiken förtroendet. Människor söker sig till en stabil grund: ”Det här är så jag arbetar, oberoende av vilket verktyg som råkar förändras.” Då blir det svårt att få dem att acceptera ännu ett nytt verktyg eller arbetssätt, eftersom de tänker att det bara är en tillfällig idé som försvinner om tre månader.

Förändringströtthet är verkligen en utmaning. På den byrå jag berättade om hade teamet vuxit, krympt och vuxit igen. När pandemin kom var många kunder stora teknikföretag och teamet finansierades av två stora kunder. Om deras budgetar halverades innebar det sannolikt att halva teamet måste försvinna.

Det hjälpte att omformulera varför förändringen skedde och vara realistisk med teamet innan man införde något nytt. Man kan säga: ”Jag vet att det här är jobbigt och att det kommer att ta tid. Jag förstår om det tar lite längre tid för dig att fokusera.” Det är viktigt att ta med de mänskliga aspekterna och erkänna att situationen inte är idealisk.

Samtidigt kan förändringen göra arbetsdagen enklare. I mitt exempel blev arbetet mindre förvirrande och mindre splittrat. Allt vi kunde göra för att skapa en känsla av stabilitet hjälpte.

Som projektledare kan man påverka tonen i projektet, både internt och ibland externt. Om teamet märker att man själv tycker att allt är dumt kommer de sannolikt att känna likadant. Därför behöver man filtrera sina egna tankar och känslor innan man förmedlar dem, särskilt när teamet är trött och oroligt och längtar efter något stabilt.

En sak jag vill betona är att man måste acceptera att saker tar längre tid när människor har gått igenom förändring. De behöver både anpassa sig till förändringen och lära sig nya processer. Det tar tid från det vanliga arbetet.

När många förändringar kommer samtidigt kommer arbetet att gå långsammare och produktiviteten kan minska. Det måste få vara så tills man når en punkt där teamet har återhämtat sig och förändringarna blir färre. Det går i vågor och är ofta säsongsbetonat.

Det kan också påverka motivationen. Om man känner att man får mindre gjort kan det bli demotiverande, särskilt om man jämför med tidigare perioder då man gjorde större framsteg. När alla förändringar är tänkta att hjälpa på längre sikt kan man ändå känna att de gör mer skada än nytta på kort sikt.

Därför är det viktigt att sätta tydliga förväntningar och förklara att det är okej att sakta ner medan människor orienterar sig och arbetar mot en bättre process.

Människor jämför ofta sin egen takt med vad de tror att andra gör. Det kan vara hjälpsamt att sätta tre saker på dagens lista och sedan ge sig själv tillåtelse att låta det vara tillräckligt. Jag har själv svårt för det, men ibland måste man kunna lägga arbetet åt sidan och säga: ”Jag har gjort tillräckligt i dag.”

Jag inser att vi är framme vid slutet av samtalet. Tack så mycket för att ni deltog och engagerade er. Det var fantastiskt att höra berättelser om hur andra arbetar och vilka utmaningar de har mött.

Det är värdefullt att höra att andra har samma utmaningar. Det är också bra att kunna ta med sig idéer och processer tillbaka till det egna arbetet. Förhoppningsvis finns det några lärdomar här som vi kan använda i våra egna organisationer och processer.

Vårt nästa evenemang är den 23 maj. Då arrangerar vi ett liveforum där ni kan ta med de viktigaste utmaningarna ni möter i arbetet. Vi lyfter fram dem och diskuterar dem tillsammans. Det blir liknande det här, men mer öppet. Det handlar alltså inte bara om förändringsledning utan om alla typer av utmaningar.

Tack igen och ha en fortsatt fin dag. Jag hoppas att allt går bra för er. Vi hörs i Slack. Hej då allihop. [00:55:00] [00:56:00] Tack.