Selv om der efterhånden er gennemført rigtig mange it-projekter, er det stadig utroligt mange it-systemer og -funktioner, der ligger ubrugt hen.
En af forklaringerne er nok, at mange har stort fokus på at udvikle it-løsningen og næsten intet fokus på den efterfølgende implementering i organisationen.
Det er en fejl, da manglende eller forkert anvendelse af systemet kan reducere værdien af investeringen betragtelig. I nogle situationer er implementeringen den svære del og bør have indflydelse på, hvordan systemet udvikles.
Hvis vi lige starter i helikopterperspektivet, så handler traditionel softwareudvikling om at omsætte en specifikation, vision, use cases eller product backlog items til et færdigt produkt. Men for mange virksomheder (dem, som ikke sælger it-produkter) ligger den virkelige værdi ikke i produktet, men derimod i at gøre organisationen mere konkurrencedygtig.
Det vil sige, at det handler om en organisationsforandring (som jeg også har været inde på i en tidligere klumme).
Når vi udvikler it-løsninger, reducerer vi problemet fra en organisationsforandring til et it-projekt (specifikationsdelen), og herefter afleverer vi det tilbage til organisationen (implementeringen).
Alt for ofte bliver den sidste del reduceret til et spørgsmål om, hvilke servere systemet skal driftes på, men det bør ses meget bredere. En effektiv implementering i organisationen er afgørende for, at der overhovedet kommer værdi af projektet.
Forandring handler om mennesker
Forsimplet handler implementeringen om, at kraften bag organisationsforandringen skal være større end modstanden - og modstanden er næsten altid menneskelig.
Traditionelt forsøger man at minimere modstanden gennem kommunikation eller undervisning, men der kan være andre muligheder. Bare det at fortælle at en løsning eller funktionalitet eksisterer, glemmes ofte i projekter, selv om løbende kommunikation om status for projektet og de fordele, organisationen vil opnå, kan minimere modstanden.
I organisationer, hvor man ikke har eksplicit fokus på implementeringen, reduceres kraften bag organisationsforandringen oftest til den uformelle indflydelse, som den eller de personer, der har specificeret og udviklet løsningen, har i organisationen.
Hvis projektgruppen eksempelvis er vellidt hos slutbrugerne, er der større chance for, at projektet bliver en succes, end hvis der ingen eller svage relationer er mellem projektgruppen og slutbrugerne.
I mange projekter vælges deltagere til projektgruppen ud fra deres faglige viden i forhold til specifikationsdelen eller i forhold til den formelle organisationsstruktur. Men i virkeligheden bør man i lige så høj grad overveje, hvem der har relationer i organisationen, der sætter vedkommende i stand til at være ambassadører for projektet og få det kørt helt igennem.
Forandringsledelse
Relationer op i hierarkiet kan også være en afgørende faktor. Hvis projektet og projektgruppen ikke har ledelsens opbakning og fokus, kan det for eksempel være svært at få ressourcer til projektet.
Men at have ledelsens opbakning er forhåbentligt ikke det samme, som at ledelsen eller stabsfunktionen driver projekt.
Ledelsesdrevet organisationsforandring har helt sikkert sin berettigelse i situationer, hvor der skal foretages strukturelle ændringer i organisationen, men det er ikke omkostningsfrit at presse en ændring igennem.
Man kan forsøge at minimere modstanden, men man skal regne med, at modstanden og frustrationen udkrystallisere sig og måske viser sig et helt andet sted.
Heldigvis er ledelsesdrevent organisationsforandring kun en ud af mange strategier: Ledelsesdrevet strategi, Tilvalgsstrategi, Producerende strategi, Udforskende strategi, BPR-strategi, Specialistdrevet strategi, Målingsdrevet strategi, Medarbejderdrevet strategi, Lærende strategi og Socialiseringsstrategi (se Projektlederundersøgelse 2014 fra RUC/Mannaz).
Ifølge undersøgelsen havde 64 procent af alle projekter ikke eksplicit valgt strategi for organisationsforandringen, og af dem, som havde valgt strategi, brugte 56 procent ledelsesdrevet strategi.
Nu er disse tal baseret på alle typer projekter og ikke kun it-projekter, men jeg er bange for, at det blandt it-projekter står mindst lige så sløjt til.
Forandringsstrategier
Nu er det ikke alle strategierne, der er egnede i it-projekter, men for de, der er relevante, har vi faktisk en masse muligheder i softwareudvikling for at understøtte disse, i stedet for at se det som to separate processer.
Det kan for eksempel være:
Læring:
Bruge softwaren og metoder fra softwareudvikling til at udforske fremtiden og til at afprøve, hvordan et fremtidsscenarie vil være i praksis, i stedet for kun at bruge softwareudviklingen til at realisere et givent mål.
Det kan for eksempel være ved at bruge metaforer, finde inspiration i løsninger fra andre domæner, eller lave prototyper i forskellige detaljegrader. Alt sammen mere eksperimenterende tilgange end traditionel specifikationsløsning.
Forankring:
Hvor i organisationen er projektet forankret og drevet - i ledelsen eller hos de medarbejdere, som projektet har indflydelse på.
I stedet for, at projekterne er initieret og drevet af for eksempel en projektleder fra stabsfunktionen, og styregruppen består af afdelingsledere, kunne man sagtens tænke sig, at forandringer drives ude i afdelingerne, eventuelt med support fra stabsfunktioner.
Hermed vil medarbejderne have meget mere kontrol over forandringen og sandsynligvis yde mindre modstand.
Roller og ansvar:
Gør op med det klassiske rollemønster mellem for eksempel ledelse, projektleder, bruger og it-medarbejder
Nogle dele af løsningen behøver måske ikke designes af it-medarbejderen, eller måske kunne der spares tid, og løsningen blev bedre, hvis brugeren og it-medarbejderen pair-programmerede.
Ligeledes kan it-medarbejderen måske se nogle helt nye muligheder på det strategiske område, som ledelsen ikke har blik for.
Kontrol:
Selv om de fleste i øjeblikket snakker om agil og Scrum (med god grund), findes der et hav af udviklingsmodeller med hver deres styrker og svagheder: Lige fra anarkistisk til struktureret softwareudvikling (vandfaldsmodellen).
Afhængig af, hvilken form for kontrol man har brug for, skal man vide helt nøjagtig, hvor man er om en måned, eller man skal vide, at man hele tiden har løst de mest presserende udfordringer - så kan der være fordele i at variere processen til mest optimalt at understøtte det mål, man har, for eksempel ved at se på længden af iterationerne.
Tænk værdi før økonomi
Grunden til, at mange projekter enten bevidst eller ubevidst oftest falder tilbage til den ledelsesdrevne strategi, handler måske om vanetænkning og fokus på økonomisk kontrol.
Mange af de andre strategier kræver, at ledelsen tør arbejde med usikkerheder og miste den traditionelle kontrol, hvor man er sikker på resultat og budget, men hvor man så betaler en stor pris i forhold til nytte værdien.
Så husk nu at tænke implementeringen i organisationen med fra starten, og hold fokus på, hvordan der skabes mest mulig værdi for pengene - i stedet for at dele det op i kontrollerbare deleelementer og glemme det vigtigste: at få løsningen implementeret og høste gevinsten.