Få hjælp som ny IT-projektleder

Den gode start på et projekt

Når du har læst denne artikel, og du har fået input til din nye rolle som projektleder, så sørg for at sætte fokus på disse emner allerede fra din første dag som projektleder:

Skab overblik over roller og ansvar

Sørg for, at alle roller er besat, at alle deltagere er velinformerede og ved hvad der forventes af dem. Tag noter om de enkelte deltageres indstilling til forandringsprocessen. Brug ambassadørerne aktivt, og giv modstanderne ekstra opmærksomhed.

Din projektorganisation skal være på plads, og alle skal være parate til at udfylde deres roller. Du har lige læst om projektorganisationen, roller og ansvar. Det er der, der skal til.

Skab mening med projektet

Skab enighed om denfælles vision for projektet, så alle ved, hvorfor virksomheden bruger tid på det. Hvorfor er det vigtigt for forretningen? Hvad er formålet, og hvilke gevinster skal høstes? Og hvad er udbyttet for den enkelte person?

Gevinstafdækningen, som du læste om i sidste afsnit, er det rette værktøj.

Nogle gange er der ikke gevinster for alle, og det er okay, men det må man også være åben om, og få det til at give mening, at nogle skal hjælpe andre. Hvis du oplever modstand mod projektets formål, så skal du eskalere det til projektejeren.

Skab en projektplan

Sammen med leverandørens projektleder skal du oprette en projektplan, som viser hvad der skal ske i hvilke faser i hvilken rækkefølge. Og den skal detaljeres til en opgaveliste, hvor du går i detaljer med, hvilke aktiviteter der er under workshops, under datamigrering, under test, under uddannelse osv.

Projektplanen sørger for at du har styr på alt. Den giver dig mulighed for at være proaktiv. Og den er en referenceramme for alle, der skal deltage i projektet.

Book alle aktiviteter

Planlæg og book alt så tidligt som muligt. Hvis du ved, at der skal holdes et statusmøde om 8 måneder, så book det med det samme i alle deltagernes kalendere. Der er ingen grund til at vente. Det er proaktivitet i bedste forstand.

De skal ikke noget om 6 måneder, men hvis du venter 6 måneder og booker i næste uge, så kan de ikke. Hvis de bliver overvældede over den store mængde aktiviteter, du booker dem til i kalenderen, så er det bedre, at de opdager det nu, så du kan håndtere det i god tid.

Fastlæg processer for dokumenter og opgaver

Opgaver og dokumenter skal styres et samlet sted, der giver overblik. Det er dyrt og frustrerende ikke at have styr på referater, rapporter og opgavestatus. Tag ejerskab for det.

Brug det opgavesystem, som din leverandør sikkert stiller til rådighed, og håndhæv at alle projektdeltagerne også bruger det.

Lær kontrakten i detaljer

Du skal have styr på kontrakten fra begyndelsen af. Du skal vide, hvad der er aftalt. Kontrakten er skrevet af jurister til jurister, og det er sådan det skal være, men du er sikkert ikke jurist, og derfor kan kontrakten være svær at forstå. Hvis du ikke selv har været en del af forhandlingen af kontrakten med leverandøren, så skal du sørge for at få en grundig overdragelse i begyndelsen.

Du skal kende projektets målsætninger. Du skal vide, hvad ledelsen har af kriterier for projektets succes, og hvad styregruppen vil holdes opdateret på undervejs i processen og hvor ofte.

Kend omfanget af projektet

Du skal kende det præcise omfang af projektet. Det kalder leverandøren sikkert ”scope”. Scope betyder bare omfang, dvs den mængde af funktioner eller processer, som er omfattet af aftalen med leverandøren. Man kan populært sige, at scope er det, du har aftalt med leverandøren, at systemet skal kunne. Scope kan godt ændre sig undervejs, hvis du og leverandøren bliver enige om det, og det har som regel en konsekvens for tidsplanen og budgettet.

Måske er der en beskrivelse af scope i aftalen med leverandøren. Der er ofte også konkrete begrænsninger. Det bliver dog mere og mere almindeligt, at aftalen tager udgangspunkt i en standardløsning, og at scope således bliver ”det som standardløsningen kan”, plus nogle tilføjelser eller begrænsninger som er konkret nævnt i aftalen. Uanset hvad – som projektleder skal du kende scope indgående.

Styr budgettet fra første dag

Få styr på budgettet. Det er din økonomiske og ressourcemæssige ramme for projektet, dvs hvor mange penge du må bruge hos leverandøren, og hvor mange interne ressourcer du må trække på.

Du skal have etableret en projektplan, hvor du har overblik over ressourceforbruget, og den projektplan skal afspejle det aftalte ”scope” for projektet.

Du skal hele tiden følge op på, om projektet holder budgettet. Når en delaktivitet er afsluttet, så skal tidsforbruget flyde ind i din oversigt, så du løbende kan opgøre, om der bliver brugt mere eller mindre tid end planlagt.

Nogle ting er svære at estimere fra begyndelsen, og det er ikke dit problem som projektleder, hvis der sker afvigelser i det reelle tidsforbrug i forhold til estimerede. Men det er skidt, hvis du ikke har styr på det og statusrapporterer det undervejs. Hvis du står foran styregruppen i slutningen af projektet og lige har opdaget at både leverandøren og de interne medarbejdere har brugt dobbelt så mange timer som forventet, så står du med ansvaret. Løbende budgetopfølgning er nøglen.

Okay – alle disse ting får du ikke fikset på din allerførste dag som projektleder – men det er ting, du skal sætte fokus på helt fra begyndelsen – og du skal have styr på det hele, inden projektdeltagerne begynder at bruge en masse tid på konkrete aktiviteter. Her er din tjekliste:

• Projektorganisationen er fastlagt og alle kender deres ansvar
• Målsætningerne for projektet står lysende klart for alle
• Projektplanen er klar, og alle kan bruge den som reference
• Alle aktiviteter er booket i deltagernes Outlook-kalendere
• Alle ved, hvor man styrer opgaver og gemmer dokumenter
• Du har sat dig ind i kontraktens indhold i detaljer
• Du kender det funktionelle og procesmæssige omfang af projektet
• Du har styr på budgettet og opdaterer det hele tiden

De primære værktøjer

Vi håber, at du snart får sat mange krydser i tjeklisten. Til at hjælpe dig på vej, så vil vi i dette afsnit lægge nogle værktøjer i din projektleder-værktøjskasse. Vi har allerede nævnt nogle af dem, men vi skal lidt mere i dybden med de vigtigste værktøjer for projektlederen.

Projektplan

Som projektleder skal du have en projektplan. Det er dit primære styringsværktøj, som du vedligeholder i fællesskab med dit projektteam, både internt i organisationen og eksternt hos leverandøren.

Projektplanen viser, hvilke aktiviteter der skal foregå hvornår og med hvem.

Projektplanen skal være så detaljeret som mulig. Typisk kan den være ret detaljeret for de kommende 3 måneder, og lidt mere overordnet for de næste 3-6 måneder, og den flytter sig naturligvis hele tiden, efterhånden som tiden går, aktiviteter afsluttes, nye planlægges, og I får mere indsigt undervejs.

Projektplanen er et levende dokument, der hele tiden skal opdateres.

Det er i projektplanen, at alle dine kolleger kan se, hvad de skal deltage i, og hvor meget tid de skal afsætte til det. Planen skal fx vise, at Lise skal deltage i en workshop på torsdag i næste uge, der forventes at vare i 4 timer, men også at hun som forberedelse skal læse et dokument inden workshoppen, som er estimeret til 3 timer, og at hun efterfølgende har en opfølgningsopgave, som forventes at vare 2 timer. Sørg for at få det hele med i planen, så deltagerne ikke møder uforberedte op.

Læg også leverandørens ressourcer ind i din projektplan. Du kan markere interne og eksterne ressourcer med to forskellige farver i projektplanen.

Mange styrer projektplanen i Excel, men det kunne også være et helt simpelt Word-dokument. Du kan også kaste dig ud i Microsoft Project, hvis du vil styre afhængigheder og have flere værktøjer og visualiseringer.

Det vigtigste er, at projektplanen er up-to-date og delt, så det fungerer som et samarbejdsværktøj og som et kommunikationsværktøj.

Opgaveplan og milepæle

Din leverandør kommer ganske sikkert med en projektmodel, som projektet skal følge, og den er opdelt i faser og indeholder en række aktiviteter. Når du får den i hånden, så kan du begynde at planlægge alle aktiviteterne i projektet – grov-planlagt på langt sigt og fin-planlagt på kortere sigt.

Begynd med at fastlægge projektets milepæle. Der er en go-live dato i sidste ende, men projektplanen vil også indeholde flere milepæle undervejs. Sæt dato på milepælene. Selv om det måske ikke er besluttet, hvad deadline er, så er det alligevel godt at have konkrete datoer at pejle efter.

Der skal helst være mange milepæle af pejle efter undervejs. Det kan være svært at vide, om man er foran eller bagefter planen, hvis der ikke er nogle holdepunkter.

Med datosatte milepæle er det meget nemmere at opdage, hvis tidsplanen skrider.

Book så meget som muligt i kalenderen. Som projektleder bliver du meget erfaren i at booke kalendere, for det kommer du til at gøre tit. Læg alle møder i kalenderen hurtigst muligt.

Der er måske en lille stemme inden i dig, som siger at der er fjollet at invitere i lang tid i forvejen, men den skal du ignorere. Når kollegerne kommer og siger ”hold da op, jeg fik mange mødeindkaldelser fra dig i dag”, så skal du bare smile.

Det er meget nemmere at booke folk til et møde om 3 måneder, end at vente 3 måneder med at booke dem til et møde.

Om 3 måneder har alle god tid. I næste uge har ingen tid.

Så det gør dit arbejde meget nemmere at være i god tid. Det samme gælder i øvrigt den lavpraktiske opgave med at finde et ledigt mødelokale.

Tip om sammenhængende planlægning

Hvad angår workshops, så har din leverandør sikkert en klar holdning til, hvordan de tidsmæssigt skal afvikles. Men hvad angår de opgaver, som dine projektdeltagere skal løse på egen hånd – fx test eller dataoprydning – der vil vi anbefale, at du booker deltagerne til sammenhængende dage, og gerne sammen.

Det er meget mere effektivt, hvis du fx booker 3 sammenhængende dage med de folk, der skal teste løsningen, hvor de sidder i samme lokale og udfører testen sammen. Så kommer de ind i et flow og en fokus, der er mere effektiv, end hvis de er booket hver for sig et par timer hist og her.

Leverandørens opgavesystem

Sørg for at bruge de værktøjer til styring af projektet, som din leverandør stiller til rådighed. Måske vil du eller nogle kolleger føle, at det er besværligt at lægge alt ind i et opgavestyringssystem, men den følelse skal I sætte jer ud over, for det giver virkelig stor værdi at have styr på projektet i et professionelt værktøj.

Din leverandør skal stille et opgavesystem til rådighed, som I kan samarbejde i. Det er ikke godt nok med vedhæftede filer i emails eller en dropbox-folder.

I opgavesystemet kan du samle alle dokumenter og tildele opgaver til personer, og du kan styre fremdriften i, hvad deltagerne udfører, og hvornår de udfører det. Og de kan melde en status tilbage, og du kan nemt rapportere til styregruppen.

Dokumentation

