Fra Behov til Gevinster: Strategisk bistand i IT-prosjekter

I februar (2024) holdt min kollega Torkjell Flatland og jeg et webinar med tittelen «Unngå dyre fallgruver - Metoder for å lykkes med din IT-investering». Utgangspunktet for webinaret var vår undring over den konstant høye andelen av IT-prosjekter som feiler i en eller flere dimensjoner. Basert på vår brede erfaring innen IT-leveranser ønsket vi å dele våre erfaringer og presentere forslag til hvordan det neste prosjektet kan bli en suksess gjennom bevisste endringsprosesser.

Selvfølgelig er det ingen som planlegger at IT-prosjektene skal feile, eller at de ikke skal resultere i de ønskede gevinstene. De fleste virksomheter har en eller annen form for metode eller prosess som skal hindre nettopp ubehagelige overraskelser. Det er jo også slik at de aller fleste prosjekter ser strukturerte og lovende ut både før oppstart og i tidlige faser. Når man senere tar en titt i bakspeilet, viser det seg imidlertid at veien fra start til mål ble veldig annerledes enn det man forestilte seg før reisen begynte.

Når vi i etterpåklokskapens lys undersøker hvorfor en del IT-prosjekter ikke lykkes i en eller annen grad, starter det ofte med at man ikke har forstått virksomhetens faktiske behov.. Dette medfører at prosjektet kommer skjevt ut fra start og pådrar seg følgefeil som merkes gjennom hele prosjektets livsløp. Ikke minst merkes dette ved et stort antall endringsordre som endrer både fokus og prosjektets rammebetingelser. Symptomene ses gjerne også i etterkant ved at mange ansatte er misfornøyde med utfallet etter prosjektets slutt. I tillegg er det som regel ingen som har en oversikt over hvorvidt prosjektets leveranser faktisk har gitt den verdien man håpet på.

Business Consulting: IT-rådgivning gjennom dialog og samarbeid

Kunsten å velge den riktige IT-løsningen

Der mange trår feil, er å velge en IT-løsning for tidlig. Det kan være ansatte og ledere som i kraft av sin posisjon er overbeviste om hva som må til for å rette opp i en situasjon. Noen velger en IT-løsning delvis basert på at den har fått gode vurderinger hos ulike analyseselskaper, eller at den fungerer godt i andre virksomheter. Andre er bundet av virksomhetsovergripende teknologivalg som i praksis reduserer valgfriheten. Uansett årsak blir resultatet at fokus raskt rettes mot funksjonalitet, konfigurasjonsmuligheter og andre tekniske data.

Når det viktige første steget – å forstå hvilke utfordringer som egentlig må løses – glemmes i iveren etter å komme i gang, opplever fremdeles altfor mange store og små virksomheter at investeringene feiler. For å parafrasere Peter Drucker, er det verre å finne rett løsning på feil problem enn å fikse rett problem med feil løsning. Den praktiske konsekvensen ser vi i stadige overskrifter hvor store IT-satsinger må skrotes i sin helhet fordi de ikke løser det de skal.

Slik identifiserer vi årsaken, ikke problemet

Vi må starte med å forstå hva som foregår i virksomheten. Hva gjør vi, hvordan gjør vi det, og hvem gjør det? Kanskje må vi helt tilbake til «hvorfor gjør vi det?». Det essensielle i denne kartleggingen er at vi ender opp med en forståelse av hva problemene er, og ikke nøyer oss med hva vi kan se eller det vi opplever. På norsk er vi ikke så flinke til å skille mellom årsak og virkning; vi kaller alt «problemer». Men det er årsakene vi skal løse, ikke symptomene. Det er derfor det blir viktig for oss å se på årsakssammenhengen. Innsikten i å forstå hvorfor ting er som de er, kan være avgjørende informasjon senere i endringsprosessen for å unngå den berømte strikkeffekten der de ansatte jobber som før på tross av mulighetene nye IT-løsninger kan gi.

Nøkkelen til et vellykket IT-prosjekt

Vi argumenterer her for det åpenbare, men allikevel så vanskelige: En grundig behovsanalyse er helt nødvendig for å ende opp med rett løsning og dermed en IT-investering som gir verdi for virksomheten. Etter at virksomheten har brukt de nødvendige ressursene på behovsanalysen, er resultatet et korrekt grunnlag for en anskaffelse. Ved valg av leverandør og samarbeidspartner er det vesentlig at implementasjonen ivaretar både teknologi, prosesser og organisasjon. En god del leverandører er dyktige på én av disse – som regel teknologiområdet – men ikke like dyktige på de andre områdene. Utfallet kan bli en lite brukersentrert løsning som senere må gjennom flere endringer før den kan bli brukt effektivt av de ansatte.

Hvem har ansvaret for å realisere gevinsten av IT-prosjektet?

Når vi snakker om effektivitet er vi raskt over i et annet tema webinaret adresserte, nemlig gevinstrealisering. Dette er et tema som fremdeles er vanskelig å diskutere, og en vesentlig årsak til det er at det er så innlysende. Fordi det er så selvfølgelig at gevinstene må realiseres, vil mange virksomheter ikke engang tenke over at dette er et område som er utfordrende. All erfaring tilsier dessverre at det faktisk ikke er så lett. Det er flere grunner til det, men det mest åpenbare er at virksomheter sjeldent har en strukturert tilnærming til gevinsthåndtering. Det finnes ikke en prosess for det, og det er heller ingen som har fått ansvaret for realiseringen. De fleste har en mal for å sette sammen en business case, men den inneholder stort sett tall og mangler en ordentlig vurdering av hvordan tallene skal bli til virkelighet. En annen utfordring er at gevinstplanlegging ikke er del av IT-prosjektets scope, for der fokuserer det i regel på løsningen og prosjektets øvrige rammebetingelser.

