Før og etter TRESS

Trygdeetatens TRESS-prosjekt er offisielt erklært som katastrofeområde. Prosjektlederne er fjernet. Sluttdatoen er skjøvet ut med noen år. En ny pengesekk må til. Hva kan vi lære av dette da, dere?

nn TRESS kommer til å bli et vannskille i vår IT-verden. Prosjektet er så synlig at selv folk et stykke unna IT godt vet om det. Heretter vil det bli meget vanskelig å sette i gang prosjekter som ligner TRESS. Risikoen er rett og slett blitt for stor. Det essensielle problemet, som var åpenbart helt fra starten, var at man forsøkte å endre system og infrastruktur i én kjempeoperasjon. Arbeidet skulle utføres på kort tid, av en hel bunt med konsulenter leid inn fra ulike firmaer. Dette skapte en situasjon som Rikstrygdeverket (RTV) ikke mestret. Etaten har aldri hatt ansvaret for et så stort prosjekt. Forrige gang de utviklet store systemer var det leverandørene som styrte det hele - og Norsk Data fikk kjempeproblemer med å komme i mål med sitt Nortrygd.

nn Et annet, like synlig problem lå i teknologivalget. RTV baserte TRESS på moderne, åpne prinsipper: Tusener av PC'er, hundrevis av UNIX-tjenermaskiner, flere standardiserte protokoller, relasjonsdatabaser osv, osv. Konseptet var distribusjon: I hvert trygdekontor ble det installert en god del utstyr og programmer, og maskinene skulle kommunisere med hverandre og med RTV. En kompleks løsning. Å plukke elementer fra "nær og fjern" gir stor fleksibilitet, men har flere ulemper. Dels må elementene sys sammen til et hele, og dette krever spesialkompetanse som ikke mange har og dels vet man ikke på forhånd om løsningen, etterat den er blitt integrert, vil ha den ønskede ytelsen og stabiliteten. Man er rett og slett først i løypa. Ingen kan si på forhånd hvor kraftige datamaskiner det kommer til å bli bruk for. TRESS ble truffet av alle disse problemene i uskjønn forening som bl.a. har resultert i at maskinene på trygdekontorene må utvides kraftig.

TRESS er ikke den første til å bomme på behovet for maskinkapasitet. Ofte ender vi opp med tre ganger så kraftige maskiner som vi trodde i starten. Dette er ille hvis det er snakk om en sentral stormaskin, men den risikoen klarer store virksomheter vanligvis å bære. Tilleggsinvesteringene kan her dreie seg om 5 eller 10 millioner kroner. Det er langt verre hvis man bommer på kapasiteten til de lokale maskinene fordi det finnes så mange av dem. Kreves det tilleggsinvesteringer på en halv million pr kontor, og vi har 500 kontorer, blir summen 250 millioner. Da blir det ramaskrik (eller rammeskrik).

nn Enda et stort problem lå i at terrenget forandret seg mens kartet ble tegnet. Verden sto ikke stille mens TRESS-utviklingen pågikk. Folketrygdens regelverk ble endret mange ganger i løpet av disse årene, og etaten fikk dessuten nye oppgaver. Disse forandringene måtte innarbeides både i TRESS og i de systemene som i dag er i bruk. En ekstra kompleksitet lå i at etaten bruker to ulike systemer, den stormaskinbaserte Infotrygd og den distribuerte Nortrygd. Å holde tre meget komplekse løsninger funksjonelt synkronisert gjennom alle forandringer, i 3-4 år, krever en disiplin og et møysommelig papirarbeid som TRESS ikke maktet.

