Derfor feiler IT-prosjekter

Hvert år går store summer tapt i IT-prosjekter som sporer av. De overskrider budsjett, forsinkes, leverer feil løsning, eller fullføres aldri. Ifølge Standish Group mislykkes over halvparten av alle IT-prosjekter på minst én av disse parameterne.

Fellesnevneren er sjelden teknologien. Det er menneskene, styringen og beslutningene rundt teknologien. Vil du ha en praktisk guide til hva god styring faktisk innebærer? Vi har samlet det viktigste i artikkelen om å lede digitale prosjekter uten overraskelser.

Med nesten 30 år bak oss i prosjekter for bank, offentlig forvaltning og telekom har vi sett de samme feilene igjen og igjen. Her er de vanligste – og hva som faktisk fungerer i stedet.

Utydelige mål og svak forankring

Altfor mange prosjekter starter uten et klart, konkret mål. Det finnes kanskje en idé eller en ambisjon, men ingen tydelig definisjon av hva som skal oppnås, hvem som eier målet og hva suksess ser ut som.

Enda verre blir det når ledelsen ikke er genuint involvert. Et prosjekt som mangler reell forankring hos beslutningstakerne, mister raskt legitimitet. Prioriteringer endres. Ressurser trekkes tilbake. Og til slutt er det ingen igjen som kjemper for at prosjektet lykkes.

Det som fungerer er å bruke tid i oppstartsfasen. Sørg for at prosjektets mål er konkret formulert, at alle forstår det, og at det er forankret hos dem med beslutningsmyndighet. Det høres selvsagt ut. Men vi har sett det glippe i store virksomheter med erfarne prosjektledere. Les mer om spørsmålene du bør stille før prosjektstart for å sikre at grunnmuren er på plass.

Prosjektet løser feil problem

Noen IT-prosjekter leverer nøyaktig det de ble bedt om – men ikke det organisasjonen faktisk trengte. Når man hopper rett til løsning uten å ha forstått problemet i dybden, ender man ofte opp med et system som skaper frustrasjon fremfor verdi.

Vi ser dette særlig i prosjekter der kravene skrives av IT-avdelingen alene, uten dialog med de som faktisk skal bruke løsningen. Systemet er teknisk korrekt. Det passer bare ikke inn i arbeidshverdagen.

Det som fungerer er å investere tid i innsikt og analyse tidlig. Gode prosjektledere stiller spørsmål og utfordrer premissene. Hva er den reelle verdien prosjektet skal skape? Hvem berøres, og hvordan ser behovene deres ut i praksis? Brukernes perspektiv må inn fra starten, ikke som en formalitet i et referansegruppemøte.

For svak styring og oppfølging

Prosjekter som strekker seg over mange måneder, med flere leverandører og skiftende prioriteringer, krever solid styring. Prosjektledere som henger etter, styringsgrupper som møtes sjelden og rapporter ingen leser. Det er kombinasjonen som lar problemer vokse seg store.

Svak styring viser seg gjerne som manglende oversikt over fremdrift, uklar ansvarsfordeling mellom leverandører og oppdragsgiver, og beslutningspunkter som utsettes i stedet for tas. Resultatet er prosjekter der alle mener noen andre har ansvaret for det som ikke fungerer.

Det som fungerer er en prosjektledelse som er tydelig, tilstedeværende og som tar tak i avvik tidlig. En erfaren IT-prosjektleder gir struktur, klargjør roller og sørger for at fremdriften faktisk følges opp, ikke bare rapporteres.

Brukerne involveres for sent

Et prosjekt som styres ovenfra uten løpende dialog med brukere og fagpersoner, mister retning underveis. Løsningen kan være teknisk vellykket og likevel møte motstand ved lansering – fordi de som skal bruke den aldri fikk si noe som helst.

Vi ser dette i offentlig sektor, der saksbehandlere får et nytt fagsystem i fanget som ingen har spurt dem om. Og i privat sektor, der salgsavdelingen får et CRM-system de ikke forstår og ikke bruker. Resultatet er lav adopsjon, bitterhet og et prosjekt som aldri realiserer den verdien det skulle.

Det som fungerer er korte feedbacksløyfer gjennom hele prosjektet. Hyppige demonstrasjoner. Brukertesting som faktisk gjennomføres med reelle brukere, ikke testere fra IT-avdelingen. Brukerne må bidra, ikke bare høres.

Endringer håndteres tilfeldig

Alle prosjekter møter endringer. Behov utvikler seg. Rammebetingelser endres. Ny innsikt kommer til. Det er ikke farlig i seg selv. Men hvis endringer håndteres tilfeldig, uten konsekvensanalyse og bevisste beslutninger, skapes det usikkerhet og tap av kontroll.

Det vanligste mønsteret: en interessent ber om en endring, utvikleren gjennomfører den, og verken prosjektleder, budsjett eller plan er involvert. Multipliser dette med tjue endringsforespørsler, og du har en forklaring på hvorfor prosjektet sprakk.

Det som fungerer er et endringsregime som gir rom for nødvendig tilpasning, men som sikrer at konsekvenser er vurdert og beslutninger er tatt av riktige personer. En aktiv styringsgruppe er avgjørende her.

Testledelse prioriteres bort

En av de vanligste beslutningene når et prosjekt er forsinket, er å kutte i testperioden. Det er forståelig under tidspress. Det er nesten alltid feil.

Feil oppdaget i produksjon er vesentlig dyrere enn feil oppdaget i test. De skaper driftsproblemer, krisehåndtering og ekstraarbeid for hele teamet. Og de undergraver tilliten til løsningen hos brukerne som møter dem.

God testledelse forebygger dette. En testleder som er med fra kravfasen og jobber systematisk gjennom hele prosjektet, gir deg et faktabasert beslutningsgrunnlag ved lansering. Du finner en fullstendig oversikt over beste praksis for testledelse i komplekse IT-prosjekter og hva som skiller prosjektene som lander trygt fra dem som ikke gjør det.

De fleste feil er forutsigbare

Det som er slående med disse feilene er at de er forutsigbare. De skjer ikke fordi noen er inkompetente eller uansvarlige. De skjer fordi prosjekter er krevende, og fordi presset for å komme i gang ofte overgår lysten til å sette ting skikkelig opp.

Prosjekter som lykkes, har som regel én ting til felles: noen som stilte de vanskelige spørsmålene tidlig, og holdt fast ved svarene gjennom hele løpet.

Vil du snakke om hvordan ditt neste prosjekt kan unngå disse fellene? Ta kontakt med oss for en uforpliktende prat, eller utforsk hva prosjektledelse hos Aspiria innebærer i praksis.

Ofte stilte spørsmål om IT-prosjekter som feiler