Prosjektveiviseren er naken

Magnus Carlsen. For en hjerne. 23 år og verdensmester i en av verdens mest komplekse spill.  Det er så mange mulige kombinasjoner av trekk man kan gjøre. Flere enn det er atomer i universet. Hvordan skal man vite hvilket trekk som er det beste i enhver situasjon? Jeg tror han må være veldig god til å planlegge.  Han tenker fremover, ser for seg alle mulighetene ved de forskjellige trekkene, så velger han løsningen som fungerer best.

Jeg får det ikke til. Jeg planlegger etter beste evne. Bruker lang tid før hvert spill. Jeg tenker nøye gjennom hvert eneste trekk, planlegger de beste trekk for både meg og motspilleren min. Følger planen slavisk. Men fortsatt taper jeg nesten hver gang. Nå er jeg oppe i flere dager med forberedelser i forkant før jeg begynner å spille. Men det er alltid et eller annet skjærer seg i forhold til planen. Motspilleren min velger alltid noe annet enn det jeg planla at hun skulle. Jeg må nok planlegge bedre, forberede meg lengre.

Kan noen se hvilken feil jeg gjør her? Jeg vil håpe den er ganske åpenlys for de fleste.  I et så komplekst spill som sjakk holder det selvsagt ikke å planlegge trekkene før spillet begynner. Man må tenke og planlegge hele veien gjennom. Faktisk må man tenke mer og mer jo lengre inn i spillet man kommer. De første trekkene går gjerne ganske fort. Det er når spillet begynner å komme godt igang at man virkelig må planlegge nøye. Det samme gjelder også software-utvikling.

Staten bruker mange hundre millioner kroner hvert år på utvikling av ny programvare. Som mange har fått med seg, så feiler de fleste store IT-prosjekter. De koster mye mer enn antatt, tar flere ganger så lang tid som antatt og fører altfor ofte til systemer ingen kan bruke. Vet dere hvorfor de feiler? I følge rapportene prosjektlederne skriver i etterkant er den største grunnen “for dårlig planlegging i oppstartsfasen”.

Det er dette prosjektlederne har lært i sine prosjektleder-skoler.  “Failing to plan, is planning to fail” er mantraet. Når ting ikke går etter planen, er det per definisjon planen det er noe feil med.  Løsningen er alltid mer planlegging. Eller som det sies i ”The first rule of bad management: When something isn’t working, do more of it”. Jeg var nylig på et seminar om gevinstrealisering i statlige IT-prosjekter. Der rapporterte noen at de hadde brukt 2 hele år på å planlegge et software-utviklings-prosjekt. “Men da de begynte å jobbe på det, så de fort at selv 2 år ikke hadde vært nok.”

Jeg er en statlig tilsatt programmerer og jeg har fått nok. Jeg vil ikke lenger være med på å kaste bort våre dyrbare skattepenger på
å løse feil problem. Problemet vårt er ikke dårlig planlegging og dårlige estimater før vi begynner. Problemet vårt er at vi legger altfor detaljerte planer altfor tidlig, og tror at disse kommer til å holde 2 år etter vi skrev dem.

Software er mye mer komplekst enn de aller fleste produkter vi har med å gjøre.  Produkter, fysiske såvel som software-applikasjoner, er mer kompliserte jo flere deler de består av, spesielt hvis delene er bevegelige.  I software er typisk mengden “bevegelige deler” astronomisk iforhold til vanlige fysiske produkter.  En mikrobølgeovn kommer med instrukser – “ikke putt levende dyr inn i ovnen”. Hvis katta dør i mikroen, så er det din skyld.  Man kunne sett for seg at alle mikrobølgeovner kom med sensorer som kjente igjen levende dyr, og nektet å skru seg på hvis det var noe levende oppi. Men alle skjønner at det hadde gjort produktet mer kostbart. I software-verdnen er kostnaden av å legge til en “katte-sensor” betydlig mindre. Dermed gjør man gjerne det. Sammen med en hel drøss andre funksjoner som kommer godt med nå og da. Kostnaden er mindre enn ved fysiske produkter, men den er mye større enn de fleste uten programmeringserfaring ser for seg.  Hver ekstra bit av funksjonalitet øker kompleksiteten. 

I tillegg skjer det hele tiden endringer i hvordan software brukes. På få år har folk begynt å surfe nettet med nettbrett og smarttelefoner. Hva blir det neste store? Smartklokker? Google glass? Hvem vet. Teknologien endrer seg, nye tjenester, nye datakilder blir tilgjengelige stadig vekk.  Ved oppstart av prosjektet aner vi ikke hvor verden vil være ved slutten.  

