Åtte av ti beslutningstakere i norsk privat og offentlig sektor har opplevd at IT-prosjekter sprekker på tid eller budsjett, ifølge en undersøkelse fra Respons Analyse. Det er ikke teknologien som er problemet.
De fleste prosjektene havarerer fordi risikoen aldri ble tatt på alvor tidlig nok. Fordi noen antok at kravene var avklart. Fordi ingen spurte hva som skjer hvis integrasjonen tar tre måneder lenger enn estimert. Fordi risikologgen lå i en mappe ingen åpnet etter kickoff.
Risikostyring handler ikke om å fylle ut skjemaer. Det handler om å stille de ubehagelige spørsmålene mens du fortsatt kan gjøre noe med svarene.
Er du nysgjerrig på hvilke feil som går igjen? Vi har samlet de vanligste i artikkelen om hvorfor IT-prosjekter feiler.
Hva er risikostyring i et IT-prosjekt?
Risiko vs. problem
En risiko er noe som kan skje. Et problem er noe som allerede har skjedd.
Skillet er avgjørende i praksis. Risikostyring handler om å identifisere og håndtere ting som ennå ikke har skjedd, mens du fremdeles har handlingsrom. Når risikoen er blitt et problem, er alternativene dyrere og færre.
God risikostyring betyr ikke at ingenting går galt. Det betyr at du er forberedt når det gjør det.
Hvorfor IT-prosjekter er mer risikoutsatt
En rapport fra Simula Research Laboratory viser at IT-prosjekter over 100 millioner kroner i snitt leverer rundt 30 prosent mindre nytte enn planlagt. 25 prosent av de største prosjektene blir stoppet eller leverer vesentlig under forventning.
IT-prosjekter kombinerer tre krevende elementer på én gang: teknologisk kompleksitet, organisasjonsendring og avhengigheter til systemer og leverandører utenfor din kontroll. Det krever systematisk risikostyring fra første dag.
De vanligste risikokategoriene
Teknisk risiko
Teknisk risiko er den mest åpenbare. Den er likevel ikke alltid den best håndterte. I prosjekter vi har fulgt hos kunder i offentlig forvaltning og finans er det sjelden ny teknologi som skaper de tyngste problemene. Det er integrasjoner mot eldre systemer ingen har full oversikt over.
Typiske tekniske risikoer er integrasjoner mot legacy-systemer med udokumentert oppførsel, avhengigheter til leveranser fra andre prosjekter, ytelseskrav som ikke er testet under reell last, og datamigrasjon som viser seg langt mer komplisert enn antatt.
Teknisk risiko bør inn i teststrategien fra dag én. En risiko som ikke er testet, er ikke avklart. Den er bare usynlig.
Organisatorisk risiko
Den mest underestimerte kategorien. Det er greit å planlegge for hva teknologien skal gjøre. Det er vanskeligere å planlegge for at nøkkelpersoner slutter, at forretningssiden ikke prioriterer akseptansetesting, eller at organisasjonen ikke er klar til å ta imot systemet når det er ferdig.
Manglende eierskap er en klassisk felle. Prosjektet har en prosjektleder, men ingen reell prosjekteier med beslutningsmyndighet. Beslutninger eskalerer. Avklaringer tar uker. Tidsplanen eroderer stille.
Med nesten 30 år i bransjen ser vi at prosjekter med en tydelig og engasjert prosjekteier lykkes markant oftere enn de uten.
Leverandør- og kontraktsrisiko
Outsourcing og systemkjøp fra eksterne leverandører introduserer avhengigheter du ikke styrer direkte. Leverandøren leverer for sent. Scope tolkes ulikt. Prisestimater dekker ikke det faktiske behovet. Kontrakten dekker ikke endringer som oppstår underveis.
Risikoregisteret bør inneholde konkrete scenarier for hva som skjer hvis leverandøren ikke leverer til avtalt tid. Hvem tar da beslutningen om veien videre?
Scope-risiko
Scope-kryp er IT-prosjektets stille dreper. Det starter med små justeringer. «Kan vi ikke bare legge til denne funksjonen?» Og ender med at prosjektet er dobbelt så stort uten at budsjett eller tidsplan er justert.
Årsaken er sjelden vond vilje. Det er uklare krav fra starten, kombinert med en prosjektleder uten mandat til å si nei. Scope-risiko håndteres med tydelig kravdokumentasjon, en etablert prosess for endringsbehandling og en styringsgruppe som forstår konsekvensene av endringsforespørsler.
Slik jobber du praktisk med risikostyring
Risikoregisteret
Risikoregisteret er prosjektets levende oversikt over identifiserte risikoer, vurderinger og tiltak. Det viktige ordet er «levende». Et register som oppdateres én gang i oppstartsfasen og aldri røres igjen, er verdiløst.
Et brukbart risikoregister inneholder for hver risiko: hva som kan skje, sannsynlighet, konsekvens, hvem som eier risikoen og hvilke tiltak som er planlagt eller iverksatt. Det trenger ikke være komplisert. Det trenger å bli brukt.
Risikomatrisen: sannsynlighet x konsekvens
Prosjektveiviseren, Digitaliseringsdirektoratets rammeverk for statlige IT-prosjekter, anbefaler risikomatrisen som standardverktøy. Du vurderer hver risiko langs to akser: sannsynlighet for at den inntreffer og konsekvens hvis den gjør det.
Høy sannsynlighet og alvorlige konsekvenser krever aktive tiltak. Lav sannsynlighet og begrensede konsekvenser kan du overvåke. Matrisens verdi er ikke presisjonen. Det er at den tvinger teamet til å prioritere hva som faktisk fortjener oppmerksomhet.
Hvem eier hvilken risiko?
Risikoer uten eiere blir ikke håndtert. Hver risiko i registeret trenger én navngitt person som følger opp tiltakene og melder tilbake. De trenger ikke løse det selv. Men de har ansvar for at noe faktisk skjer.
Når bør du jobbe aktivt med risiko?
Forprosjektet: der det koster minst
De 7 spørsmålene du bør stille før du starter et prosjekt inkluderer risiko som et sentralt tema. Det er i forprosjektet du har størst handlingsrom. Krav kan endres. Scope kan justeres. Leverandørvalg er åpne.
En risikoworkshop tidlig i forprosjektet, der prosjektleder, testleder og forretningssiden deltar, er blant de mest kostnadseffektive investeringene du kan gjøre. To timer med de rette menneskene identifiserer risikoer som ellers ville dukket opp som kriser seks måneder senere.
Underveis: fast punkt i statusmøtet
Risikostyring er ikke et engangsarbeid. Nye risikoer oppstår underveis. Eksisterende risikoer endrer karakter. Det som var lavprioritert i uke én kan bli kritisk i uke tolv.
Sett risikoregisteret fast på agendaen i statusmøtene. Ikke som en lang gjennomgang, men som et kort punkt. Hva har endret seg? Er det risikoer som har økt? Er det noe nytt som bør inn? Det tar fem minutter.
Testfasen som siste sikkerhetsnett
Testfasen er prosjektets siste mulighet til å avdekke risiko før systemet treffer sluttbrukerne. Den kan ikke kompensere for manglende risikostyring i de foregående fasene. Den synliggjør konsekvensene.
Les mer om testrelatert risiko og hvordan du håndterer den konkret, og om samspillet mellom prosjektleder og testleder i risikohåndteringen.
Hva er forskjellen på risiko og usikkerhet?
Risiko er en identifisert hendelse med kjent eller estimert sannsynlighet og konsekvens. Usikkerhet er det du ennå ikke vet. Risiko håndteres ved å planlegge for konsekvensene. Usikkerhet reduseres ved å innhente mer informasjon og teste tidlig. Et godt prosjekt arbeider aktivt med begge.
Hvem bør ha ansvar for risikostyring i et IT-prosjekt?
Prosjektlederen eier risikoregisteret og har det overordnede ansvaret. Testlederen bidrar med perspektiv på kvalitets- og testrelatert risiko. Styringsgruppen informeres om de mest kritiske risikoene og tar beslutninger der prosjektet ikke har mandat til å handle selv. Risikostyring fungerer dårlig som en oppgave som tilhører én person.
Hvor ofte bør risikoregisteret oppdateres?
Som minimum ved hver statusrapportering og ved alle milepæler. I prosjekter med høy endringstakt bør det skje ukentlig. Det viktigste er ikke frekvensen, men at det er satt av fast tid og at risikoeierne faktisk følges opp.
Risiko forsvinner ikke av seg selv
IT-prosjekter vil alltid innebære risiko. Målet er ikke å fjerne all usikkerhet. Det er å forstå hvilke risikoer som er akseptable, hvilke som krever tiltak, og hvem som eier hva.
Prosjekter som lykkes er sjelden de som unngår problemer. De er prosjektene der noen stilte de vanskelige spørsmålene tidlig nok, og der risikoeierskap var avklart lenge før krisene ble akutte.
Hos Aspiria jobber prosjektlederne våre med risikostyring som en integrert del av prosjektarbeidet. Vil du snakke om risikobildet i ditt neste prosjekt? Ta kontakt.