Som projektleder skal du sikre dokumentation af alle beslutninger i projektets forløb. Al denne dokumentation skal være skriftlig, og den skal helst samles i det opgavesystem og projektstyringssystem, som din leverandør stiller til rådighed. På den måde bliver dokumentationen til en fælles referenceramme i samarbejdet.

Dokumentation er fx rapporter efter workshops. Det er korrespondance. Det er referater af statusmøder. Det er godkendelser af test cases. Og så videre.

Det er ganske vigtigt, at du nyder at sikre denne dokumentation, for dagligdagen som projektleder kan nogle gange føles som: referat, godkendelse, referat, godkendelse, referat, godkendelse …

Dokumentationen sikrer enighed om alle beslutninger. Du og leverandøren er blevet enige på et møde, men alligevel har I måske forskellige opfattelser af enigheden bagefter.

Et referat hjælper med at harmonisere forskellige opfattelser. Sandheden bliver altid mere konkret af at blive nedskrevet.

Dokumentation er især vigtig, når projektet afviger fra den oprindelige plan. Når en procesejer godkender en ændring, der har indflydelse på tidsplanen eller budgettet, så skal det dokumenteres.

Når testcases giver fejl, så er det vigtigt at dokumentere præcis, hvad der er blevet testet, og hvad resultatet var.

Når du står foran styregruppen og argumenterer for en udsættelse af driftsstart, så er det vigtigt at kunne dokumentere, om behovet skyldes behovsændringer eller fejl. Og hvis du kan dokumentere, at kun 60% af de planlagte test er gennemført, og at 35% af dem har resulteret i en fejl, så kan styregruppen sikkert godt se behovet for at gennemføre hele testen inden driftsstart.

Hvis styregruppen alligevel insisterer på at gå i drift til tiden, så kan du med dokumentationen i orden sætte præcise tal på, hvor mange fejl der kan forventes at skulle håndteres i dagene efter driftsstart. Så kan du argumentere for, at der skal være et meget større beredskab ved driftsstart til at håndtere fejlene.

Dokumentation trumfer holdninger. Dokumentation er den gode projektleders bedste trumfkort.

Risikolog

En risikolog er et dejligt, konkret redskab, som er lidt overset.

Nogle gange får projektlederen slet ikke lavet en risikolog, men de fleste gange får man lavet en i begyndelsen af projektet, hvor man har masser af gå-på-mod, og så risikerer den at blive et statisk dokument, som man ikke får vedligeholdt.

Det er et dejligt simpelt værktøj. Du noterer alle de potentielle risici, du kan få øje på i projektet, og så giver du dem en score for, hvor stor sandsynlighed der er for den enkelte risiko er.

Vurderingen af sandsynligheden for en risiko er ofte på en skala fra 1 til 5, men du kan egentlig vælge præcis den slags vurdering, som du foretrækker. Der skal bare være en vurdering, og den er baseret på din mavefornemmelse, og det er okay.

På samme måde giver du bagefter en score for, hvor stor konsekvens hver risiko vil have.

Det skal være risici af en vis betydning, for risikologgen skal ikke være alt for lang. Hvis det er noget, der bekymrer dig, så du har lyst til at huske, at du skal holde øje med det, så skal det med i risikologgen.

Lad os tage et par nemme eksempler:

• Det kan være, at en nøglemedarbejder bliver syg på en workshopdag. Sandsynlighed er høj, men konsekvensen er lav.
• Det kan være, at den vigtigste procesejer siger op midt i projektet. Sandsynlighed er lav, men konsekvensen er stor.

Vurderingerne bliver relative, og hvis du vil prioritere risici i forhold til hinanden, så ganger du de to tal sammen til en samlet score.

Som projektleder skal du præsentere risikologgen for styregruppen. Det er det samlede risikobillede lige nu, som de skal forholde sig til. Risici med en score på 25 vil de have stor opmærksomhed på, men dem med en lille score interesserer de sig sikkert ikke for.

Det er ikke dig som projektleder, der skal løse risici, og det er principielt heller ikke dig, der skal beslutte, hvad der skal gøres ved dem.

Din opgave er at bringe risici frem i lyset, give et retvisende billede af dem, hjælpe med at prioritere, og præsentere mulige handlinger for at imødegå risici.

Styregruppen kan vælge, at de ikke vil gøre noget, håber på det bedste, og løser udfordringerne som de dukker op. Det er okay, hvis det blot er en beslutning de træffer med åbne øjne. De kan også vælge at uddele ansvar og bede om handling fra medarbejdere, som kan minimere konkrete risici.

Du bør udarbejde din risikolog sammen med din leverandør. Hvis du opdager risici på leverandørens side, så skal de med i risikologgen. Og leverandøren har også et ansvar for at bidrage til risikologgen. Det kan være, at de kan få øje på risici, som du ikke har på radaren.

Det kan være, at de synes, at du har afsat for få ressourcer til test, men du synes, at der er afsat alle de timer, som kan lade sig gøre. Det giver anledning til en god snak om, hvad det rette niveau er, og hvad de potentielle konsekvenser kan være. På den måde kan en risikolog være et værktøj til at afstemme forventninger og blive enige.

Det er en god idé at udpege en risikoansvarlig for hver risiko – dvs den medarbejder, som har pligt til at tage initiativ for at imødegå den pågældende risiko. Så ved du, hvem du skal følge op på, og den risikoansvarlige selv ved, at vedkommende har fået tildelt et ansvar.

På den måde bliver en risikovurdering til handling.

En risikolog er rygdækning for projektlederen.

Du risikerer ikke, at nogen senere påstår, at du skulle have gjort noget. Hvis du har noteret risikoen, og styregruppen har besluttet, hvilken handling der skal tages, så er det svært at pege fingre ad nogen.

Men den rigtig gode fordel er, at en risikolog skaber fokus, der får færre risici til at blive til virkelighed.

Projektlederens karaktertræk

En projektleder er en person af en bestemt støbning. Én ting er, at din værktøjskasse indeholder de rette planer og dokumenter, men den succesfulde projektleder har også en bestemt indstilling til arbejdsopgaver og personlige relationer.

Lad os blive konkrete med det samme. Der er fem karaktertræk, vi gerne vil tale om, og de kommer her:

1. Frygtløs som uerfaren projektleder

Som projektleder er du nødt til at være en smule frygtløs. Nogle gange skal du have ledelsen i tale, og du skal have den til at mene noget bestemt, eller kommunikere noget for at gøde jorden for dig. Andre gange skal du holde fast i holdninger, som er ubelejlige for ledelsen, og når du står skoleret foran ledelsen eller styregruppen, så kan det være lidt intimiderende at sætte sig igennem over for alle de mennesker med mange stjerner på skuldrene.

I de situationer må du mønstre lidt tapperhed. Det er bedre at være ekstra proaktiv og lidt irriterende i begyndelsen, end at skulle håndtere forsinkelser, forglemmelser og misforståelser senere i forløbet.

Det bliver lettere, efterhånden som du får mere erfaring med projektledelse – og også med din anciennitet i virksomheden. Hvis du er ny i projektlederrollen, så er du nødt til at kaste dig frygtløst ud i arbejdet og gøre det nødvendige, selv om det er lidt ubelejligt for cheferne.

Din projektejer skal gerne kunne hjælpe dig i denne situation. Projektejeren er typisk på samme niveau som de ledere, du er tilbageholdende med at udfordre eller bare booke.

2. Vejled dine projektdeltagere

Du skal tænke på, at dine procesejere er ikke erfarne procesejere. Afdelingschefer og projektdeltagerne har en travl hverdag med helt andre funktioner. De ved ikke nødvendigvis, hvad det kræver at indgå i et IT-projekt. De vil konsekvent undervurdere opgavernes omfang, og det skal du hjælpe dem med ikke at gøre – gerne så konkret som muligt – og med en positiv og konstruktiv indstilling.

Det kan være, at det er første gang, at du har rollen som projektleder, og det er sikkert også første gang for de fleste af dine projektdeltagere, at de er med i et IT-projekt.

Book dem i deres kalender, send invitationer, send agendaer, afstem forventninger, gensend materiale, send påmindelser – og sørg for at de kan bruge projektplanen som reference, når de er i tvivl om noget. Du må ikke lade dig irritere, hvis de ikke forstod budskabet første gang – det er et almindeligt menneskeligt træk – og du har naturligvis ikke noget imod at gentage dig selv, fordi du har en så godmodig og positiv projektledersjæl.

3. Vær tids-pessimist

Som projektleder skal du være tids-pessimist. Det er vigtigt, fordi alle andre typisk er optimister, og hvis du også er tids-optimist, så skrider tidsplanen hurtigt.

Du kan ikke lægge tidsplanen og booke opgaver efter en ideal-situation, hvor alt går godt – den utopiske situation, hvor intet bliver forsinket.

Der er ikke nogen, der bliver syge – heller ikke deres børn. Der er ingen, der pludselig skal tage sig af hasteopgaver i virksomhedens drift. Der er ingen, der laver fejl, så de er nødt til at lave opgaven igen. Der er ingen, der siger op undervejs. Der er ingen, der melder sig ud af projektet undervejs – eller bliver stressede. Der er ingen, der bliver fyret, eller ansat, eller flyttet. Der er ingen, der nedprioriterer projektopgaverne, og alt bliver gennemført perfekt til tiden.

Er det ikke en dejlig verden at leve i? Jo, det er det, men det er en urealistisk verden, og du må ikke planlægge efter, at alt går godt. Du er nødt til at planlægge efter, at der er uforudsete forhindringer undervejs. Ellers skrider tidsplanen lige med det samme.

Du skal også være lidt pessimist på de enkelte projektdeltageres vegne.

Hvis deltageren siger: ”Jeg skal nok få testet det hele i næste uge. Du behøver ikke booke mig,” så kan du være sikker på, at samme person om et par uger siger: ”Jeg har desværre ikke nået at teste.” Det slår aldrig fejl.

Du er nødt til at tage styringen og insistere på, at du booker personen onsdag, torsdag og fredag i næste uge – i øvrigt sammen med to andre, som skal teste andre områder, men det forpligter mere, at de skal mødes og arbejde sammen. Du skal insistere på at booke dem, og du skal også booke et mødelokale til dem, og hvis du kan begynde hver dag med, at du har wienerbrød med til dem, eller at du kommer med test-slik kl. 14 og hører hvor langt de er nået, så bliver det endnu mere socialt forpligtende for dem at holde aftalen.

Jo kedeligere en aktivitet er for deltagerne, des flere godter kræver det. Det kan godt være, at test ikke er sjovt, og det skal vi ikke påstå at det er, men vi kan godt gøre det hyggeligt. Det hjælper.

Du tænker måske, at de er jo voksne mennesker, og de kan vel selv finde ud af at løse den opgave, som de har lovet at løse. Ja, men de får ikke gjort det. Selv med de bedste intentioner kan det være svært at overskue alt på egen hånd. Det kender vi nok alle sammen. Du er nødt til at have den indstilling, at I er i samme båd.

4. Vær proaktiv med alt

Som projektleder skal du tænke længere frem end de fleste andre. Det er du nødt til, fordi noget af det sværeste i at drive et projekt er at få folk frigjort på de rette tidspunkter, og at få dem til at påbegynde opgaver i god tid.

Jo længere, du kan planlægge fremad og få varslet folk om, at der kommer en opgave, des nemmere er det at få ting til at lykkes. Hvis du er i sidste øjeblik, så kommer du til at bruge alt din tid på planlægning.