Ikke len deg tilbake når prosjektet er sluttført

Den virkelige utfordringen gjør seg gjeldende når prosjektet har levert, ressursene er frigitt og ledelsen er fornøyd. Hverdagen har tatt over, og alle er opptatt med nye oppgaver som skal løses. Men det er nå gevinstrealiseringen faktisk starter. Det er først nå vi kan begynne å se om investeringen vil gi avkastning. Noen har nok en opplevelse av at prosjektets leveranser i seg selv er en garantist for gevinster. Det vil si at så lenge løsningen er på plass, vil gevinstene komme av seg selv. Virkeligheten er at prosjektet bare har gitt virksomheten et mulighetsrom. Dette mulighetsrommet gir et potensial for gevinster, men for å utnytte dette mulighetsrommet må noe endres for at vi skal oppnå en effekt. Det er denne effekten som til slutt vil gi oss en gevinst dersom vi velger å realisere den.

Dersom et IT-system gir oss muligheten til å spare inn ett visst antall timer, vil gevinsten først bli realisert dersom den tiden brukes til noe verdiskapende, eller at den brukes som et grunnlag for kostnadsbesparelser. Det betyr at leveransen bare vil gi en gevinst dersom noe endres.

Endring er en forutsetning for gevinstuttak

Endringshåndtering er også ett av disse temaene som skaper litt hodebry. Nødvendigheten for strukturert ledelse og håndtering av endringsreisen har vært opplest og vedtatt i en årrekke. Allikevel ser vi den samme mangelen på prosess og lunken støtte fra ledelsen som vi gjorde ved gevinsthåndtering. Resultatet er at endringshåndteringen ikke sjeldent blir begrenset til en prosjektrolle som i praksis har lite myndighet. Rollen har i et slikt scenario ikke den nødvendige tyngden for å lykkes.

På lik linje med at risikohåndtering ikke bare skal skje før et styringsgruppemøte, eller at testing ikke bare kan skje på slutten av prosjektet, må også endringshåndteringen være bygget inn i måten prosjektene blir utført. Fordi mange av endringsbehovene er (eller skal være) knyttet til hva som kreves for at gevinstene skal realiseres, må ansvaret kobles med en tilsvarende myndighet for å kunne lykkes. Dersom endringshåndteringen ikke tas alvorlig og får den nødvendige plassen i virksomheten, ender vi fort opp med at endringene ikke varer. Det kan bety at mange jobber på nøyaktig samme måte som tidligere, at man ikke har fått med seg de ansatte og at effektene dermed uteblir.

Iverksett en endringsprosess for å forstå hvordan du kan lykkes

Faktum er at man generelt burde stille høyere krav til at behovene faktisk forstås før det settes inn tiltak. Det gjelder måten å jobbe på like mye som valg av IT-løsning. Hvordan vet vi at å ansette en endringsleder vil løse noe? Hvordan vet vi at å innføre en prosess for gevinstrealisering vil øke avkastningen? Også her bør det vurderes å starte med begynnelsen: Hvor er vi i dag, hvor ønsker vi å være og hva ønsker vi å oppnå?

Når denne kunnskapen finnes, kan det lages en plan for å dekke deltaet mellom dagens situasjon og ønsket situasjon. Det litt ironiske er at vi må endre oss for å kunne håndtere endringer. En endringsprosess lar oss identifisere hva som må forandres slik at vi kan lykkes med IT-prosjekter i fremtiden, samt hvordan kompetent ledelse på toppnivå så vel som på prosjektledernivå er avgjørende for strategisk ansvars- og rollefordeling. Hvis vi innser at virksomheten må endres, kan vi starte en reise som tar oss strukturert fremover og løser de faktiske utfordringene.

Styrker og svakheter i bedriften

For å bistå med dette finnes det modenhetsanalyser innen ulike områder. Disse analysene gir gjennom en modenhetsskala innsikt i hva som kjennetegner en virksomhet på de ulike trinnene. Analysen kan benyttes som utgangspunkt til forbedringer, men kanskje enda viktigere er at den kan brukes til å skape bevissthet rundt virksomhetens styrker og svakheter. Med denne innsikten kan det innføres målrettede tiltak for å redusere sannsynligheten for kostbare feil i IT-anskaffelser, og øke mulighetene for å gjennomføre en effektiv overgang fra gammel til ny måte å jobbe på.

Det beste verktøyet for suksess, er å forstå hvordan vi bruker det

Oppmerksomheten vår trekkes fort mot teknologi, funksjonalitet, og andre ting vi synes er interessante. Det er for mange ikke så artig – og kanskje til og med slitsomt – å snakke om prosesser, om motstand, eller om hvorvidt noe lønner seg. Men de som tar dette på alvor og tar utgangspunkt i hvilke utfordringer som skal løses, lykkes bedre både i prosjektgjennomføringen og i gevinstrealiseringen.

Det er paradoksalt å hevde at vi har verktøyene vi trenger for å lykkes samtidig som andelen feilede IT-prosjekter over tid stort sett har forblitt på samme nivå. Men det er vår påstand at de fleste prosjekter ikke feiler fordi verktøyene ikke finnes, men snarere at de ikke brukes – eller at de ikke brukes riktig.