Risiko og innovasjon
“No pain – no gain”. “Den som intet våger intet vinner”. Alle forstår at om vi vil oppnå noe bra så innebærer det ofte også en viss risiko. Slik er det selvsagt også med IT-prosjekter. Men hvordan forholder vi oss til risiko i IT-prosjekter? Hva slags strategi skal vi ha for å håndtere denne?
Mye tyder på at vi er i ferd med å bli alt for risiko-averse i dette landet. Særlig i offentlig sektor, hvor vi virkelig trenger innovasjon!
Tankegangen innen innkjøp, styring og ledelse er at vi må forsøke å eliminere risikoen ved å gjøre grundige foranalyser, gjerne forprosjekter, før vi tar på oss økonomiske forpliktelser. Dette er intuitivt og fornuftig i mange sammenhenger. Grundig analyse og planlegging gjør at selve gjennomføringen går på skinner. Dette er sant, gitt noen rammebetingelser nemlig at vi
a) er i stand til å overskue og forstå problemet gjennom analyser og
b) har en grad av stabilitet underveis slik at forutsetningene vi må legge i starten ikke endrer seg
Men hvor godt fungerer denne tankegangen for IT-prosjekter? Har vi disse rammebetingelsene? Klarer analyser å gi oss den nødvendige forståelsen og har vi denne stabiliteten?
I offentlig sektor skal IT-prosjekter gjennom kvalitetssikringsmilepælene KS1 og KS2. Dette representerer to nivåer av beslutningsgrunnlag – for å sikre at vi bruker penger på prosjekter som gir større nytteverdi enn de koster. Dette er svært rigorøse og omfattende prosesser. I moderniseringsprosjektet til NAV kan vi lese et 177-siders dokument som er kvalitetssikringen av KS1 – konseptvalg (Takk til Tom Gilb som viste meg dette). Det er lett å se at dette skal bli et gigantprosjekt! Nesten et år senere (april 2012) kommer KS2-av prosjekt 1 et dokument på ca 100 sider. Deretter skal prosjektet utlyses på anbud, løsningsbeskrivelser og kravspesifikasjoner skrives osv.. Vi snakker 3-4 år før noen begynner å lage en kodelinje. Nå vet vi jo også fasiten – prosjektet ble stoppet og 3-4 år av moderniseringen gikk tapt. Pluss noen hundre millioner kroner. NAV-direktør Joachim Lystad uttaler i 2015:
Hovedårsaken til det var at det i 2010 ble planlagt å kombinere ny saksbehandlingsløsning for Nav med en løsning for uførereformen. Det viste seg å være feil.
En antagelse tatt for mange år siden fikk med andre ord leve lenge i prosjektet før man fant ut at den var feil…
Systemet legger opp til følgende håndtering av risiko: Jo større prosjekter, desto grundigere analyser og forarbeide. Samtidig vet vi at de som gjør dette forarbeidet er spesialister på nettopp dette – så de vil sette sin ære i å gjøre dette grundig og komplett. Vi vet jo også at de konsulentselskapene som leverer analysene vil ha noe å tjene på at omfanget blir stort. Derfor ser vi gang på gang at noe som i utgangspunktet er stort, lett blir enda større i analysefasen! Det er mange krefter som spiller inn her, blant annet a alle interessentene vet at det blir lenge til neste prosjekt, så de vil presse på for å komme med i prosjektet – og det blir enda større! Vi må også være klar over at verden rundt oss er omskiftelig og dynamisk, slik at sannsynligheten for at antagelser rekker å bli utdaterte allerede mens vi analyserer og planlegger er stor…
Uheldige virkninger av grundig, tidkrevende forarbeid
Og så kommer MilliardKronerSpørsmålet: “Hvor gode betingelser har et slikt prosjekt for å lykkes?” Ikke så veldig gode. Det finnes mange studier som analyserer IT-prosjekter. Disse er ikke alltid samstemte, bortsett fra en ting: Samtlige advarer mot å kjøre store prosjekter!
Vi som har vært ute en vinterdag eller to ser dette lett. IT-prosjekter er komplekse og for mange overraskende vanskelig å spesifisere korrekt på forhånd. Til det er behovene for ulne og abstrakte, og antall krav får fort en uhåndterlig størrelse. Dessuten blir selve prosjektet selv et svært komplekst, dynamisk sosialt system. Og til alt overmål har vi dynamikken, de uventede hendelsene (som vi vet kommer) og ønsket om innovasjon.
Store prosjekter kommer fort inn i en ond sirkel med økende kompleksitet og liten tid til innovasjon
Innovasjon betyr blant annet å ta vare på de gode ideene og mulighetene som oppstår underveis.
Alle disse sammenhengene skulle borge for å forsøke å unngå store prosjekter. Men disse sammenhengene er på en måte ikke det mest skremmende! Det mest skremmende er at i store prosjekter med få leveranser, vil feilaktige antagelser få lov til å leve alt for lenge. Dette er et system uten feedback, uten læring slik at den akkumulerte økonomiske risikoen blir skyhøy! Vi vet per definisjon ikke om det har vært vellykket før leveransen er idriftsatt og vi kan analysere hvordan den faktisk fungerte i praksis.
“The proof of the pudding is in the eating”
Britene vet at det er overraskende vanskelig å lage en perfekt pudding. Vi vet ikke om resultatet ble vellykket før puddingen er ferdig. Akkurat på samme måten er det med IT-prosjekter.
Dette innebærer at jo lengre vi venter med å fullføre noe, desto større akkumulert økonomisk risiko tar vi. Dette er jo innkjøpere og prosjekteiere klar over, men resepten med å analysere enda grundigere for å minske risikoen duger altså ikke. I stedet kan vi ta virkeligheten på alvor og akseptere usikkerhet og risiko.
Vi kan lære oss å surfe på bølgen som kommer i stedet for å forsøke å stoppe den – det er en bedre strategi å forsøke å forstå og beherske naturen enn å prøve å motvirke den.
Om vi deler opp problemet i små biter og legger opp til mange små leveranser kan vi oppnå flere ting. Vi vil da kunne “smake på puddingen” og validere resultatet om igjen og om igjen og på den måten absorbere risikoen.
Løpende validering av antagelser for å unngå å akkumulere opp risiko
Figuren viser hvordan vi ved å levere resultatet i små inkrementer vil kunne “spise opp risikoen” underveis. (Enkelte ganger -hvis nyhetsgraden er stor – vil det første trinnet måtte ta noe lengre tid enn de andre. Dette trinnet kan også romme forretningsutvikling). Dessuten vil vi i dette regimet ha mye bedre betingelser for innovasjon. Her er det unødvendig å ha et ferdig omfang på forhånd, siden vi hele tiden får feedback og kan la detaljene bli til underveis. Vi kommer ikke på etterskudd for det er ikke inngått forpliktende, langsiktige løfter. Nå ser vi at det er rekkefølgen vi løser problemet i som blir avgjørende. Vi spør oss hele tiden “hva er det neste vi skal lage som vil gi oss maksimal validering av antagelser?“. Dette regimet er altså basert på en løpende finansiering. Vi validerer resultatet og gjør kost/nytte vurderinger hele tiden. Gevinstrealiseringen er innbakt i prosessen. Vi manøvrerer her i usikkert farvann i stedet for å låse oss til en fast kurs – og håpe det beste.
På denne måten ser vi at vi fint kan “slippe unna” med langt mindre forarbeide, siden vi insisterer på å ikke ta på oss store økonomiske forpliktelser. Om sponsorer og eiere gjennom feedbacken finner ut at det er riktig å avbryte (enten fullstendig eller for å justere kursen), så må de ha mulighet til det. Kunsten å stoppe i tide er avgjørende!
In: inkrementell utvikling, kompleksitet, ledelse, Planlegging, Samfunn · Tagged with: innovasjon, ledelse, prosjektstyring, Smidig, Styring