Datamigrering er et godt eksempel. Det tager længere tid, end de fleste forventer, og derfor skal de begynde i god tid og sætte rigeligt med tid af til opgaven. Datamigrering er ikke en svær opgave, men det er en opgave, som bliver undervurderet. Folk tænker, at det bare er noget med nogle udtræk i Excel-ark, som skal filtreres lidt, men beslutningerne viser sig altid at være svære at træffe.

Du kan lige så godt prikke til den sovende drage og få sat gang i alle de store overvejelser og svære beslutninger med det samme.

Hvis man fx gerne vil migrere de aktive kunder, så opstår der straks et spørgsmål om, hvad det betyder at være ”aktiv”. Er det dem, der har fået en faktura inden for x måneder? Eller dem, som har en udestående saldo? Er der en petitessegrænse for hvor meget kunden skal have købt? Det ender altid med at blive en politisk beslutning.

Hvad så, hvis man vil migrere de seneste produktionsordrer? Skal kriteriet blot være et datofilter? Hvis I for 5 år siden har leveret en specialdesignet del til en havvindmølle, der har 20 års levetid, skal I så om 10 år kunne finde den oprindelige produktionsordre for at kunne genproducere den som reservedel? Det ender igen med at være en politisk beslutning – eller en møjsommelig manuel vurdering af hver enkelt post i regnearket.

Man undervurderer altid, hvor lang tid detaljerne tager. Derfor skal du som projektleder hjælpe deltagerne til at begynde i rette tid og have afsat nok tid. Den politiske diskussion om, hvordan man definerer en ”aktiv” kunde kan tages allerede i dag. Den behøver ikke afvente et IT-projekt. Men det bliver kritisk, hvis man midt i IT-projektet ikke har formået at komme til enighed. Efter alle beslutningerne er truffet, så tager selve datamigreringen faktisk ikke så lang tid.

Der er mange ting, man kan forberede i god tid. I slutningen af projektet skal deltagerne teste det nye system, inden det bliver taget i brug. Til det anvender man en test-case, som er en beskrivelse af hvad man gør i en arbejdsgang. Det kan man sagtens forberede i god tid.

Medarbejderne kan allerede i dag begynde at skrive ned, hvad de gør i hverdagen trin-for-trin. Hvad lægger de ind i det gamle IT-system? Og hvornår er der noget, der er svært i løbet af en almindelig dag? Begynd tidligt med at tage noter, for så har testcasen nærmest skrevet sig selv, og så bliver det ikke en tung opgave, der rammer som en bombe, når det nye system pludselig skal testes, og deltagerne bliver fanget på det forkerte ben og kun kan huske det halve af, hvad de plejer at gøre i hverdagen.

Nu er datamigrering og testcases kun nogle eksempler. Der er mange aktiviteter i et projekt, som kan overraske, og der er mange tiltag, man kan sætte i gang i god tid. Hvis du og din organisation ikke er meget erfarne i IT-projekter, så skal du læne dig op ad din IT-leverandør.

De kan bidrage med erfaring om, hvad du skal være opmærksom på, og de kan advare dig om, hvad andre virksomheder har oplevet udfordringer med. For IT-leverandøren er de færreste af dine udfordringer overraskende.

Begynd med at spørge din leverandør, hvilke udfordringer de helt ærligt forventer, og hvad de synes du skal prioritere. Det kræver en vis ærlighed fra leverandøren, for det kan indebære kritik af din virksomheds beslutninger eller bemanding, men alle er bedst tjent med, at de tør sige sandheden, og at du lytter med åbent sind.

5. Sig alt højt med kærlighed

Som projektleder skal du elske at snakke med mennesker, og du skal være nysgerrig på menneskers holdninger og adfærd. Du skal forvente det bedste, men altid spørge aktivt i stedet for at antage. Og du skal ikke blive forurettet, hvis andre ikke har gjort hvad de skulle.

Dit stærkeste værktøj til forandring er kommunikation. Send kærlige opdateringer til deltagerne. Tit og ofte. Svære emner skal tages op med det samme, så der er god tid til at håndtere dem. Problemer skal italesættes med det samme, så de kan blive løst uden stress. Det er kærligt og hensynsfuldt at tage et svært emne op, selv om det føles som at træde på en øm tå. Du må gerne være høflig og diplomatisk, men du må ikke have berøringsangst over for den svære kommunikation.

Du skal nyde at bruge kommunikation som dit vigtigste redskab. Og det er så stort et emne, at det har fået sit helt eget kapitel. Det kommer her:

Kommunikation

Det magiske problemknuser-værktøj

De 5 vigtigste aktiviteter som projektleder er: planlægning, planlægning, kommunikation, kommunikation og planlægning. Det er sagt med et smil, men vedholdenhed i både planlægning og kommunikation er utrolig vigtig.

I alle dine opgaver skal du stræbe efter at være mere proaktiv, gentage hyppigere, og gå i flere detaljer – end du umiddelbart forventer.

Nu skal vi snakke om kommunikation, som er det magiske problemknuser-værktøj inden for forandringsledelse (som vi går i dybden med senere).

Vær proaktiv. Begynd at involvere deltagere i projektet, lang tid før det er nødvendigt. Det kan godt være, at Julius først har en aktiv rolle, når han skal modtage slutbruger-undervisning af en superbruger, men hold ham informeret om projektet fra begyndelsen af, for så bliver alt meget nemmere.

Projektet er en forandringsproces, og forandringer af både holdninger og adfærd tager lang tid. Det kan ikke bare fikses på en undervisningsdag, og så har Julius en anden holdning og en anden adfærd dagen efter, vupti-bum.

Direktøren kan heller ikke nøjes med at fortælle på et firmamøde, at der kommer et nyt IT-system, og at det bliver godt. Det betyder ikke, at alle medarbejdere dagen efter glæder sig til det nye system, fordi de nu ved, at det bliver godt, fordi det har direktøren sagt. Sådan fungerer mennesker ikke. Sådan fungerer forandringsprocesser ikke.

Praktiske værktøjer til kommunikation

Hvordan kan du kommunikere i praksis? Du kan fx have et intranet, hvor du løbende opdaterer kollegerne om fremdriften i projektet og fortæller om aktiviteterne. Det kan fx være godt at fortælle, at der konkret er blevet afholdt en workshop om et bestemt emne, og hvad resultatet af workshoppen var. Det giver en følelse af at være tæt på processen. Det er måske blot en stemningsrapport med et billede, der viser de glade deltagere, men modtagerne kan mærke, at projektet er i fremdrift, og de føler sig velinformerede og inkluderede. Det imødegår al den usikkerhed og frygt, der kan opstå i medarbejdere, der føler sig uden for processen.

Nogle medarbejdere tænker, at hvis chefen holder møde, så diskuterer de sikkert, hvor mange der skal fyres. Men måske diskuterer de blot, hvordan man skal definere aktive kunder, eller om 5 år gamle produktionsordrer på dele til havvindmøller skal migreres over i det nye system.

Du tænker måske, at du ikke vil spilde deres tid, når de ikke har en aktiv rolle, men medarbejdere, der står uden for et projekt, der ender med at blive forretningskritisk, har det med at føle sig oversete. De føler sig mindre respekterede. De føler, at deres rolle i organisationen er faldet i værdi. De føler, at deres indsats er mindre anerkendt. Og når det har ulmet i deres hoveder i et stykke tid, så føler de sig fremmedgjorte, og arbejdsglæden daler, og så spørger de deres chef, hvorfor de er blevet sat på B-holdet.

Du synes sikkert, at det lyder overdrevet, men det er det ikke, og du vil blive overrasket over, hvor stor en forskel du kan gøre med et ugentligt nyhedsbrev.

Hvis virksomheden har et nyhedsbrev eller en anden kommunikationskanal, der skubber information ud til medarbejderne, så sørg for at få en fast klumme i det medie. Du kan også oprette dit eget nyhedsbrev, eller du kan have et fast indlæg på et firmamøde, eller tage rundt på afdelingsmøder og give en kort opdatering, eller du kan printe et nyhedsbrev og hænge det op ved kaffemaskinen. Det kan være hvad som helst. Bare sørg for at koble dig på de nyheds-feeds der fungerer i virksomheden.

Hvis Pernille skal deltage i en workshop om 4 uger, så har hun ikke noget praktisk at bruge information om en workshop på et andet område til. Men hun kan se, at serien af workshops kører, og at det er en succes, og at deltagerne er glade. Hun kan mærke, at hun er en del af noget stort. Så begynder hun også at se frem til, at det bliver hendes tur. Og hun går ind i det med en mere positiv indstilling.

Det er intern marketing.

Fejring af succes

Ud over hverdagens kommunikation, så skal du også tage initiativ til at fejre succeserne undervejs.

En virksomhed, der gik i drift med et nyt forretningssystem, optog en lille video af den første ordre, som kørte igennem systemet. Ordren kom ind fra webshoppen,
og lagerchefen kunne se, at ordren blev frigivet til plukning, og så fulgte video-
kameraet lagermedarbejderen som plukkede den første ordre ude på lageret, og han havde en hale af procesejere og medarbejdere gående efter sig, som skulle følge den store begivenhed. Videoen blev delt internt som en fejring af, at projektet var succesfuldt i mål.

En anden virksomhed så frem til at afskaffe fysiske papirer ved at indføre et nyt forretningssystem, og da det gik i drift, så samlede de alle medarbejdere til en fejring med en stor kage, og så pakkede alle medarbejderne papirerne i flyttekasser og bar dem ud. Det var en manifestering af, at målet med projektet var nået: Farvel til papir. Vi filmede det hele for at kunne dele oplevelsen med alle og festligholde begivenheden.

Det er nogle gode eksempler på, hvordan virksomheder har valgt at fejre succeser. Mindre kan også gøre det, og en kage og en hjertelig tale har også en stor effekt. Opmærksomheden er som regel det vigtigste.

Men det er ikke kun, når projektet er i mål, og det nye system går i drift, at du skal fejre succesen. Der er masser af milepæle undervejs i projektet, som du kan fejre, og det hjælper med til at holde gejsten og momentum oppe.

Selv om det blot bliver til en hurra-email, hvor du anerkender de kolleger, der har gjort en indsats, eller du giver flødeboller en onsdag eftermiddag, hvor milepæl 27 er nået, så sørg for at fejre milepælene undervejs.

Modstand

Nu bliver det lidt mere alvorligt. Nu skal vi snakke om, hvad der sker, hvis du ikke lykkes med kommunikationen, og der ikke er noget at fejre med en hurra-email. Nu skal vi snakke om modstand – og lad os begynde med at konstatere, at modstand vil forekomme, så du støder sikkert på det i større eller mindre grad.

Hvad gør du, når du møder modstand?

Hvad skal du gøre, når du møder modstand? Fx hvis der er en procesejer, som ikke prioriterer at afsætte den nødvendige tid til projektet.

I den situation er det ret almindeligt at have fokus på fremdriften. Det er forståeligt, for hvis ressourcerne bliver knappe, så bliver projektet forsinket, og så ender du med at skulle stå skoleret for styregruppen. Derfor vil dit første instinkt være at opretholde fremdriften, fx ved at få andre til at bidrage, ved at træffe nogle hurtige beslutninger, eller ved at du selv smøger ærmerne op. Men det er en skidt idé. Du er nødt til at stoppe op.

Hvis procesejere udviser modstand, så skyldes det måske, at de ikke har købt 100% ind på projektet, eller at de ikke prioriterer tiden til det.

Det kan skyldes, at de ikke har den nødvendige forståelse for, hvorfor virksomheden ønsker at gennemføre projektet, og hvilke gevinster projektet skal opnå. De forstår ikke, hvorfor projektet også er vigtigt for dem selv. De ved ikke ”what’s in it for me”.

