En undersøkelse fra Respons Analyse, omtalt av Digi.no, viser at åtte av ti beslutningstakere i norsk privat og offentlig sektor opplever at IT-prosjekter sprekker på tid og budsjett. De fleste problemene som viser seg midtveis, eller i ukene før go-live, ble plantet i oppstarten. Her er de ti feilene vi ser oftest – og hva som faktisk hjelper.
Det handler sjelden om teknologien. Det handler om hva som ikke ble avklart, hvem som ikke ble involvert, og hvilke spørsmål ingen torde å stille høyt.
1. Målene er for løst definert
«Vi skal lage et nytt system» eller «vi trenger noe mer moderne» er ikke mål. Det er ønsker. Problemet er at alle nikker og tror de er enige, men når leveransen skal vurderes, viser det seg at ingen hadde samme bilde i hodet.
Vær konkret fra dag én. Hva skal prosjektet faktisk oppnå? Hvem skal få nytte av det, og hvordan ser suksess ut om ett år? Fokuser på verdien for brukeren og virksomheten, ikke på løsningen i seg selv. Et prosjekt uten tydelige mål er et prosjekt uten retning.
2. Forankringen er for svak
Et prosjekt uten støtte fra ledelsen mister prioritet når det butter. Beslutninger blir utsatt. Ressurser trekkes tilbake. Det som startet som et viktig initiativ, havner bakerst i køen.
Sørg for at prosjektet har en tydelig prosjekteier som er synlig og involvert, ikke bare på papiret. En styringsgruppe som faktisk følger opp og tar beslutninger, gjør en større forskjell enn de fleste tror. Vi ser det tydelig i prosjekter i offentlig forvaltning: når eierskap er uklart i starten, bruker man mye tid på å rydde opp i det midt i leveransen.
3. Ingen vet hvem som bestemmer hva
«Alle» er med i prosjektet, men når en beslutning må tas, ser alle på hverandre. Rolleavklaring som ikke er gjort tidlig, er en av de sikreste kildene til friksjon og forsinkelse vi kjenner til.
Det trenger ikke å bli et 40-siders ansvarsmatrisedokument. Det holder å avklare hvem som har ansvar for hva, hvem som tar hvilke beslutninger, og hvem som må konsulteres når noe er uklart. Gjort tidlig tar det en time. Gjort sent koster det uker. En erfaren IT-prosjektleder gjør nettopp dette fra dag én.
4. Planleggingen nedprioriteres
Tidspress er den vanligste grunnen til at prosjekter hopper over planleggingsfasen. «Vi begynner å levere, så planlegger vi underveis.» Resultatet er at ting må gjøres om, prioriteringer kolliderer, og ingen har oversikt over hva som faktisk gjenstår.
En gjennomtenkt plan gir forutsigbarhet og trygghet, og sparer for ekstraarbeid og omkamper senere. Å lede digitale prosjekter uten overraskelser handler i stor grad om å bruke nok tid i starten til å unngå kaos i midten.
5. Viktige interessenter blir oversett
I mange prosjekter er det folk som burde vært med fra starten, men som ikke blir involvert før langt ut i løpet. Da er det gjerne for sent å gjøre det enkelt. Krav endres. Løsninger må skrives om. Motstand oppstår sent i prosessen, der den koster mest.
Lag en enkel oversikt tidlig: hvem påvirkes av dette prosjektet, hvem sitter på viktig innsikt, og hvem må involveres aktivt fremfor kun informeres? Det tar ikke lang tid, men gir stor effekt.
6. Forventningene er aldri eksplisitt avtalt
Prosjektgruppen tror én ting. Bestilleren tror noe annet. Begge er i god tro, og begge kan vise til det samme møtereferatet. Dette er en av de vanligste kildene til konflikt vi ser mot slutten av prosjekter.
Snakk konkret og tidlig om hva «ferdig» betyr. Hva slags kvalitet forventes? Hva er godkjenningskriteriene? Hva er ikke en del av leveransen? Det er ubehagelig å ta de samtalene tidlig, men langt mer ubehagelig å ta dem når leveransen er klar og noen er skuffet.
7. Ingen har forstått dagens situasjon godt nok
Mange prosjekter hopper rett til løsning uten å forstå problemet de faktisk skal løse. Det gir løsninger som teknisk sett fungerer, men som ikke treffer behovet. Brukerne tilpasser seg, eller finner seg andre måter å jobbe på.
Bruk tid på å forstå hvordan ting fungerer i dag, hva som er de faktiske smertepunktene, og hva som faktisk må bli bedre. I prosjekter vi kjenner fra helse og offentlig forvaltning, er dette steget som oftest hoppes over, og oftest angres på.
8. Teknologivalget er tatt for tidlig
Noen ganger er teknologien valgt før prosjektet egentlig har startet. Det kan skje fordi en leverandør allerede er valgt, fordi noen i ledelsen har bestemt seg, eller rett og slett fordi det virket åpenbart. Problemet oppstår når løsningen ikke passer behovet, og kostnadene ved å tilpasse blir store.
Finn først ut hva brukerne trenger og hva virksomheten krever. Velg teknologi etterpå. Det er en anbefaling som ikke alltid lar seg følge fullt ut, men prinsippet bør være styrende: behov definerer løsning, ikke omvendt.
9. Risiko blir ikke snakket om
I starten ser alt lyst ut. Det er energi i rommet, og alle vil komme i gang. Det er et godt tegn. Men det betyr ikke at risikoer ikke finnes, bare at ingen har tatt seg tid til å se etter dem.
Lag en enkel risikovurdering tidlig. Hva kan skape trøbbel? Hva har vi ikke full kontroll på? Hva er plan B hvis en kritisk avhengighet faller bort? En risikovurdering trenger ikke å være komplisert for å være nyttig. Det holder å stille spørsmålene systematisk og eie svarene.
10. Metodikken passer ikke prosjektet
Det finnes mange rammeverk for prosjektgjennomføring, og alle har sine styrker. Men å følge en metode slavisk, uavhengig av hva prosjektet faktisk krever, gir sjelden gode resultater. Et lite, avgrenset digitaliseringsprosjekt trenger ikke den samme styringsmodellen som et flerårig systembytte.
Tilpass metoden til virkeligheten, ikke omvendt. Det viktigste er at teamet har en felles forståelse for hvordan dere jobber, hvem som bestemmer hva, og hva som skjer når noe ikke går som planlagt. Les mer om beste praksis for testledelse og prosjektgjennomføring i komplekse prosjekter.
Hva de ti feilene egentlig handler om
De fleste av disse feilene har én ting til felles: de handler ikke om teknologi. De handler om uklarhet. Uklare mål, uklare roller, uklare forventninger og uklare risikoer.
Et IT-prosjekt som starter med teknisk klarhet, men menneskelig uklarhet, er et prosjekt som er i trøbbel fra dag én. Det vi ser igjen og igjen, på tvers av bank, offentlig forvaltning og telekom, er at prosjektene som lykkes ikke nødvendigvis er de som starter raskest. De er de som starter best. De brukte litt ekstra tid i starten på å sikre at alle hadde samme bilde, og at de viktigste spørsmålene var stilt og besvart før leveransen begynte.
En god start er noe du aldri angrer på
Med nesten 30 års erfaring fra prosjekter i bank, finans, telekom og offentlig forvaltning har vi i Aspiria sett det meste av hva som kan gå galt. Og vi har sett at de samme feilene gjentar seg, prosjekt etter prosjekt, bransje etter bransje. Ikke fordi folk er uforsiktige, men fordi starten av et prosjekt er den fasen der presset om å komme i gang er størst, og der det er lettest å hoppe over det som egentlig er viktigst.
En god start koster lite, men gir mye igjen.
Lurer du på om prosjektet ditt har den riggen det trenger? Les våre 7 spørsmål du bør stille før du starter et prosjekt, eller ta kontakt med oss for en uforpliktende prat om prosjektledelse.
Ofte stilte spørsmål om prosjektstart og IT-prosjekter
Hva er de vanligste feilene ved oppstart av IT-prosjekter?
De vanligste feilene er løst definerte mål, svak forankring hos ledelsen, uklare roller og ansvar, og manglende involvering av viktige interessenter. I tillegg hoppes risiko- og forventningsavklaringer ofte over fordi presset for å komme i gang er stort. De fleste problemene som oppstår midtveis i et prosjekt, ble plantet i oppstartsfasen.
Hva bør avklares før et IT-prosjekt starter?
Før oppstart bør dere ha klare svar på hva prosjektet skal oppnå, hvem som eier prosjektet, hvem som tar hvilke beslutninger, hvilke interessenter som må involveres og hva suksess ser ut som. I tillegg bør forventninger til kvalitet og leveranse eksplisitt avtales, og en innledende risikovurdering gjennomføres.
Hvorfor overskrider så mange IT-prosjekter tid og budsjett?
Ifølge norske undersøkelser sprekker åtte av ti IT-prosjekter på tid eller budsjett. Årsaken er sjelden teknisk. Det handler om uklare mål, svak styring, endringer som håndteres tilfeldig og manglende involvering av brukerne. Prosjekter som investerer tid i en solid oppstart, har markant bedre sjanser for å levere innenfor rammene.
Når bør en prosjektleder involveres?
Fra dag én. En erfaren prosjektleder bidrar til å strukturere oppstarten, avklare roller, sette opp en realistisk plan og identifisere risiko tidlig. Prosjekter som henter inn prosjektledelse etter at problemene har oppstått, betaler alltid mer enn om de hadde gjort det fra start.
Hva er forskjellen på en god og dårlig prosjektstart?
En god prosjektstart kjennetegnes av tydelige mål, forankret eierskap, avklarte roller, realistisk planlegging og åpen dialog om risiko og forventninger. En dårlig start kjennetegnes av at noen av disse elementene mangler, gjerne fordi presset for å komme i gang er sterkere enn lysten til å tenke seg om.