Skrevet av Jan Gunnar Helgaland
Endringsledelse handler ikke om å håndtere endring. Det handler om å lede en organisasjon slik at den er i stand til å tilpasse seg, vokse og trives i møte med endring.
Kilde: Kotter, John P. (1996). Leading Change. Harvard Business Review Press.
Et klassisk IT-Prosjekt
Se for deg at du er hyret inn som IT-prosjektleder til en større organisasjon. Du har fått i oppgave å oppgradere og migrere en sentral IT løsning med gitte rammer for kost og tid. Løsningen er daglig benyttet av samtlige ansatte i selskapet.
Som en dyktig prosjektleder planlegger du godt og gjennomfører prosjektet i følgende rekkefølge:
- Analyse av eksisterende systemer og prosesser.
- Definere krav til den nye løsningen og prosjektomfang.
- Planlegging av prosjektet.
- Utvikling av den nye løsningen.
- Testing av den nye løsningen.
- Implementering av den nye løsningen.
- Opplæring og støtte for brukere.
- Evaluering av prosjektets suksess og forbedringer.
Du har sørget for gjentagende møter for prosjektstyret med representanter fra ledelsen. Ikke alle møtene blir gjennomført da viktige deltakere ofte blir omprioritert i siste liten. De møtene som blir gjennomført går meget bra; du har sørget for å forhånds utforme forslag til løsning på utfordringer du legger frem og får anerkjennende nikk for dine konklusjoner og anbefalinger.
Du leverer til avtalte rammer og prosjektet er ferdig innenfor de kriteriene som er satt. De gjenværende risikoene med forslag til mitigerende tiltak overleveres til kunden og prosjektstyret.
Tilsynelatende en suksess?
Du går videre til nytt oppdrag. Tre måneder senere får du en telefon, kunden er i krise, de har måttet rulle tilbake til gammel versjon.
Hva gikk galt her?
Det kan være lett å peke på manglende involvering fra ledelsen som rotårsak og det er tvilsomt man vil møte mye motargumentasjon mot dette. I fare for å kaste ut en brannfakkel; er det ikke deg som IT-prosjektleder som skal sørge for å sikre en suksessfull prosjektleveranse og dets verdiskapning for kunden over tid?
Eksemplet over her er høyst forenklet og fiktivt, men jeg kan høre meg selv for endel år siden forsvare overnevnte spørsmålet på følgende måte:
“Jo, men her var det flere faktorer som var utenfor min kontroll, jeg varslet gjentagende om utfordringene til prosjektet og la frem forslag til styringsgruppen om hvilke tiltak som måtte videreføres når prosjektet ble avsluttet. Hva mer kan jeg gjøre?”
Smidig samspill: En ny tilnærming
La oss starte historien på ny, vi tar utgangspunkt i det samme oppdraget, men denne gangen kombinerer vi punktene i prosjektplanleggingen med elementer av smidig endringsledelse uten en fast rekkefølge.
- Iterativ behovsanalyse og kontinuerlig forbedring.
- I stedet for å analysere systemene og prosessene i begynnelsen av prosjektet, utfører man en iterativ behovsanalyse og forbedrer kontinuerlig systemene og prosessene gjennom prosjektets levetid.
- Samle inn og prioritere krav etter hvert som prosjektet utvikler seg.
- I stedet for å definere alle krav og omfang på forhånd, samles og prioriteres kravene etter hvert som prosjektet utvikler seg, noe som gir fleksibilitet og tilpasningsevne.
- Tidsbokset planlegging og iterativt arbeid.
- I stedet for å lage en detaljert plan for hele prosjektet på forhånd, arbeider man med tidsbokset planlegging og iterativt arbeid, noe som gir bedre muligheter for å håndtere endringer og usikkerhet.
- Inkrementell utvikling og kontinuerlig integrasjon.
- I stedet for å utvikle løsningen som en monolittisk enhet, benyttes inkrementell utvikling og kontinuerlig integrasjon for å raskere levere funksjonalitet og redusere risiko.
- Kontinuerlig testing og automatisert testing.
- I stedet for å vente med testing til etter utviklingsfasen, gjennomføres kontinuerlig testing og automatisert testing parallelt med utvikling, noe som øker kvaliteten og reduserer risikoen for feil.
- Hyppige og små releaser.
- I stedet for å vente med implementering til hele løsningen er ferdig, gjennomføres hyppige og små releaser, noe som gir raskere tilbakemeldinger og redusert risiko for feil.
- Tett samarbeid med brukere og kontinuerlig opplæring.
- I stedet for å vente med opplæring og støtte til etter implementering, samarbeides det tett med brukerne og tilbyr kontinuerlig opplæring og støtte gjennom hele prosjektet, noe som øker brukertilfredsheten og aksept av løsningen.
- Kontinuerlig læring og retrospektiver.
- I stedet for å evaluere prosjektets suksess og forbedringer ved prosjektets slutt, benyttes kontinuerlig læring og retrospektiver for å forbedre prosjektet kontinuerlig og lære av erfaringene underveis. Dette gir muligheter for å identifisere og adressere utfordringer tidlig, samt tilpasse prosessen og metoder for å maksimere prosjektets suksess.
Du går videre til nytt oppdrag. 3 måneder senere får du en telefon, kunden er veldig fornøyd med hvordan du løste prosjektet og ønsker å diskutere videre muligheter for flere IT prosjekter med fokus på smidig endringsledelse.
Nøkkelen
I denne forenklede og fiktive, men likevel gjenkjennelige fortellingen om en IT-prosjektleders kamp for å navigere i de komplekse farvannene mellom prosjektledelse og endringsledelse, avdekker vi en viktig innsikt: Smidighet er nøkkelen. For å sikre en vellykket prosjektleveranse og langsiktig verdiskapning, må vi omfavne et smidig samspill mellom disse to disiplinene.
Ved å bruke en iterativ og inkrementell tilnærming, tidsbokset planlegging, hyppige releaser og kontinuerlig testing, kan prosjektledere skape en mer fleksibel og tilpasningsdyktig prosjektgjennomføring. Dette gjør det lettere å håndtere endringer og usikkerhet, redusere risiko og øke brukertilfredshet og aksept av løsningen.
Det er viktig å innse at rollene som prosjektleder og endringsleder ikke kan operere isolert, men heller må komplementere hverandre for å skape varig verdi for organisasjonen. Smidig samspill mellom IT-prosjektledelse og endringsledelse er nøkkelen til å transformere organisasjoners evne til å tilpasse seg, vokse og trives i møte med en digital hverdag i konstant endring.