Det skyldes typisk, at den forudgående forandringsproces ikke har været god nok – altså den proces med behovserkendelser, formulering af forretningsmæssige målsætninger og erkendelser af nødvendige forandringer, som har ført ledelsen frem til beslutningen om at indføre et nyt IT-system.

Det er et problem. Det er mere almindeligt, end man skulle tro, men det er et potentielt stort problem for dig i projektlederrollen, så du skal tage det alvorligt. Hvis du møder modstand fra procesejerne, så skal du teste, om det skyldes manglende commitment, og i så fald hvorfor.

Du skal sige det højt til din projektejer for at få løst den konkrete udfordring, og du skal løfte problemet på et mere abstrakt niveau til styregruppen, så de ved, at der i organisationen er mangel på forståelse af projektets formål, berettigelse og prioritet.

I praksis er du nødt til at stoppe de aktiviteter, I har gang i, og træde nogle skridt bagud og tage en snak om, hvad formålet er med projektet, med de konkrete personers deltagelse og med de aktiviteter, som har skabt modstand.

Det går måske ud over fremdriften på kort sigt, men det er nødvendigt. Ellers vil du i sidste ende have et projekt, som er halvhjertet gennemført. Hvis procesejeren begynder projektet med at udvise modstand, så vil det smitte af på vedkommendes medarbejdere, og de vil ikke blive ordentligt informeret, de vil nedprioritere projektet når de har travlt, de vil ikke engagere sig i workshops, de vil ikke føle at det er vigtigt at teste, de vil gøre modstand når de skal ændre arbejdsgange i praksis.

Procesejere sender modstand videre til deres medarbejdere, og det er starten på en ond cyklus, som ender med et dårligt IT-system og besværlige arbejdsgange.

Det ville være godt, hvis du kunne imødegå eventuelle problemer helt fra begyndelsen. Så, hvordan kan du som projektleder vurdere, om projektet er godt nok forankret i ledelsen og hos procesejerne, så du kan udgå at løbe ind i problemer undervejs?

Det er et svært spørgsmål, for hvis du spørger direkte, om projektet er forankret hos alle ledere, så får du et simpelt svar: ”Ja, ledelsen har besluttet, at projektet skal gennemføres”. Men du har behov for at teste, om de alle sammen har forstået projektets mål og berettigelse helt inde i hjertet. Du er nødt til at syreteste.

Begynd med at give et indtryk af, hvor meget tid, der skal bruges på projektet – både til styregruppen og til procesejerne.

Vi plejer at sige, at din organisation skal bruge mindst lige så meget tid på projektet som IT-leverandøren. Så du kan tage udgangspunkt i timebudgettet fra leverandøren, og måske skal du tilføje en lille buffer. Så kan du opdele timebudgettet i afdelinger efter hvor meget hver afdeling cirka fylder i projektet – gerne fordelt på faserne i projektets tidsplan, så det er nemmere at planlægge ressourcetrækket.

Når du derefter går til fx Økonomichefen som procesejer for Økonomi og præsenterer et timebudget for projektdeltagere fra Økonomiafdelingen i projektets forskellige faser, så bliver det dejligt konkret, og så trykker du sikkert på et ømt sted, fordi de timer sikkert ikke er til rådighed uden videre.

De afdelinger, som er driftsafdelinger, har typisk ikke overskydende ressourcer, så de har ikke tid til at lave andet end drift. Der kan du syreteste engagementet i projektet ved at gøre timeforbruget meget konkret. Projektet er nødt til at blive prioriteret i forhold til driftsopgaverne.

Den samme øvelse skal du foretage med styregruppen på overordnet niveau. Hvis projektet skal gennemføres i november og december, og juletiden er jeres højsæson, så kan du fremvise det samlede timebudget og spørge, om det er realistisk at prioritere de nødvendige timer til projektet. Hvis svaret er: ”det må vi lige finde ud af”, så er forankringen ikke på plads. Så er forandringsprocessen ikke i gang. Og det ender med at blive dit problem i praksis, når dit projekt taber i prioritering til julehandlen.

Hvis procesejerne slet ikke har hørt om projektet

Du møder måske procesejere, som er helt uvidende om projektet. De har fået at vide at de skal deltage, men de ved intet om det.

Det hænder ofte, at ledelsen træffer en velinformeret beslutning om at indføre et nyt IT-system, men at beslutningsprocessen har foregået internt i ledelsen. De har ikke fået inddraget alle deres primære interessenter, som er afdelingslederne.

Hvis du som projektleder får fornemmelsen af, at det er tilfældet, så skal du hjælpe ledelsen med at opstarte forandringsprocessen omhyggeligt, inden du sætter afdelingscheferne eller deres medarbejdere i arbejde.

Du skal have de uvidende afdelingschefer til bordet sammen med ledelsen. Vi kan kalde det et kick-off, og egentlig er det altid en god idé at afholde et kick-off før et større projekt, for det sikrer at alle deltagere har samme niveau af viden, og at de har de samme forventninger. Det er måske også en opgave, som din leverandør kan hjælpe med at facilitere.

Ledelsen skal fortælle om deres beslutning og målsætninger, og du skal fortælle om projektets faser, aktiviteter og tidsplan. Deltagerne skal også have information om, hvad der forventes af dem i projektet.

Hvis projektet er helt ny viden for nogle af afdelingscheferne, så vil de have en masse at sige om det, og det skal de have mulighed for at få luft for. Ledelsen skal være til stede, så de kan lytte til holdninger, indvendinger og bekymringer – og give passende svar.

Når man træffer beslutninger uden at have haft folk med på rejsen, så skaber det altid støj. Det er en naturlig reaktion. Folk føler måske, at de har fået trukket noget ned over hovedet.

Så, hvis nogle deltagere hører om projektet første gang på kick-off, så kan du godt forberede ledelsen på, at de skal håndtere modstand på mødet. Men de må ikke bare bruge deres ledelsesret til at lukke munden på bekymrede deltagere. De må ikke blot sige: ”Beslutningen er truffet, og nu skal vi videre.” Deltagerne skal have lov til at lufte bekymringerne. Skriv dem på tavlen. Gå bordet rundt og få alle til at nævne deres største bekymring, og lad ledelsen kommentere dem.

Der viser sig ofte at være en rød tråd i deltagernes bekymringer og indvendinger, og ofte bliver den første konklusion ganske simpelt, at man ikke har snakket nok sammen i organisationen i den hidtidige proces. For alle problemer kan man gå tilbage og finde et tidspunkt, hvor to mennesker ikke talte nok sammen.

Det næste problem er som regel ressourcer. Der er mangel på tid, og folk føler, at det er uretfærdigt at forvente, at de skal deltage i projektet oven i deres almindelige driftsopgaver. Og det har de jo ret i. Når det kommer på tavlen, så kan det gøres konkret. Du kan få deltagerne til at konkretisere, hvilke områder eller medarbejdergrupper, der konkret vil være pressede. Du kan skrive det ind i projektets risikolog. Og hvis du ikke har en risikolog, så opret en, for det er et godt værktøj til at synliggøre risici for styregruppen.

Lad os sige, at salgsafdelingen ikke har afsat tid til at deltage i projektet, som ligger midt i deres travleste periode. Det skriver du ind i risikologgen med en passende vurdering af, hvor stor risikoen er, og hvad konsekvensen vil være. Så går du til projektejeren og styregruppen og siger, at du har en udfordring. Du kan ikke løse problemet selv, for som projektleder har du ikke ledelsesret over medarbejderne eller Salgschefen. Du skal altid ud at ”låne” ressourcer i afdelingerne. Men projektejeren og styregruppen har kompetence til at omprioritere, flytte deadline, arrangere overarbejde, hyre flere ressourcer eller hvad løsningen end skal være.

At bruge en risikolog til at få projektejeren eller styregruppen til at løse et ressourceproblem er en konstruktiv metode til at løse en udfordring, som ellers ville ende i en formålsløs konfrontation mellem dig og Salgschefen. Synliggørelse af ressource-udfordringer og risici generelt er en hjælp for både dig og procesejerne.

Du bliver en hjælper for procesejerne i stedet for en modstander, der kommer og forstyrrer deres hverdag.

Håndtering af modstand hos procesejere

Du risikerer også at møde procesejere, som ikke selv har en konstruktiv indstilling
til projektet, og det gør det naturligvis umuligt for dem at drive forandrings-
processen i deres afdeling. De er negativt indstillet på forhånd, og det kan skyldes manglende forståelse af formålet, uenighed i systemvalg, konsulentskepsis, faglig stolthed og meget mere.

Som projektleder er du nødt til at spotte modstand hos procesejere så tidligt i processen som muligt og eskalere det til projektejeren, for modstanden betyder, at procesejeren ikke kan drive forandringsprocessen, og det resulterer i en hel afdeling med modstand.

Det gode spørgsmål er, hvordan du spotter modstand hos procesejere.

Den bedste måde er at gå i detaljer. Hold et koordineringsmøde med procesejeren så tidligt som muligt i projektet. Tal alt igennem og læg mærke til, om procesejeren er mentalt til stede. Hvis procesejeren ikke er klar til at booke konkrete personer på konkrete datoer til workshops, test og undervisning, så bør du stoppe op. Hvis procesejeren svarer: ”Vi må lige se, om det bliver nødvendigt” eller ”Det vender vi lige tilbage til på et senere tidspunkt” på konkrete spørgsmål, så bør du reagere.

Du kan også udsende et spørgeskema tidligt i processen. Det virker både med procesejere og de øvrige deltagere. Det er nogle gange nemmere at svare ærligt i et skema end til et møde, hvor chefen også er til stede.

Der findes også større rammeværk som fx ADKAR med forandringsledelsesværktøjer til at måle om medarbejdere er parate til forandringer, men hvis du ikke har den slags modeller i værktøjskassen som projektleder, så kan mindre også gøre det. Det er altid lavpraktisk og effektivt at gå i detaljer og sørge for at studse over diffuse svar.

Din leverandør kan også hjælpe med praktiske værktøjer, når de er på banen. I en workshop kan deltagerne fx blive bedt om at foretage vurderinger. Når leverandøren fremviser en arbejdsgang i løsningen, så er det nemt at sige ”ja” uden at tænke over konsekvenserne, men hvis deltagerne bliver bedt om at vurdere, hvor stor en forandring en arbejdsgang vil medføre, og en svarer ”lille” og en anden svarer ”kæmpestor”, så giver det anledning til en god dialog, som både giver bedre input til løsningsdesignet, men som også afslører hvor forandringsparate deltagerne er.

Når leverandøren bruger denne type værktøjer til at engagere projektdeltagerne, så skal du som projektleder lytte godt efter, for det er en kilde til meget brugbar information. Det er en fordel at bruge en ekstern facilitator, som ikke er forudindtaget med viden om deltagerne og processerne.

Håndtering af modstand fra projektdeltagere

Du kan også støde på modstand fra projektdeltagerne.

Mennesker er grundlæggende ikke tilhængere af forandringer, og modstand mod forandring handler ofte om utryghed. Medarbejderne har arbejdet på samme måde i årtier, og nu kommer et nyt IT-projekt og truer med at ændre deres hverdag og arbejdsprocesser – og måske endda underminere deres ekspertise. De går fra at være superbrugere til at være nybegyndere, og det kan være en voldsom oplevelse.

