Siden artikkelen «Vi kan få langt mer igjen for IT-investeringene»
ble publisert for et par uker siden, har det fått en del oppmerksomhet i
de kretsene jeg beveger meg i. Jeg har i hvert fall fått tilsendt
anbefalinger fra flere personer om å lese den så langt. Konklusjonen fra
artikkelen er at det offentlige burde strukturere IKT-prosjektene sine
mye mer smidig, slik som man også gjør i det private.
Det er ikke vanskelig å være enig i artikkelens analyse av problemet. Vi har i det siste sett en del offentlige IKT-prosjekter som har brukt fryktelig mye penger uten at de har produsert noen resultater, eller i hvert fall bare små resultater. Noen IKT-prosjekter har til og med brukt mye penger uten at de kom seg så langt som oppstartsfasen. Men jeg er ikke så sikker på om løsningen som artikkelen foreslår virkelig løser hele problemet.
For det første er ansvarskjeden i det offentlige skrudd sammen på en hel annen måte enn i det private. Når det kommer til stykket står man i en privatbedrift ikke til ansvar for noen andre enn aksjonærene. Oppstår det en konflikt, f.eks. fordi man er uenig i en satsning, kan aksjonærene velge å kaste ledelsen og få rettet opp kursen. Og aksjonærene som blir stilt i minoritet kan velge å selge sine aksjer, for heller å investere i en bedrift som gjør ting på en måte de liker bedre.
I det offentlige er denne øvelsen mye vanskeligere. I prinsippet kan man selvfølgelig alltid flytte til et annet land og til og med bytte statsborgerskap, men det er veldig få som gjør det p.g.a. et par mislykkede IKT-prosjekter i det offentlige.
Konsekvensen er at man i det offentlige er mye mer, og bør være mye mer forsiktig med å bruke skattepenger. Det er derfor ikke feil å kjøre et lite forprosjekt for å undersøke modenheten av en ny teknologi eller et nytt produkt, slik at man får tenkt seg godt om før man setter i gang et større prosjekt. I det private er det derimot mye lettere –og heller ikke feil– å komme i gang med en ny teknologi eller et nytt produkt, bare man får overbevist de riktige personene i bedriften.
Legg dog merke til at jeg skriver et lite forprosjekt, ikke et svært forprosjekt som noen ganger kan bli nesten like stort som selve hovedprosjektet. Da kan det fort bli for mye konsulenteri uten at det blir levert noen substans. Og for all del, forprosjektet må gjerne kjøres i form av en proof of concept istedenfor å bare produsere en rapport med mye tekst.
Men et annet problem som jeg har med artikkelen er at det også går i fella som heter survivorship bias. Når man henviser til vellykkede privatbedrifter som Amazon, Google, Facebook, Ebay, Netflix, Spotify, FINN.no (og de kunne ha lagt til LinkedIn), så må man huske at det også finnes titalls, om ikke hundretalls andre privatbedrifter som prøvde å gjøre akkurat det samme, men mislykkes. Ofte har de vært like smidige i utviklingsmetodikken sin som eksemplene nevnt ovenfor, men likevel mislykkes fordi de satset på feil teknologi, feil produkt, kom for tidlig til markedet, kom for sent til markedet, var lokalisert i feil land, eller bare hadde litt uflaks.
For offentlige prosjekter er det som regel ikke et problem å komme for tidlig eller for sent til markedet, fordi staten har monopol på en del tjenester og derfor definerer markedet selv. Men når det gjelder teknologi- og produktvalg er det offentlige like mye utsatt for feilvalg som en enkelt privatbedrift, samtidig som det ikke kan dra nytte av markedsøkonomien i form utvelgelsesprosessen blant mange privatbedrifter samlet for å kåre vinneren. Og det betyr at hvis et offentlig prosjekt satser på feil teknologi eller feil produkt for å implementere en tjeneste, så vil man bli sittende med dette valget i potensielt mange år fremover.
Jeg har flere ganger vært vitne til offentlige prosjekter der man har tatt en sjanse på en ny teknologi eller et nytt produkt, og bommet skikkelig. Noen ganger var det fordi man var for tidlig ute, noen ganger fordi man rett og slett hadde uflaks. Men har man først valgt feil teknologi eller feil produkt, er det vanskelig å komme seg ut av det uten at det fører til store ekstrakostnader. Da vil man heller prøve å stå løpet ut, selv om det betyr at det vil være stadig vanskeligere å finne folk som vil jobbe på prosjektet, og stadig vanskeligere å videreutvikle prosjektet eller vedlikeholde det.
I mange av disse tilfellene hadde smidig utvikling ikke endret noe på utfallet av prosjektet. Noen av disse tilfellene var faktisk smidige prosjekter. Men fordi teknologi- og produktvalg er et binært valgt –man bruker det, eller man bruker det ikke– hjelper det ikke å prøve seg litt frem i begynnelsen, og ta små skritt. At man har valgt feil teknologi eller produkt er dessuten noe man ofte ikke får vite før et par år etterpå, og da er det for sent.
Så ja, det er surt å se at en masse skattepenger blir brukt på store forprosjekter uten at det kommer noe nyttig ut av det (hvis man snevrer begrepet nyttig inn til «kjørende kode»). Det er også surt å se at noen IT-systemer hindrer viktige og nødvendige lovendringer. Og det er sikkert riktig at smidig utvikling i mange tilfeller vil kunne gi mer verdi for pengene enn hva som er tilfellet nå. Men nei, heller ikke smidig prosjektutvikling ville kunne gi noen garantier for suksess i alle offentlige IT-investeringer. Det er en viktig nyanse å huske, slik at ikke smidig prosjektutvikling i seg selv får skylden neste gang det oppstår problemer i et offentlig IKT-prosjekt.
Det er ikke vanskelig å være enig i artikkelens analyse av problemet. Vi har i det siste sett en del offentlige IKT-prosjekter som har brukt fryktelig mye penger uten at de har produsert noen resultater, eller i hvert fall bare små resultater. Noen IKT-prosjekter har til og med brukt mye penger uten at de kom seg så langt som oppstartsfasen. Men jeg er ikke så sikker på om løsningen som artikkelen foreslår virkelig løser hele problemet.
For det første er ansvarskjeden i det offentlige skrudd sammen på en hel annen måte enn i det private. Når det kommer til stykket står man i en privatbedrift ikke til ansvar for noen andre enn aksjonærene. Oppstår det en konflikt, f.eks. fordi man er uenig i en satsning, kan aksjonærene velge å kaste ledelsen og få rettet opp kursen. Og aksjonærene som blir stilt i minoritet kan velge å selge sine aksjer, for heller å investere i en bedrift som gjør ting på en måte de liker bedre.
I det offentlige er denne øvelsen mye vanskeligere. I prinsippet kan man selvfølgelig alltid flytte til et annet land og til og med bytte statsborgerskap, men det er veldig få som gjør det p.g.a. et par mislykkede IKT-prosjekter i det offentlige.
Konsekvensen er at man i det offentlige er mye mer, og bør være mye mer forsiktig med å bruke skattepenger. Det er derfor ikke feil å kjøre et lite forprosjekt for å undersøke modenheten av en ny teknologi eller et nytt produkt, slik at man får tenkt seg godt om før man setter i gang et større prosjekt. I det private er det derimot mye lettere –og heller ikke feil– å komme i gang med en ny teknologi eller et nytt produkt, bare man får overbevist de riktige personene i bedriften.
Legg dog merke til at jeg skriver et lite forprosjekt, ikke et svært forprosjekt som noen ganger kan bli nesten like stort som selve hovedprosjektet. Da kan det fort bli for mye konsulenteri uten at det blir levert noen substans. Og for all del, forprosjektet må gjerne kjøres i form av en proof of concept istedenfor å bare produsere en rapport med mye tekst.
Men et annet problem som jeg har med artikkelen er at det også går i fella som heter survivorship bias. Når man henviser til vellykkede privatbedrifter som Amazon, Google, Facebook, Ebay, Netflix, Spotify, FINN.no (og de kunne ha lagt til LinkedIn), så må man huske at det også finnes titalls, om ikke hundretalls andre privatbedrifter som prøvde å gjøre akkurat det samme, men mislykkes. Ofte har de vært like smidige i utviklingsmetodikken sin som eksemplene nevnt ovenfor, men likevel mislykkes fordi de satset på feil teknologi, feil produkt, kom for tidlig til markedet, kom for sent til markedet, var lokalisert i feil land, eller bare hadde litt uflaks.
For offentlige prosjekter er det som regel ikke et problem å komme for tidlig eller for sent til markedet, fordi staten har monopol på en del tjenester og derfor definerer markedet selv. Men når det gjelder teknologi- og produktvalg er det offentlige like mye utsatt for feilvalg som en enkelt privatbedrift, samtidig som det ikke kan dra nytte av markedsøkonomien i form utvelgelsesprosessen blant mange privatbedrifter samlet for å kåre vinneren. Og det betyr at hvis et offentlig prosjekt satser på feil teknologi eller feil produkt for å implementere en tjeneste, så vil man bli sittende med dette valget i potensielt mange år fremover.
Jeg har flere ganger vært vitne til offentlige prosjekter der man har tatt en sjanse på en ny teknologi eller et nytt produkt, og bommet skikkelig. Noen ganger var det fordi man var for tidlig ute, noen ganger fordi man rett og slett hadde uflaks. Men har man først valgt feil teknologi eller feil produkt, er det vanskelig å komme seg ut av det uten at det fører til store ekstrakostnader. Da vil man heller prøve å stå løpet ut, selv om det betyr at det vil være stadig vanskeligere å finne folk som vil jobbe på prosjektet, og stadig vanskeligere å videreutvikle prosjektet eller vedlikeholde det.
I mange av disse tilfellene hadde smidig utvikling ikke endret noe på utfallet av prosjektet. Noen av disse tilfellene var faktisk smidige prosjekter. Men fordi teknologi- og produktvalg er et binært valgt –man bruker det, eller man bruker det ikke– hjelper det ikke å prøve seg litt frem i begynnelsen, og ta små skritt. At man har valgt feil teknologi eller produkt er dessuten noe man ofte ikke får vite før et par år etterpå, og da er det for sent.
Så ja, det er surt å se at en masse skattepenger blir brukt på store forprosjekter uten at det kommer noe nyttig ut av det (hvis man snevrer begrepet nyttig inn til «kjørende kode»). Det er også surt å se at noen IT-systemer hindrer viktige og nødvendige lovendringer. Og det er sikkert riktig at smidig utvikling i mange tilfeller vil kunne gi mer verdi for pengene enn hva som er tilfellet nå. Men nei, heller ikke smidig prosjektutvikling ville kunne gi noen garantier for suksess i alle offentlige IT-investeringer. Det er en viktig nyanse å huske, slik at ikke smidig prosjektutvikling i seg selv får skylden neste gang det oppstår problemer i et offentlig IKT-prosjekt.
Geen opmerkingen:
Een reactie posten