Vi er nødt til å tenke annerledes enn vi gjør idag. Vi har muligheten til å spare millioner samtidig som vi får bedre IT-systemer. Hva må gjøres rent konkret? Jeg har ingen fasit, men jeg har noen forslag. 

For det første må vi slutte å organisere software-utvikling som prosjekter som settes ut på anbud.  Anbudsprosessen er en av hoveddriverne til en tung planleggingsfase før oppstart. Før man kan sette noe ut på anbud, må det defineres krav.  Flere år går med på å skrive disse.  Kravspesifikasjonen sendes så ut i verden. Konsulentselskapene samler sine beste teknologer, som kommer med estimater – vel vitende om de ikke kommer til å stemme overhodet. De gjør sitt beste, men vet godt at de bare gjetter. Når de er ferdige kutter salgsavdelingen estimatene slik at tilbudet blir konkurransedyktig.  Dette er ingen overdrivelse. Dette er sånn det skjer.  Jeg har vært konsulent selv, og kjenner mange andre.
Et år til går, mens tilbudene evalueres. Så kan man endelig begynne arbeidet.  Sjansene for at planen allerede er utdatert er høy.  Men incentivene til både kunde og leverandør er å holde seg mest mulig til planen. Endringer koster dyrt. De som ser muligheter til bedre løsninger blir hysjet ned – endringer og avvik i forhold til planen har vi ikke råd til. Prosjekt-suksess måles i hvor nøye man fulgte planen, ikke hvor bra produktet ble.

Så hva kan skal vi gjøre istedenfor? De fleste statlige etater som tilbyr software av noe slag, har også en stab med software utviklere som forvalter disse applikasjonene.  Jeg jobber selv i en slik organisasjon. I forvaltningsverdnen slipper vi unna planleggingshysteriet.  Krav drypper inn fra våre brukere, fra våre politikere, fra oss selv. Ledelsen prioriterer oppgavene fortløpende og vi gjør vårt beste for å lage gode løsninger. Vi vet at vi kan få nye krav når som helst, og må dermed organisere oss på en hensiktsmessig måte for å kunne reagere på nye krav.  Med denne virkelighetsoppfatningen er det så uendelig mye lettere å lage gode løsninger.  Vi forholder oss til virkeligheten her og nå. Ikke en plan lagt for mange år siden.  Jeg foreslår at utvikling av ny software utføres av statens egne tilsatte, med hjelp av innleide konsulenter, på samme måte som vanlige linjeoppgaver løses i et forvaltningsteam. 
En av de viktigeste grunnene til at dette ikke kan gjøres idag, er at vi ikke har nok tilsatte programmerere i enhver etat til at de kan ta over seg det ekstra arbeidet som er involvert i å lage et helt nytt system. Dessuten kan man ikke ansette folk når man vet at man ikke har noen jobb til dem 2 år senere. Men dette problemet kan løses ganske enkelt.  Faktisk kan vi slå to fluer i en smekk, 3 fluer, 4 kanskje: Programmerere liker nye utfordringer. En av grunnene til at de store konsulenthusene er så populære arbeidsgivere, er at de tilbyr muligheten til å bytte fra prosjekt til prosjekt.  De ansatte trenger ikke være redde for å bli sittende fast et sted og aldri lære noe nytt.  Hvorfor ikke gi våre tilsatte i staten samme muligheten? Hvorfor ikke tillate våre programmerere å bytte prosjekt/etat? Når Nav blir ferdige med et prosjekt, kan utviklerne overføres til politiet, eller helsedirektoratet, skatt, forsvaret, Statens vegvesen, Statens pensjonskasse, Lånekassa, Husbanken…Staten har til enhver tid så mange forskjellige prosjekter på gang, at det aldri vil være et problem å sysselsette en programmerer.  Dette vil i tillegg føre til at vi lærer av hverandre, blir kjent med hverandre, finner bedre løsninger for samhandling fordi vi kjenner hverandres systemer.  I tillegg vil muligheten til å lage masse ny software, uten slitsom prosjektstyring, tiltrekke seg de aller beste programmererne.  De vi aldri ser i et statlig prosjekt idag.

Jeg ser med glede at den nye regjeringa har fokus på bedre IT-systemer i Norge.  Jeg håper de innser at vi får flere og mye bedre IT-systemer hvis vi utvikler dem på en smart måte. 

Advertisement