I den ideelle verden har afdelingschefer og procesejere tid og overskud til at snakke med alle medarbejdere og forebygge deres nervøsitet ved et forandringsprojekt. Men i den virkelige verden går mange utrygge medarbejdere ubemærket hen.

Det kan resultere i modstand, lavere arbejdsglæde eller stress, og det er ærgerligt. Hvis du fornemmer, at kolleger er nervøse, så sørg for at nævne det for deres nærmeste leder. Du gør alle en stor tjeneste ved at sige det højt.

Det er ofte i test-fasen, at modstanden fra projektdeltagerne kommer til udtryk. Det skyldes, at det er i test-fasen, at medarbejderne skal kontrollere, at deres arbejdsgange fungerer efter hensigten i det nye system. Derfor bliver forandringerne meget virkelige og mærkbare i test-fasen, og så reagerer de medarbejdere, som ikke er parate til forandring.

Hvis det endda er tilfældet, at testen bliver nedprioriteret – det sker desværre lidt oftere end man skulle tro – så viser eventuelle udfordringer sig efter driftsstart, når det daglige arbejde bliver en ufrivillig, sporadisk live-test.

Hvad sker der, hvis en medarbejder, som ikke har været nok med på rejsen, og som generelt har modstand mod projektet og forandringerne, finder en ”fejl” i det nye system?

Nogle gange er ”fejlen” blot en forandring, som medarbejderen ikke har taget til sig, men andre gange er fejlen en reel fejl eller mangel, og den fejl bliver oplevet mange gange større, mere presserende, hastende og alvorlig, hvis medarbejderen ikke har været med på rejsen og er indstillet på forandring.

For medarbejdere, der har siddet med korslagte arme gennem hele projektet, vil en fejl være en dejlig bekræftelse af, at de hele tiden har haft ret. De kan faktisk blive glade for, at det går dårligt.

Selv hvis negative medarbejdere forsøger at tillægge sig en mere positiv holdning, så er det svært at juble over et velfungerende system, hvis man har været kritisk hele vejen.

Håndtering af unikke fageksperter

Blandt fageksperter kan du støde på en modstand mod standardløsninger og andres ekspertise. Den bunder i, at fagpersoner har deres identitet bundet i deres faglige ekspertise. De føler, at virksomhedens behov er unikke, og at deres fagområde eller afdeling er unik, og at de har en unik forståelse for, hvordan det skal IT-understøttes.

Når leverandøren kommer og ruller standardløsninger og standardmetoder ud med skabeloner, så kan det skabe friktion, for det fjerner følelsen af at være unik, og det nedbryder deres identitet. Derfor kan de kun acceptere løsninger, som de selv har været med til at opfinde. Skabeloner bliver afvist, fordi de ikke kan omfavne den unikke kontekst.

Som regel overvurderer fagpersoner, hvor unikt deres område er, men det er svært at overbevise dem. Du kan ikke gøre andet end at have antennerne ude, så du i god tid opfanger, hvis der er nogen der er skeptiske over for skabeloner og standarder. I så fald skal der være tid til at fagpersonerne og leverandørens eksperter kan tale i dybden om deres fag, så fagpersonerne kan føle sig trygge.

Interessentanalyse som værktøj

Det mest praktiske værktøj til at håndtere modstand fra projektdeltagere er en interessentanalyse.

I en interessentanalyse kortlægger du, hvem der er vigtige deltagere i projektet, hvordan de har indflydelse på projektet, og om du forventer, at de kommer med en positiv eller negativ indstilling. Hvem bliver ambassadører, og hvem vil skabe modstand.

Du kan udføre kortlægningen sammen med hver procesejer for sig, eller du kan samle alle procesejerne og tage det i plenum. Det er vigtigt at involvere procesejerne, for du får ikke kun konkret input – du får også aktiveret procesejerne til at tænke i de baner.

Resultatet skal være en handlingsplan med konkrete aktiviteter, der imødegår de risici, der er identificeret.

Det kan være, at nogle risici skal skrives ind i risikologgen, så det kan blive eskaleret til projektejeren eller styregruppen, at der er en udfordring i en bestemt afdeling. Det kan også være, at det er tilstrækkeligt, at procesejeren tager initiativ til at informere mere i afdelingen, aktivere ambassadører, eller holde møder med konkrete medarbejdere.

Som projektleder skal du ikke løse alle problemer, men du er en rigtig god projektleder, hvis du formår at synliggøre problemerne, så de rette personer kan gøre noget ved dem. Hvis du prøver at løse alt selv, så kommer du ingen vegne.

Forandringsledelse

Det meste modstand kan forebygges. Du kan imødegå alle problemerne ved proaktivt at bruge forandringsledelse. IT-projekter skaber forandringer, og dem skal alle være parate til.

Vi oplever sjældent, at mennesker slet ikke ønsker at ændre sig. Udfordringen er ofte, at forandringerne og konsekvenserne ikke er formidlet godt nok til dem, og derfor har de modstand mod det, de frygter, at forandringen vil medføre – ikke de reelle forandringer.

Modstand opstår, når personer ikke er parate, og forandringsledelse er værktøjer til at gøre personer mere velinformerede og parate til forandring – så der er en åbenlys sammenhæng.

Bullshit-udfordringen

Forandringsledelse er et vigtigt element i din rolle som projektleder. Du skal ikke personligt skabe forandringerne, men du skal facilitere, at procesejerne får gjort konkrete tiltag, og at forandring generelt har gode vilkår i organisationen.

Men det kan være, at du skal passe på med at bruge ordet ”forandringsledelse”. Ordet i sig selv skaber desværre modstand hos mange, fordi det lyder ”konsulent-agtigt”. Det er ganske uretfærdigt, men det er noget, vi ofte møder. Hvis du også siger, at forandringsprocessen er en ”rejse”, hvor vi er nødt til at være ”omstillingsparate” og have ”ja-hatten” på, så vi kan ”se fremad” og være ”agile” nok til at ”genbesøge” gamle arbejdsprocesser, så vi kan ”afstemme forventningerne” til de nye arbejdsgange – så er du allerede bagud på point fra starten af.

Mange er allergiske over for floskler og metaforer. Her er et eksempel på en formulering, der er svær at forstå:

• Forandringsledelse er en kompleks og multifaceteret proces, der kræver en integreret og holistisk tilgang. Det er vigtigt at skabe en visionær og dynamisk strategi, der kan navigere i den konstante disruption, der er en realitet i den digitale tidsalder. En anden vigtig faktor er at skabe en organisatorisk kultur, der tilskynder til innovation og læring.

Hvis du trækker på smilebåndet af den formulering, så ved du godt hvad problemet er. Her er en bedre måde at sige det på:

• Vi er nødt til at ændre os for at følge med tiden, men ændringer i adfærd kan være svære at gennemføre. Det kræver en indsats fra lederne på mange områder. Som ledere skal vi se det store billede, men vi skal også anerkende det enkelte menneske, så de får lyst til at lære nyt og få gode ideer, der forbedrer vores processer.

Hvis du har kolleger, som synes, at forandringsledelse lyder som varm luft, så kald det noget andet, og forklar tingene på en mere jordnær måde.

Det er en gratis omgang, når en kollega synes, at noget er floskler. Spørg nysgerrigt ind til hvorfor vedkommende oplever emnet som floskler. Det kan være, at der gemmer sig noget relevant under overfladen.

Det er en god idé at få hjælp fra din leverandør til at kommunikere de vigtige budskaber. De har sikkert projektledere eller konsulenter, som er specialiserede i forandringsledelse, og dem kan du med fordel trække på. Hvis der er en kommunikationsafdeling i din virksomhed, så kan du også trække på deres hjælp, selv om de måske til hverdag arbejder med markedsrettet kommunikation.

Hvad er forandringsledelse

Forandringsledelse er egentlig ”bare” ledelse, der foregår i en situation, hvor der sker forandringer. Lederen skal vejlede og tale med sine medarbejdere til hverdag, og i forandringssituationen skal lederen vejlede og tale endnu mere.

Men der er den afgørende forskel, at projektet bringer medarbejderne i uvante roller. Den enkelte medarbejder er vant til at fokusere på sine egne arbejdsprocesser, og chefen er vant til at tale med medarbejderen om præcis de processer.

I IT-projektet skal medarbejder pludselig deltage i workshops og forholde sig til beslutninger, som rækker bredere end vedkommendes eget arbejdsområde. Og medarbejderen skal tage ansvaret for at teste og godkende det nye system – og skal lære en række nye arbejdsprocesser og påtage sig rollen som superbruger og formidle viden videre til sine kolleger.

Det er en uvant situation, medarbejderne bliver sat i, og det kræver en anden type ledelse. Nye ansvar, nye typer beslutninger, nye emneområder, og usikkerheden om hvad fremtiden bringer – det skal lederen hjælpe medarbejderen med at finde sig til rette i.

De værktøjer, som lederen skal tage i brug, er kommunikation, dialog, information, inklusion, anerkendelse, indflydelse, involvering … vi kunne også sige coaching. Og alt dette skal foregå med en langt større proaktivitet, hyppighed og vedholdenhed, end lederen normalt er vant til.

Den enkelte medarbejder skal forstå, hvad pointen er for vedkommende selv, hvorfor forandringen er nødvendig for virksomheden, hvad forandringen reelt medfører, og hvordan processen for at gennemføre forandringen vil forløbe.

Forandringsledelse er ganske lavpraktisk. Du har medarbejdere, der ikke er parate til at håndtere forandring, og det skal du tale med dem om.

Hvis medarbejderne kan se en gevinst for dem selv, så er modstanden sjældent stor.

Hvis forandringsledelse ikke bliver taget alvorligt

Som projektleder vil du måske opleve, at forandringsledelse ikke bliver taget alvorligt, selv om procesejerne har forstået, at det er relevant.

Ofte trumfer den tekniske løsning over forandringsledelse, når hverdagen bliver presset. Det er lidt spøjst, for problemer med at realisere de ønskede gevinster i IT-projekter skyldes oftere manglende forandringsledelse end tekniske mangler.

Hvis vi kigger på IT-projekter om forretningsløsninger i danske virksomheder i de senere år, så tør vi faktisk godt vove den påstand, at ud af de projekter, der er løbet over budget, eller ikke har opnået de ønskede gevinster, der er mangel på forandring den hovedskyldige i langt de fleste tilfælde. Det er de færreste tilfælde, at teknikken er problemet.

Alligevel hælder de fleste til at prioritere teknikken højest, når tidsplanen er under pres. Hvis den situation opstår, så må du prøve at forklare dine kolleger, at det er et dårligt valg at nedprioritere forandringsledelse.

Rollen som Change manager

Hvis det er muligt, så er det en rigtig god idé at udnævne en Change Manager. Det er ikke så tit, at det er muligt, men vi vil gerne slå et slag for det, fordi en Change Manager er et godt tiltag.

En Change Manager er ansvarlig for, at forandringsledelse bliver ført ud i praksis, så alle kommer trygt og godt med på forandringsrejsen og ikke skaber modstand undervejs. En Change Manager skal ikke selv udføre forandringsaktiviteterne, men skal planlægge og facilitere, at procesejerne og ledelsen får gennemført aktiviteterne.

Hvis der ikke er udnævnt en Change Manager, så falder ansvaret tilbage på dig som projektleder, og det er også okay, men det skaber et særskilt fokus at have en dedikeret Change Manager.

Det skaber en sund erkendelse hos ledelsen og styregruppen, når behovet for at skabe adfærdsændringer fysisk manifesterer sig i en Change Manager-rolle. Styregruppen bliver også holdt til ilden, når en Change Manager løbende rapporterer status på forandringsaktiviteter.

