Change Management: Inden vi tager hul på sagerne, så kommer der lige en hurtig disclaimer: Dette indlæg er ikke et hardcore Change Management-indlæg, hvor vi gennemgår procedurer op og processer ned.
Nej, dette indlæg er til dig, som vil stifte bekendtskab med forandringsledelse og Change Management af IT-projekter, måske fordi du ønsker, at jeres egne projekter bliver bedre modtaget i fremtiden, end de har været hidtil.
Indlægget er til dig, der ved, at successen af et IT-projekt skal måles i slutbrugernes reaktion, men som er i tvivl om, hvordan du kan bidrage til successen med gode Change Management-processer.
Hvad er IT Change Management?
Desværre er det sjældent de tekniske kravspecifikationer, der er problemet, når man vil implementere ændringer på virksomhedens IT-platform.
”Desværre” fordi man ofte kan finde en løsning på sådanne udfordringer relativt nemt. Ofte kan man programmere sig ud af problemet eller måske ændre lidt i IT-infrastrukturen, så det nye system kører glat.
Nej, det er ikke det tekniske, der er problemet. Det er brugerne.
Brugerne, der vil have tingene, som de plejer. Som ikke vil bruge tid og kræfter på at sætte sig ind i et nyt program, og som ikke orker at ændre sine vaner. Langt de fleste mennesker bryder sig nemlig slet ikke om ændringer, når det kommer til stykket.
Change Management handler ikke om projektstyring
IT Change Management (eller forandringsledelse, som det også kaldes) handler altså hverken om projektledelse, Scrum-metoder eller Kanban-boards.
Faktisk kan det nærmest siges at handle om det modsatte: om at få brugerne til at købe ind på de planlagte systemændringer og om at give brugerne en opfattelse af, at projektet er styret og kørt professionelt.
Ganske enkelt handler Change Management af IT-projekter altså om at sørge for, at projektet bliver en succes, når først det er implementeret. Der er tale om en formaliseret proces, hvor man tager slutbrugerne i ed for at skabe accept og måske ligefrem få de involverede slutbrugere til at endorse projektet over for kolleger og andre interessenter.
Hvis dette scenarie skal blive til virkelighed, skal Change Management-arbejdet dog begynde længe før, du er klar til trykke på den store røde ”implementér”-knap. Ja, faktisk starter arbejdet allerede sammen med de indledende sparkeøvelser, og længe inden det første stykke kode skrives.
Hvornår er Change Management nødvendigt?
Man kunne let forfalde til at tro, at den formaliserede styring af interessenter kun giver mening, når der er tale om større projekter, men det er faktisk ikke rigtigt.
Tænk på det på denne måde: Du tager ikke kun dine naboer i ed, hvis du vil opføre et 16 etagers boligbyggeri. De skal også høres, hvis du vil bygge en ny carport, ja, eller blot sætte et lille læhegn op i skellet. Men hvorfor? Fordi naboernes hverdag påvirkes af dine planer.
På samme måde gælder det med forandringsledelse af IT-projekter. Her handler det også mere om, hvorvidt du påvirker dine kolleger eller kunders daglige arbejdsgang, end om hvor stort projektet er.
LÆS OGSÅ: Kære IT-Chef. Er du klar? Vh. Fremtiden
Stor virksomhed, lille virksomhed – processen er den samme
Selvfølgelig er der forskel på, om din virksomhed har 500 ansatte eller 30, men faktisk er forskellen ikke så stor, som man skulle tro. I begge tilfælde handler det nemlig om, at du skal undgå at irritere dine kolleger unødigt, og at du for alt i verden skal undgå, at projektet bliver et, som alle elsker at hade.
Spiralen af dårlig omtale, som kan opstå ved kaffeautomaten, skal undviges, og i virkeligheden er der kun ét middel til at standse negativiteten: at brugerne involveres tidligt i forandringsprocessen.
Hvornår og hvordan skal brugerne involveres?
Det korte svar er så tidligt som muligt, og det spiller faktisk ingen rolle, om brugerne er kolleger, eller om der er tale om kunder.
I større virksomheder vil løsningen typisk være, at man involverer såkaldte applikationsansvarlige personer. Det kan være personer, som har ansvaret for jeres SAP-løsning eller for, at Office-pakken kører uden problemer.
Ved at sætte de applikationsansvarlige i tale allerede helt fra begyndelsen af projektet, sikrer I, at en række kernemedarbejdere føler sig hørt, og med lidt held vil disse medarbejdere blive projektambassadører, når de kommer ud i virksomheden.
På samme måde vil de applikationsansvarlige kunne agere talerør for slutbrugerne, både fordi de ofte selv er slutbrugere, og fordi de er i daglig kontakt med dine øvrige kolleger omkring netop deres applikation.
Input fra brugerne giver bedre løsninger
Hvis du forstår at involvere de applikationsansvarlige medarbejdere på rette vis – og rent faktisk lytte og justere IT-projektet ud fra deres input – opnår du to ting:
- Du undgår den onde spiral af negativ omtale om projektet
- Du kan rette børnefejl og integrationsproblemer, så udrulningen af de nye systemer forløber gnidningsfrit og med minimal gene for slutbrugerens daglige arbejde.
Naturligvis er en god Change Management ikke noget vidundermiddel, der fjerner alle problemer, som var det dug for solen. Med god forberedelse kan du måske have taget hånd om 80 procent af de problemer, som en IT-udrulning kan medføre.
Når størstedelen af problemerne er af vejen, resulterer det i, at du har langt flere ressourcer til at løse de sidste 20 procent, der måtte komme sidenhen.
Hvor meget skal vi informere?
Som du sikkert har regnet ud, så handler en stor del af et godt Change Management-flow om, at du informerer til og kommunikerer med dine brugere, inden du trækker en systemopdatering ned over ørerne på dem.
Selv simple opdateringerne af Office-pakken kan betyde timer – hvis ikke ugers – ekstra arbejde for eksempelvis en økonomimedarbejder, der har hele sin afrapportering hængt op på nøje tilpassede makroer. Hvis makroerne pludselig ikke kan køre, betyder det måske brudte deadlines, overarbejde og i det hele taget stress for hele økonomiafdelingen.
Hovedreglen er derfor: Hellere for meget information end for lidt.
Sørg for at være i god tid, når du informerer slutbrugerne om forestående opdateringer. Forklar dem, hvad opdateringerne vil betyde for netop dem, og hvorfor de er vigtige.
Hvis dine brugere har en god forståelse af, hvorfor en systemopdatering er vigtig, så har de også meget nemmere ved at være tålmodige over for de eventuelle problemer, der kan opstå.
Giv brugerne selvbestemmelse
Et andet godt trick i bogen er at lade det være op til brugerne selv at vælge, hvornår de vil gennemføre opdateringen.
Hvis en ingeniør har brug for at køre en række beregninger, som måske tager tre dage, så er det rigtig smart for hende at kunne udsætte opdateringerne til efter, beregningerne er færdige. Ellers risikerer hun at skulle forklare forsinkelsen over for en utålmodig kunde.
Når brugerne selv får indflydelse på, hvornår de vil foretage en opdatering, giver det dem samtidig en følelse af selvkontrol. De får et valg og bliver dermed ikke umyndiggjort i forhold til, hvordan de strukturerer og planlægger deres tid. Vi har sikkert alle mærket irritationen, når man tænder computeren for at stille op til en præsentation, og så pling! er der 30 minutters opdatering, som lige skal gennemføres. Tal om en dårlig start på dagen!
Alt i alt handler Change Management i IT-processer altså om, at holde sig på god fod med de brugere, som skal leve med ændringen efterfølgende. Involvér dem tidligt og lyt til deres input. Og informér alle de medarbejdere, som ikke sidder med ved projektbordet, så tidligt og så meget du kan, så de hele tiden har mulighed for at tilrettelægge deres tid efter opdateringerne. Kun på den måde undgår du de allerstørste IT-projektfejl.
