Derfor gikk på NAV på en IT-smell i milliardklassen

Prosjektnestoren Tom Gilb mener at de utallige budsjettsprekkene i IT-bransjen er fullstendig unødvendig.

– IT-ingeniører får like godt betalt for fiaskoer som vellykkede prosjekter. Faktisk kan de få mer betalt for å feile, fordi da kan de fakturere mer for å fikse problemet.

Tom Gilb har i flere tiår jobbet med risikostyring hos noen av verdens største selskaper. Hans metoder brukes blant annet av teknologigiganten Intel, som de siste to tiårene har brukt hans innsikter til å kurse tusenvis av sine ansatte.

Å bygge IT-systemer er fortsatt en fersk bransje, sammenlignet med å bygge veier og bruer. Bransjen har dermed fortsatt mye å lære, mener Gilb.

Han trekker frem NAV som eksempel: Da etaten skulle modernisere sine systemer, sprakk budsjettet med skyhøye 1,5 milliarder kroner. «Alt NAV har gjort har vært en fiasko», var den nådeløse dommen til Heidi Austlid, administrerende direktør i IKT-Norge. Milliarder av kroner hadde blitt brukt til konsulenter uten å levere det forventede resultatet.

Det gjorde at NAV-sjefen ble tvunget til å gå av.

NAV er imidlertid ingen enslig svane. Store, havarerte IT-prosjekter fyller mediene regelmessig med skandaleoppslag.

Statistikken er også et sørgelig skue. Rapporten «Suksess og fiasko i offentlige IKT-prosjekter» fra Universitetet i Oslo viser at om lag halvparten av norske IKT-prosjekter møter på store problemer og sliter med å levere på nytte, kostnad og tid. Én av fem IKT-prosjekter bruker dobbelt så mye enn det som opprinnelig var budsjettert. Én av ti prosjekter ender i regelrette fiaskoer.

Skipperen og seilskuten

På tross av at store tekniske prosjekter kan være krevende å styre, og mye kan gå galt, mener Gilb at det egentlig ikke er særlig komplisert å unngå saftige smeller. Han driver i dag Tekna-kurset Risikohåndtering i tekniske prosjekter, som lærer bort praktiske metoder for å styre risiko i tekniske og avanserte prosjekter.

Problemet er, ifølge ham, at det tar altfor lang tid før feil oppdages og gjøres noe med.

– Dette er risikohåndtering i et nøtteskall: Å skaffe seg tidlige varsler fra virkeligheten. Vi må måle fremgang ofte, og starte tidlig, sier Gilb.

Den rutinerte konsulenten sammenligner et veldrevet prosjekt med å styre en båt. Først må du stake ut et tydelig mål. Deretter må du hele tiden følge med på havstrømmene og vindretningen for å styre unna skjær og holde skuten på riktig kurs. Dersom du ikke samler inn informasjon om hvilken retning skuten har, og justerer seilene deretter, havner du lett på avveie.

Kvantifiser målene dine – også de myke

Det kan høres enkelt ut, men dette er noe som svært mange synder med, forteller Gilb. Mange har ikke engang tydelige og konkrete sluttmål.

– For å lykkes, må du kvantifisere målene dine. Ikke bare penger og andre klassiske kvantifiserbare størrelser, men også myke verdier, slik som sikkerhet og brukervennlighet. Mange vet ikke dette, sier Gilb.

Når målene er satt opp, må du dele opp prosjektet i mange delmål, forklarer han.

– Hvert delmål, eller «sprint», må gi verdi til bedriften. Det nytter ikke bare å skrive lange dokumenter med kode. Koden må også løse faktiske problemer. Her feiler altfor mange, sier Gilb.