Det letter også presset på dig som projektleder, når du står i en svær prioritering, og du bliver målt på en deadline, som kun handler om teknik. Projektlederen har ofte svært ved at udskyde en teknisk deadline, fordi der skal være plads til et informationsmøde, men en Change Manager kan nemmere sætte fokus på de problemer, det vil skabe, hvis man aflyser informationsmødet.

Hvis du lige nu sidder med en nyfunden ambition om at give forandringsledelse den prioritering, som det fortjener, så vil vi gerne være hudløst realistiske:

Det vi oftest oplever er, at projektledere begynder med gode ambitioner om forandringsledelse, men når der bliver travlt, så er honeymoon overstået, og så ryger forandringsledelse og kommunikation langt ned på prioriteringslisten, fordi der er mere synligt ild i andre ting.

Kommunikationsplan

Det vigtigste styringsredskab for forandringsledelsen er en kommunikationsplan. Den skal vise, hvad der skal kommunikeres, hvornår, hvor ofte, til hvem og af hvem.

Den skal vise, at der er forskellige typer af aktiviteter. Det er forskellige folk i forskellige situationer, og de skal kommunikeres til på forskellige måder. Og den skal også anskueliggøre, at alle relevante personer er omfattet af planen.

Rent praktisk så kan aktiviteterne være fx firmamøder, afdelingsmøder, 1-til-1-
møder, nyhedsbreve, informations-emails, undervisning, kurser, coaching, konfe-
rencer, workshops, intranetopslag, afstemninger, spørgeskemaer, konkurrencer, rollespil, og alt muligt andet, der giver gode rammer for dialog mellem to mennesker.

Workshops

Når projektarbejdet er kommet godt i gang, så har du en masse projektdeltagere, som skal deltage på workshops med leverandøren. Den proces kan du forvente, at leverandørens projektleder styrer i detaljer, men før workshops begynder, så synes vi, at du skal kigge på leverandørens bemanding.

Blinde vinkler og eksperter

Det er en vigtig erkendelse, at mennesker har blinde vinkler i forhold til, hvordan virkeligheden ser ud, og man kan ikke forvente, at projektdeltagerne kan gennemskue de fulde konsekvenser af de abstrakte beslutninger, de træffer ved en tavle i en workshop. Det er virkelig svært.

Hvad kan du som projektleder gøre ved det? Du kan i praksis ikke gøre særlig meget, men leverandøren kan gøre en hel del – og du kan bidrage ved at sikre, at leverandøren har bemandet projektet med profiler, der er i stand til at yde den rette sparring.

Udviklere hos leverandøren fungerer lige som en kok i et køkken, som bare følger en fastlagt opskrift. De udvikler det, som er specificeret. Dem behøver du ikke være nervøs over – altså udviklerne, ikke kokkene. Du skal være meget mere interesseret i, hvem leverandøren stiller med som konsulent på workshops.

Den rolle hedder måske en løsningsarkitekt, en hovedarkitekt, en forretningskonsulent eller noget helt andet. Der er mange titler. Men rollen er at lytte til projektdeltagernes behov og omsætte det til noget, som udviklerne kan implementere. Det er konsulenten, der skriver opskriften.

Den konsulent skal forstå jeres forretning, jeres branche og jeres behov, gerne i så mange detaljer som muligt, for det giver vedkommende mulighed for at gennemskue konsekvenserne af jeres beslutninger og udfordre og rådgive på de rette tidspunkter.

Den person skal du tjekke CV’et på, og du skal bore i, hvad der kvalificerer vedkommende til at stå for workshoppen.

Undtagelser og anekdoter

På en workshop kan der blive truffet mange beslutninger, som ændrer scope – og dermed også tidsplanen og økonomien. Som projektleder har du en interesse i at følge med i, hvordan workshops skrider frem, og om deltagerne holder sig nogenlunde inden for scope.

I den forbindelse er der et menneskeligt træk, du skal lære at spotte og reagere på.

Det er altid undtagelserne, der bliver smækket på bordet i en diskussion, og de er fascinerende historier, men det er et problem, hvis man træffer beslutninger ud fra undtagelser.

Mennesker har en tilbøjelighed til at overvurdere relevansen af den information, som er mest synlig for os. Hvis det har været et stort problem i bogholderiet, at en kunde havde et problem med en faktura, så vil det konkrete problem være et vigtigt emne på workshoppen dagen efter. Men måske er det den eneste kunde, der nogensinde vil have det problem. Måske bør det slet ikke have indflydelse på det nye system.

Det er anekdotisk viden, der er problemet. Kolleger fortæller om udfordringer i konkrete situationer. Ledere fortæller om erfaringer de har hørt i netværksgruppen fra en enkelt person. Det er ikke forkert viden, for det er jo konkrete erfaringer. Men det er undtagelser, fordi det er anekdoter om enkelte tilfælde.

Det første spørgsmål skal altid være: Hvor ofte oplever vi det, og hvor stort et problem er det egentlig?

Hvis problemet ofte opstår, så er det et vigtigt emne – men hvis det kun er sket én gang, så er det en anekdote, og så skal der ikke bruges tid på det. IT-systemer skal ikke dække 100% af alle anekdoter og undtagelser, for så bliver det det dyreste IT-system nogensinde.

Ændringer

Hvis der dukker noget op, som man ikke kan leve uden, så bliver det til en ændringsanmodning, som skal sendes til leverandøren, så de kan vurdere, om det er noget, der forsvarligt kan gennemføres inden for projektets rammer. Og hvis det har en konsekvens for tidsplanen eller budgettet, så skal du få projektejer eller styregruppen til at godkende ændringen.

Ændringer kan opstå, når din organisation opdager noget nyt, som de gerne vil føje til ønskesedlen – men de kan også opstå, hvis de oprindelige estimater viser sig at være urealistisk lave. Lad os begynde med sidstnævnte.

Over- og undervurderinger – og dårlige estimater

Mennesker har en tendens til at være optimistiske, når vi skal vurdere noget, vi gerne vil. Det tager sikkert ikke særlig lang tid at gennemføre, og det koster sikkert ikke særlig meget. Senere viser det sig, at det var kompliceret, tog lang tid og kostede mange penge. Man overvurderer sin egen formåen og undervurderer kompleksitet.

Som projektleder kan du roligt regne med, at det gælder alle vurderinger undervejs i projektet – både fra dine kolleger og fra din leverandør. Nu er vi jo selv en IT-leverandør, så vi skal passe på med at skyde os selv i foden, men vi er også mennesker, og mennesker kommer altid til at være for optimistiske i estimater – men vi har gjort en række foranstaltninger for at sikre os mod den værste optimisme, for det er rarest at ramme korrekt med estimater.

Du skal også være opmærksom på, at nogen kan finde på at undervurdere et estimat med vilje. Det sker forhåbentlig ikke tit, men vi er stødt på det. Leverandøren kan undervurdere et estimat for at få ordren. Ledende medarbejdere kan undervurdere et budget for at få ledelsens godkendelse.

Der er en flydende grænse mellem urealistisk overmodighed og decideret løgn, men uanset hvad, så er det virkelig skidt, når nogen desværre bevidst vælger at undervurdere. Hold øjnene åbne.

Proces for ændringsanmodninger

Der bliver altid behov for ændringer undervejs i et komplekst projekt. Der opstår nye muligheder, eller der er noget man bliver klogere på.

Det er grundlæggende en positiv situation i de fleste tilfælde. Projektdeltagerne opdager en mulighed for at gøre IT-understøttelsen endnu smartere, og den mulighed vil de gerne udnytte.

Det kan naturligvis kun lade sig gøre, hvis der er tid og penge til det, og det er ærgerligt at gå glip af nye muligheder, der kan øge gevinsterne i projektet, fordi tid og penge er begrænset.

Et godt råd til dig som projektleder er, at du har en pulje til ændringer, dvs. ekstra penge og en tidsmæssig buffer. Det gør, at du kan håndtere små ændringer uden stop. Ellers skal du tage spørgsmålet op med styregruppen – eller afvise ændringer.

Din leverandør kan hjælpe med at prioritere mellem forskellige ændringsanmodninger,
men du behøver ikke delagtiggøre din leverandør i dit budget for ændringer, hvis du gerne vil beholde puljen i skuffen til en rigtig regnvejrsdag.

Helt lavpraktisk, så skal deltagerne på workshops registrere, når der kommer en ny idé på bordet, som kan bidrage positivt til projektets gevinstmål, men som ikke er inden for scope.

Der skal samles til bunke og prioriteres. Det kan være, at der kommer mange ideer. Nogle er gode, andre er bedre, og senere i projektet kommer der måske nogen, som er endnu bedre.

Derfor skal alle ændringsanmodninger samles. Omfanget og gevinstpotentialet skal vurderes, og så skal der prioriteres.

I nogle projekter træffer styregruppen beslutninger om ændringer. I andre projekter er det uddelegeret til procesejerne. Nogle gange har procesejere hvert sit ændringsbudget, og andre gange har de et samlet budget og skal prioritere sammen, på tværs af afdelinger.

Du skal få styregruppen til at træffe en beslutning om, hvordan processen for ændringsanmodninger skal være. Hvor detaljeret ønsker de at styre og bestemme?

Beslutningerne ligger faktisk bedst i hænderne på procesejerne, for de kender til årsagerne, mulighederne og konsekvenserne ved ændringerne, og det er bedst hvis prioriteringen foregår på tværs af alle anmodninger i hele projektet, men det er også sværest, fordi det kræver, at alle procesejere bliver enige.

Når du udvider scope for projektet, så kan det være, at tidsplanen ikke kan absorbere det. Det er projektleder-trekanten, som vi talte om tidligere. Når vi ændrer på omfanget, så har det en konsekvens for tid og penge. I så fald skal beslutningen forbi styregruppen, som skal acceptere, at du udvider tidsplanen, tilføjer en fase 2, omprioriterer aktiviteter, eller hvilken løsning du vælger for at få tidsplanen til at gå op.

Test

Senere i projektet kommer du til den hyppigt oversete test-fase. Test kan vel ikke være så kritisk, vel? Det kan næppe fylde mange sider i denne artikel. Leverandøren har vel testet deres arbejde og leverer noget, der virker. Ja, det gør din leverandør sikkert, men du er nødt til at teste internt alligevel.

Det er der to årsager til: Ind i mellem laver din leverandør fejl alligevel, og dem skal du fange, inden de gør ondt. Og den anden årsag er, at det er kun teknikken, leverandøren har testet. Du skal teste anvendelsen, og det kan give et helt andet resultat. Det går vi i detaljer med her.

Men først er vi nødt til at sige, at de fleste mennesker synes, at test er en drønkedelig opgave. Lige så kedeligt som en brandøvelse.

Der er nogle få, der elsker det, og har du sådan en person i teamet, så er du heldig, men de fleste synes det er kedeligt.

Hvad skal testes – og hvem skal teste?

Hvorfor kan du risikere, at få leverancer fra din leverandør, som indeholder fejl? Helt grundlæggende er det sådan, at den person der har bygget noget, ikke er den bedste til selv at teste det. Det er en psykologisk barriere, som de færreste mennesker kan sætte sig ud over. Man har brugt meget energi på at bygge noget, og det føles afsluttet, og så er det svært at vende tilbage og gennemgå det detaljeret, med risiko for at man er nødt til at åbne det hele op igen for at rette en fejl.

