Hva kan gå galt i IT-prosjekter? Svaret er mye. Svært mye. Og mye går galt. Undersøkelser viser at 40 til 50 prosent av prosjektene feiler.

Slik lød den lokkende invitasjonen til et kaffeseminar hos Senter for rettsinformatikk ved Universitetet i Oslo forrige uke.

– Hvis det er én ting dere skal huske er det dette: Den aller største feilen står i prosjektets
mandat. Feilen er beskrevet som oppgaven du skal løse, sa Harald Os.

Foredragsholderen delte erfaringer han har opparbeidet seg etter over tyve år som konsulent, de siste fem som seniorrådgiver i Skatteetaten.

Opplevd behov
Ikke bare hvor det ofte svikter, man hva som kan gjøres for å unngå havariet. – Alle prosjekter starter ut fra et opplevd behov, så er det ikke sikkert beskrivelsen av behovet eller opplevelsen av det stemmer med virkeligheten.

– Vi bruker IT-prosjekter for å løse organisasjonsutfordringer. Tror vi. Der kunne jeg egentlig stoppet, for det er dette det handler om, sier Os, før han spør retorisk. Hva skal prosjektet levere? Er det behovsstyrt eller er det et IT-prosjekt?

Uklare mål
Rådgiveren hevdet han har til gode å se et prosjekt hvor det bærende elementet er hva som skal komme ut i andre enden, hvilke behov det skal dekke og hva som faktisk skal oppnås.

De rundt 20 som hadde møtt opp til foredraget, fikk høre at testing nødvendigvis er en viktig del av IT-prosjekter. Det er kjent at all programvare inneholder feil. Os la til at alt som ikke testes er feil. Men hva er det som ikke testes?

– Mandatet og gevinsten testes ikke. Det gjør heller ikke kravene som vi stiller opp. De kan være langt unna det vi tror de er. Kravspesifikasjonen beskriver vel behovet? Nei, som regel beskriver den noe helt annet. Feilaktig beskrevne krav er samvittighetsfullt implementert, det kan vi dokumentere med tester.

Skrell vekk
Det finnes ifølge foredragsholderen bare én ting som er verre enn et prosjekt som endrer på kravspesifikasjonen, og det er de som ikke gjør det. Så lett og så vanskelig. – Vi må endre underveis.

Erfaringen hans er at de som skriver kravspesifikasjonen skriver alt for mye. Kort ned på beskrivelsen, skrell vekk alt som er unødvendig.

Det var også tid til å komme innom kjente prinsipper som KISS (keep it simple, stupid!) og 80/20-regelen. Sistnevnte postulerer at 80 prosent av funksjonaliteten kan leveres på 20 prosent av tiden.

– Anvender vi det to ganger, så kan vi med 40 prosent av innsatsen dekke 96 prosent av behovet. Er det da verdt å bruke resten av tiden for å dekke 100 prosent? Ja, noen ganger er det det, men det er verdt å tenke over.

Mentalt krevende å forenkle
Skatteetatens IT-mann lanserte en påstand om at kompleksiteten i et prosjekt dobles for hver fase man går gjennom (fra konsept til analyse, til design, implementering og så videre). Dermed er man raskt oppe i en økning i kompleksitet på 10-gangen.

For å unngå dette må man forenkle. Man gjør det som er nødvendig, men heller ikke mer. Så var budskapet også at noen ganger er kompleksitet helt nødvendig, du må bare vite når du kan unngå unødig kompleksitet.

Dette er vanskelig, vedgår Harald Os. – Vi tar oss ikke den mentalt krevende jobben det er å gjøre noe enkelt. Dessuten, hva er det som gir status i en organisasjon. Er det å mestre det enkle eller å mestre noe som er komplisert, spurte han retorisk.

Seniorrådgiveren avsluttet med råd om hvordan man kommer seg ut av uføret. Han presenterte en enkel matrise baserte på «triste og gode erfaringer fra en del prosjekter».

Løsningsfella er typisk noe du bør unngå. «Når konsulentene ikke har forstått et problem, så drar de fram en løsning for å slippe å vise at de ikke forstår. Det lærer man på konsulentskolen».

– Beskrivelser er mye viktigere. Når vi atpåtil skal lage noe så abstrakt som programmer, tror jeg det er ekstra viktig.

Still heller ikke hvorfor-spørsmål, da slike kan bli for offensivt oppfattet. Os foreslår i stedet at man spør «hva skal vi oppnå med det?». Hva er hensikten med det vi skal lage?

– Det har jeg terpet på hos oss (Skattedirektoratet) mange ganger. Men det å beskrive hensikten med få ord – og få fram hva poenget egentlig er – det krever innsats, sier Os.