nn Prosjektet var basert på tidsanslag og kostnadsestimater som ble utarbeidet innen startskuddet gikk. Dette var nødvendig for å få Stortingets velsignelse til å gå i gang. Her lå også et digert problem. Tidlige estimater av tid og kostnader for store prosjekter pleier å være helt på jorde - fordi man vet for lite om hva som egentlig skal leveres. Man står ansikt til ansikt med et langt større prosjekt, men man er ikke klar over det. Amerikanske Spectrum International som er spesialist på prosjektstyring hevder f.eks. at etterat de initielle 2% av innsatsen er lagt ned i et prosjektforslag, pleier estimatene å være opptil 80% unna virkeligheten. Etterat 15% av arbeidet er unnagjort, og man har den detaljerte kravspesifikasjonen og systemarkitekturen på plass, daler usikkerheten til 40%. Først etter 60% av innsatsen og avsluttet programkonstruksjon er usikkerheten nede på 10% og der blir den liggende helt til prosjektet er i havn. 10% av 200 millioner er fortsatt 20 millioner! Her ligger et politisk dilemma: For å få bevilgninger må prosjektledelsen presentere et tiltrekkende forslag der nytten er større enn kostnadene - samtidig som de vet at estimatene kan være 80% høyere enn de som er vist. Nytteberegningene for TRESS var basert på at driften og vedlikeholdet av de nåværende systemene kostet så mye at en ny løsning måtte bli lønnsom. Innebygget i dette resonnementet ligger at det gjaldt å være ferdig så fort som bare det fordi da ble besparelsene enda større. Det hastverk som dette skapte ble en del av prosjektets bane.

Den opprydningen og replanleggingen i TRESS som skjer nå kommer to år for sent. Den burde ha skjedd da RTV sparket ut det firmaet som ledet prosjektet til da, og overtok ansvaret selv. Dette er også et typisk trekk ved prosjekter som løper løpsk: Mye prestisje er investert både fra styrings- og prosjektgruppen, og da er det lettere å kaste mer penger i det dype hullet enn å stanse opp og risikere kritikk.

nn OK, OK, nå har jeg skrevet langt nok om problemer og risikomomenter. Men hvordan skal vi unngå at store prosjekter løper løpsk? TRESS har lært oss noen lekser:

n Vi skal ikke legge planer som innebærer at mange ting må forandres samtidig. Det er bedre å planlegge i faser. Skifte den tekniske infrastrukturen i kontorene og innføre lokale løsninger, men beholde det sentrale systemet kan være første fasen. Tilpasse det sentrale systemet til grafisk brukerdialog, men fortsatt beholde den kompliserte innmaten, kan være fase to. En viss hr. Lenin snakket ofte om salamitaktikken: Du skyver ikke hele salamipølsa inn i munnen og tygger i vei, men skjærer én og én skive.

n Det er livsfarlig å satse på uprøvede tekniske løsninger i store prosjekter. Hvert eneste element, hver eneste kombinasjon må prøves ut innen de blir en del av systemarkitekturen. Dette tar tid og koster penger, men det er ingen vei utenom. Eksperimentering går an når konsekvensene er små, men når de måles i hundre millioners enheter, må vi være konservative.

n Budsjetter og tidsplaner kan ikke fastsettes i begynnelsen av prosjektet. Estimatene på dette tidspunkt bør betraktes som omtrentlige, og bør presiseres og reforhandles med oppdragsgiveren etterhvert, på planlagte tidspunkter.

nn Jeg hører innvendingene! Dette er lett å si, men det går da ikke an å stille opp i Stortinget og be om tillatelse til å gå i gang med et prosjekt som vi anslår vil koste 200 millioner og ta to år, men at vi må få lov å komme tilbake om ett år når vi vet mer for å be om mer tid og penger. Men det er nettopp dette som er poenget! Vi er nødt til å håndtere store prosjekter på en annen måte enn TRESS - og jeg håper og tror at i en post-TRESS tid vil det bli lettere å få aksept for at store IT-prosjekter inneholder mye usikkerhet. Vi sammenligner ofte IT-prosjekter med å bygge en bro eller en tunnel, men det er feil. En bro blir først konstruert ut fra gitte krav og deretter blir den bygget ut fra konstruksjonen. Kravene står fast. Hovedproblemet med systemutvikling er at kravene kan endres radikalt mens prosjektet pågår. Veien blir til mens vi går, den ligger ikke der den lå. Den beste analogien til IT-prosjekter er ikke brobygging, men menneskelivet selv. Prosjektet starter med unnfangelsen, deretter kommer graviditeten og fødselen - og da begynner det virkelige arbeidet gjennom barndommen, ungdommen og voksenlivet. Og som med livet: Vi vet ikke hvordan prosjektet kommer til å gå fordi alt ikke lar seg planlegge i forveien.

Artikkel automatisk generert, 11/11-94, kl. 16.47 cw@oslonett.no