Derfor vil din leverandør gerne sætte en anden person til at teste, inden de leverer til dig. Det bliver en slags ”peer review” test. Det er naturligvis noget, som tager ekstra tid, fordi person nummer 2 er nødt til at sætte sig ind i det, som person nummer 1 har bygget.

Udfordringen kan opstå, når budgettet er presset, og der skal skæres i projektets timer for at imødekomme kundens ønske til prisniveauet. Så kan mange kunder opfatte denne peer-review-test som en slags livrem-og-seler-test, der er lidt unødvendig, og så bliver den sparet væk.

Ganske forståeligt, men også ærgerligt.

Den bedste test er dog den, som projektdeltagerne i din egen virksomhed udfører. Hvis du kun skal udkæmpe én kamp inden for test, så skal det være at få dine kolleger til at teste ordentligt.

Leverandøren kan teste, at en funktion virker. Men dine projektdeltagere kan teste, om funktionen lever op til deres behov, og om den fungerer i den samlede arbejdsgang.

Test-processen skaber en større forståelse for de nye arbejdsprocesser hos deltagerne, og det sætter dem i stand til at vurdere, om den nye funktion er fyldestgørende, og om den dækker det fulde behov, eller om man hellere skulle have bygget noget mindre, noget mere eller noget helt andet. Der kan være rigtig mange udfald af en test.

Det er i en test, at en ny funktion første gang rammer virkelighedens verden. Det gør den ikke i undervisningen, for det er en abstrakt situation. Det er i testen, at deltagerne første gang afprøver det nye system, sådan som det skal bruges i dagligdagen.

Det er super-vigtigt, at denne afprøvning foregår i testmiljøet – og ikke på den første dag efter driftsstarten.

Den pointe vender vi tilbage til om lidt. Det er nemlig ret dyrt at lade testen foregå de første dage i rigtig drift.

Testdeltagerne skal have været en del af processen tidligere. De skal have været med på workshops, så de kender de beslutninger, som er truffet. Hvis en medarbejder er indkaldt til test, og ser det nye system for første gang, og ikke kender de beslutninger, som er truffet om arbejdsgange og funktioner, så stiller de spørgsmål og er kritiske. Så risikerer du, at de ikke er parate til forandringen, og det skaber modstand.

Faktisk er det en god test af, om dine procesejere er lykkedes med forandringsledelsen. Hvis du kan komme igennem testen uden at deltagerne udfordrer tidligere beslutninger, så er de forandringsparate.

Test er den billigste kvalitetssikring

Igen må vi lige understrege, at det ikke er dig som projektleder, der skal træde til som vikar, hvis der er projektdeltagere, der pludselig ikke har tid eller skaber for meget modstand. Du skal eskalere problemet, men du skal ikke selv udføre testen. Du kan ikke vurdere, om en funktion er fyldestgørende for medarbejdere i en anden afdeling, eller om den passer ind i deres arbejdsgang.

Test skal udføres af dem, som har en interesse i at finde problemerne. Det er dem, der ved, at hvis de ikke fanger problemerne nu i testen, så rammer problemerne dem hårdt, når systemet er gået i drift og hverdagen melder sig.

Det er meget billigere og nemmere at fange problemerne i testen – end at vente til når systemet er i drift. Hvis nogen i ledelsen er skeptiske over for at medarbejderne skal bruge tid på test, så kan du roligt forklare, at test sparer rigtig mange penge.

Hvad sker der, hvis en fejl først bliver opdaget, når systemet er i drift? Så er man i gang med hverdagens arbejde, og man har ikke længere tid afsat til at håndtere tilbageløb fra IT-projektet. Man er heller ikke mentalt indstillet på det.

Men den største udfordring er, at en fejl efter driftsstart giver fejl i driftsdata.
I testen arbejder man i en test-database, og hvis en fejl smadrer alle data, så sker der faktisk ikke noget ved det. Men hvis en fejl forurener data i driftsdatabasen, så ligger der et stort oprydningsarbejde foran jer.

Det har indflydelse på mange mennesker i organisationen, og det kan forårsage stop i arbejdsprocesser, forsinkelser i leverancer til kunder, tabte ordrer og alle slags ulyksaligheder.

Hvis en utestet løsning rammer driften, så er det rigtige penge du sætter over styr. Mens din leverandør kæmper for at rette fejlen, så fortsætter dine kolleger med at bidrage til forureningen af data ved at fortsætte deres arbejde og lægge flere data ind – med mindre du sætter alle de berørte processer i stå, men det skaber forsinkelser eller sætter virksomhedens drift helt på pause, og det er næppe acceptabelt.

Hvad sker der, hvis du ikke kan foretage et indkøb hos en leverandør? Eller du ikke kan fakturere kunder? Eller webshoppen ikke kan tage imod ordrer? Eller der står fire lastbiler i varemodtagelsen, og scanneren ikke virker?

Det er virkelig ikke noget, du som projektleder bliver populær på, og derfor skal du insistere på, at det nye system skal testes ordentligt i testfasen.

Vi får det til at lyde lidt slemt, men det kan nogle gange være nogle simple småting, som har store konsekvenser.

Det kan være, at der mangler et enkelt datafelt på en vares papirer, og så bliver de stoppet i tolden til Kina. Alle varerne bliver sendt retur til Danmark, fordi nogen har overset, at der mangler en information på et dokument. ”Nååh, men det felt kan jeg da hurtigt smække på dokumentet”, siger udvikleren, og det er korrekt, men det er meget sjovere at fange den mangel i test-fasen – end når containeren er blevet afvist i tolden i Kina.

Hvilke problemer fanger man i testen?

Udfordringen ved alle udviklingsprojekter er, at man kun ved det, man ved. Man stiller spørgsmål ud fra den virkelighed, man kender. Man fokuserer på det man mangler i dag.

Men virkeligheden ændrer sig hele tiden – og med det ændrer behov sig også hele tiden. Man får også mere og mere viden om det nye system. Og hvis projektet varer i lang tid, så ender det med at blive et problem, at det er baseret på viden fra det gamle system og en forældet virkelighed.

Det var en super-god idé, da man designede den ny proces på tavlen i en workshop for mange måneder siden, men nu under testen virker det ikke længere som en god idé. Systemet fungerer helt som specificeret. Der er heller ikke nogen fejl i det, som blev skrevet efter workshoppen, set i datidens perspektiv. Men siden da har man lært mere om det nye system, er blevet klogere på sine egne processer, og den gode idé er ikke længere fyldestgørende i den nye virkelighed.

Det kan også gå op for en, at der er et behov man har glemt at italesætte. Der er jo ingen projekter, hvor alt hvad systemet skal kunne er skrevet ned. Selv hvis man har skrevet en lang kravspecifikation, så er der mange behov, som ikke er specificerede.

Der kan være behov, som er så indlysende, at man ikke tænker over at nævne det. Men det er måske ikke lige så indlysende for leverandøren, og derfor er de ikke opmærksomme på det.

Du synes måske, at det er indlysende, at der skal salt i maden, men hvis der ikke står salt i opskriften, når kokken bliver sat i arbejde, så kommer der ikke salt i maden.

Der kan også være behov, som man ikke har haft på radaren i begyndelsen. Efterhånden som systemet har materialiseret sig, så har man gjort sig nogle erkendelser, og når man tester det nye system op mod dagligdagens verden, så viser der sig nogle afledte behov, som man ikke havde en chance for at erkende dengang, workshoppen blev afholdt.

Du har givet kokken opskriften på den lækreste sovs, og kokken har fulgt opskriften perfekt, men når sovsen bliver serveret, så viser det sig, at den er lidt tynd. Først da erkender du, at der er behov for, at sovsen skal jævnes.

Alt det møder du i testen, og det er nogle af grundene til, at test er så vigtig.

Men der kan dukke endnu mere finurlige udfordringer op i testen, som kun indirekte har noget med det nye system at gøre. Lad os tage et eksempel:

Indkøbsafdelingen kæmper med at få komponenter hjem fra fjerne dele af verden, og produktionen er afhængig af, at de kan planlægge efter, hvornår delene er på lager.

Nu indfører man et nyt IT-system, som understøtter både produktion og indkøb, og det er rigtig smart, men i testen bliver det tydeligt, at når indkøberne ikke kan få en komponent hjem til et bestemt tidspunkt, så skal produktionen ændre produktionsplanlægningen, for at indkøberne kan få indkøbsplanlægningen til at stemme fremadrettet.

IT-systemet styrer processen, som de gerne vil have det, men det viser sig pludselig, at én afdeling kommer til at være afhængig af, at en anden afdeling gør noget på et bestemt tidspunkt. Det er en ny arbejdsgang, som man ikke havde gennemskuet konsekvensen af på forhånd. Det bliver fanget i testen.

Testen samler systemet, arbejdsprocesserne, roller og den menneskelige adfærd.

Test er et kedeligt ord, når man tænker på, at det er så vigtig en aktivitet at engagere dine projektdeltagere i. Test burde hedde noget andet.

Din leverandør kalder det måske User Acceptance Testing, og så forkorter de det sikkert til UAT, fordi IT-leverandører er alt for glade for at bruge bogstavforkortelser.

Men det er faktisk en god betegnelse, at det handler om ”bruger-accept”, fordi det signalerer, at man ikke kun leder efter fejl, men også evaluerer, om brugeren kan se sig selv arbejde med de nye processer og funktioner.

Proaktivitet før tests

Allerede ved det interne kick-off i begyndelsen af projektet skal du begynde at forklare, hvor vigtig testen bliver. Du skal klæde projektdeltagerne på fra begyndelsen af.

Det er en god idé, at medarbejderne så tidligt i forløbet som muligt begynder at tage noter om, hvad de gør i hverdagen. Hvis man har været i sin rolle i lang tid, så gør man sikkert mange ting af ren vane, og hvis man pludselig står til en workshop eller en test og bliver spurgt om sine arbejdsprocesser, så kan man som regel kun huske det halve.

Hvis man noterer overskrifterne på sine arbejdsopgaver, så bliver det meget nemmere at skrive testcases.

Det er også en del af forandringsledelsen, at medarbejderne tidligt bliver opmærksomme på, at de skal involvere sig, og at de skal kunne beskrive, hvordan deres arbejde foregår.

Tid kan være en udfordring

Planer er lagt efter den virkelighed, man kender fra begyndelsen, men hvis planerne ændrer sig undervejs i projektet, fordi man bliver klogere eller ændrer ambitionsniveau, så kan tidsplanen nemt komme under pres.

Ofte ligger den dato, hvor løsningen skal gå i drift ret fast. Hvis leverancen af systemet bliver forsinket undervejs, så bliver vinduet til test mindre og mindre.

Du kan ende i en situation, hvor du står foran styregruppen og forklarer, at tidsplanen er skredet, og at driftsstarten bør udskydes, så der er god tid til at teste løsningen.

Det siger de sikkert nej tak til.

Så forklarer du, at planen har ændret sig undervejs, og der er kommet 14 ændringsanmodninger undervejs, som har taget ekstra tid, og derfor er det kun rimeligt, at driftsstarten også bliver udskudt.

Så hører du dem sikkert sige: ”Vi har allerede været i gang længe, og nu er det tid til at komme videre”, og ”vi ved godt, at det hele ikke er testet, men så må vi rette eventuelle fejl efter go-live.”

Så skal du sige nej.

Det er rigtig svært at sige nej, for der er sikkert pres på dig. Du er måske den eneste i lokalet, der hellere vil udskyde tidsplanen end presse noget igennem. Ledelsen har prestige på spil, og styregruppen får en bonus, hvis tidsplanen holder, og det kan efterlade dig ret alene.

Så fortæller du om risikoen for forurenede data, de fire ventende lastbiler i varemodtagelsen og containeren der er bremset i tolden i Kina. Så har du i det mindste gjort dit til, at styregruppen kan træffe en velinformeret beslutning

– og du har optjent retten til bagefter at kunne hive mødereferatet frem og sige: ”Hvad sagde jeg”.

Rapportering af testresultat

Som projektleder er det dit ansvar at sikre praktikken i forbindelse med test. Din leverandør vil sikkert foreslå en struktur, og de stiller sikkert også et opgavesystem til rådighed, hvor du kan styre afviklingen af testen – men ellers skal du selv tage initiativ til at strukturere testen.

Der skal foreligge en proces for, hvordan testen skal udføres, hvordan man indrapporterer resultatet, og hvem man indrapporterer til. Der skal være en kategorisering af fejl, så de ikke blot alle sammen er kritiske. Du kan fx opdele dem i rød, gul og grøn. Der kan også opstå nye ønsker og gode ideer undervejs i testen, og medarbejderne skal også have en struktureret form til at indmelde nye ideer, så de ikke bliver blandet sammen med fejlmeldinger.

Test Manager

Vi oplever, at der i større projekter er en værdi i, at det er en anden person end projektlederen, som har ansvaret for testafviklingen. Et særskilt fokus på forandringsledelse med en Change Manager styrker indsatsen på forandrings-
ledelse – og på samme måde styrker også en Test Manager indsatsen på testen.

Rollen kan fx tages af en superbruger, som automatisk bliver til en ambassadør for det nye system i organisationen, og det er sundt at få spredt ambassadør-rollen på flere personer. Nu har organisationen i lang tid lyttet til dig som projektleder, og så er det fint, at der kommer en anden person på banen med frisk engagement og nye betragtningsvinkler. Nogle gange kan det forny momentum i projektet.

Der er en risiko i, at du kører lidt træt i projektleder-rollen. Vi snakker ikke om, at du er gået helt kold på at være projektleder og hader jobbet. Vi snakker om, at det måske har været et langt projekt, når du når frem til test. Det er naturligt, at alle er trætte og glæder sig til at nå målstregen. Der kan nemt opstå en ”lukket kreds” mellem dig og leverandørens primære deltagere, og I kan måske betrygge hinanden i, at alt ser fint ud, og at I er parate til at hjælpe hinanden, hvis der dukker noget uforudset op, og så virker det pludselig acceptabelt at springe over, hvor gærdet er lavest.

Den fælde vil en dedikeret Test Manager aldrig falde i, fordi test er personens hovedfokus. Det er det, personen bliver målt på. Det tilføjer en frisk ihærdighed at skifte en ny spiller ind på banen.

Hvis der er én ting, du skal tage med dig om test, så er det denne pointe: Gør det

Der er alt for mange projekter, hvor test er overset allerede i planlægningen, eller hvor test bliver nedprioriteret undervejs. Det er virkelig dårlig prioritering. Det er dyrt. Don’t underestimate the power of the test.

Tak for at du læste med. God fornøjelse med din nye rolle som projektleder

Ordbog

Hvis du støder på nogen, der taler indforstået projektleder-sprog, så er det godt at kende nogle udtryk. Vi har gjort vores bedste for ikke at bruge denne slags udtryk i denne artikel, men der kunne sagtens være nogen i din ledelse eller hos din leverandør, som bruger nogle smarte fagudtryk.

Her kommer nogle af de mest almindelige. Så ved du, hvad de betyder.

As-is / to-be
En beskrivelse af, hvordan den eksisterende løsning og arbejdsproces ser ud i dag (as-is), og hvordan det forventes at se ud efter en ændring og implementering af den nye løsning (to-be).

Beslutningskompetence
Den myndighed eller autoritet, der er tildelt en person eller gruppe til at træffe beslutninger inden for et bestemt område eller på et bestemt niveau.

Budgetstyring
En disciplin, der beskæftiger sig med at planlægge, allokere og overvåge et projekts budget.

Bugs
En bug er en fejl eller et problem i løsningen, som leverandøren skal afhjælpe. Udtrykket bliver som regel anvendt ved mindre fejl, som ikke er kritiske.

Business Case
En dokumentation af et projekts forventede indtjening og omkostninger, der anvendes til at vurdere om projektet skal gennemføres.

Capex / Capital expenses
Kapitalomkostninger, som er omkostningerne ved at erhverve eller etablere en løsning, udstyr eller andre langvarige aktiver.

Cost to complete
De samlede omkostninger, som er nødvendige for at fuldføre projektet.

Faser
Delperioder inden for et projekts livscyklus, fx en analysefase, en designfase eller en implementeringsfase.

Fit / gap
En analyse af, hvor godt den nye løsning dækker de funktioner, som den gamle løsning har, hvilket giver mulighed for at fokusere på de områder, hvor den nye løsning ikke dækker.

Forandringsledelse
En ledelses-disciplin der fokuserer på at håndtere og implementere adfærdsændringer i en organisation, så medarbejdere er parate til de forandringer, som et IT-projekt medfører.

Forretningsmæssige mål
Mål, der er defineret ud fra et forretningsmæssigt perspektiv, fx øget indtjening eller forbedret kundetilfredshed – i modsætning til tekniske mål, der handler om systemets implementering.

Frontloading
At lægge en større indsats i planlægningsfasen af et projekt for at reducere risici og øge sandsynligheden for succes.

Gantt chart
Et diagram, der viser en tidslinje for et projekts aktiviteter, milepæle og afhængigheder mellem disse i et grafisk overskueligt overblik.

Gemba walk
En metode til at undersøge og kortlægge en forretningsproces ved at besøge de konkrete arbejdssteder, hvor processen finder sted.

Gevinstmålsætning
En konkret beskrivelse af de forventede gevinster ved et projekt, herunder økonomiske, forretningsmæssige og organisatoriske fordele. Dette er en del af gevinstrealiserings-disciplinen.

Gevinstrealisering
En metode til at definere de ønskede gevinster i begyndelsen af projektet for at sikre, at de forventede gevinster ved et projekt faktisk opnås og måles.

Interessentanalyse
En metode til at identificere og analysere de personer eller grupper, der har en interesse i et projekt, og deres mulige indflydelse på projektet, herunder forventelig modstand.

Issue
Et problem eller en udfordring, der skal løses eller håndteres i et projekt. Udtrykket anvendes som regel, når kunden sender en forespørgsel til leverandøren, som skal vurdere, om der er tale om et supportspørgsmål, en ændringsanmodning eller en fejl.

Kapacitetsplanlægning
En planlægning af, hvordan et system eller en organisation kan håndtere mængden af arbejde, når flere opgaver falder tidsmæssigt oven i hinanden.

Kommunikationsplan
En aktivitetsplan for hvordan kommunikationen omkring et projekt skal håndteres, herunder hvem der skal informeres, af hvem, hvornår og på hvilken måde.

Kravspecifikation
En detaljeret beskrivelse af de krav, der stilles til en ny løsning og leverandørens service. Dette anvendes i forbindelse med den indledende evaluering af potentielle leverandører.

Kvalitetssikring
En proces, der sikrer at en specifik del af systemet opfylder bestemte krav og standarder.

Milepæl
En betydningsfuld begivenhed eller et specifikt mål, der markerer en del af et projekts fremdrift.

Opex / Operational expenses
Operationelle omkostninger, som er de daglige omkostninger ved at drive en løsning eller en organisation.

Procesejer
De personer, der på hvert sit område eller afdeling har ansvar for at tilrettelægge, hvordan områdets forretningsprocesser skal understøttes i det nye system. Procesejerne har også ansvaret for at udføre forandringsledelse i organisationen.

Project Charter
En formel dokumentation, der skabes i forbindelse med godkendelse af projektet og angiver dets formål, forventede resultater og de ressourcer, der er tildelt projektet.

Projektdeltager
En person, der er involveret i et projekt, enten som udførende eller støttende rolle.

Projektejer
Den person, der har det overordnede ansvar for et projekt og dets resultater. Det er ledelsens repræsentant i projektet, der har beslutningsmyndighed over projektledelsen, procesejere og projektdeltagere.

Projektledelse
Den disciplin der beskæftiger sig med at planlægge, organisere og overvåge gennemførelsen af et projekt.

Projektplan
En overordnet plan for hvordan et projekt skal gennemføres, herunder mål, tidsplan, ressourcer og budget. Den detaljeres i en opgaveliste med konkrete aktiviteter.

Projektrapportering
Dokumentation af projektets fremdrift, resultater og udfordringer, der præsenteres for projektets interessenter.

Proof of concept
En prototype på en løsning, der etableres for at undersøge, om en idé eller en teknologi kan fungere i praksis i større skala.

Return on investment (ROI)
Afkastet på en investering, målt som en procentdel af den oprindelige investering.

Risikoanalyse
En metode til at identificere, vurdere og håndtere risici i et projekt.

Scope creep
En uønsket udvidelse af scope i løbet af et projekt, som kan påvirke tidsplan, budget og kvalitet.

Scope
Omfanget af et projekt, dvs. hvad den nye løsning skal omfatte af funktioner og forretningsprocesser.

Scrum
En agil projektledelsesmetode, hvor projektet opdeles i små iterative udviklingscykler, kaldet sprints.

Stakeholder management
En disciplin, der beskæftiger sig med at identificere, analysere og håndtere projektets interessenter, herunder deres behov, forventninger og mulige indflydelse på projektet.

Styregruppe
En gruppe bestående af ledere og andre interessenter, der har det øverste ansvar for at styre og overvåge et projekt. Det er den øverste beslutningsmyndighed i projektet.

Test case (eller Use case)
En specifikation af et testscenarie, herunder forventet input og resultat.

Test
En systematisk undersøgelse af det nye system, i form af en række konkrete arbejdsprocesser, for at validere at det vil fungere i dagligdagens driftssituation.

Tidsplan
En plan for, hvornår forskellige dele af et projekt tidsmæssigt vil blive udført. Tidsplanen er som regel opdelt i faser, og detaljeret i en opgaveliste.

User Acceptance Testing (UAT)
Det er det samme som ”test”, men udtrykket har en speciel fokus på, at man ikke kun validerer, at en arbejdsproces virker, men også at den kan anvendes tilfredsstillende af slutbrugeren.

Vandfaldsmodel
En projektmodel, hvor faserne i et projekt følger hinanden i en lineær rækkefølge, f.eks. analyse, design, implementering og vedligeholdelse.

Work breakdown structure (WBS)
En struktureret opdeling af et projekts aktiviteter i mindre, mere håndterbare dele. I denne sammenhæng kalder vi det for en projektplan og en opgaveliste.

Workshop
Et struktureret møde med en samling af personer med et fælles formål, fx at designe eller validere forretningsprocesser og træffe beslutninger om, hvordan det nye system skal fungere.

Ændringsanmodning
En anmodning om en ændring af projektet indhold på et konkret punkt, dvs. en ændring af scope, der eventuelt har en konsekvens for tidsplan og økonomi.

Nu har du læst om din nye rolle som projektleder.

Hvis du gerne vil vide mere om, hvordan vi konkret driver projekter med forretningssystemer, så kan du besøge vores website og læse mere.

Du er også meget velkommen til at ringe til os på 70 23 23 16 og få en snak.

Vi håber, at vi tales ved.
Abakion