Slaktet Tress-90

---

SINTEF DELAB gjorde jobben. Rapporten Ekstern prosjektrevisjon burde i januar 1993 laget den høringen som ble avholdt tre år senere.

---

Tress-90 har vært et mareritt. Sintef Delabs rapport Ekstern prosjektrevisjon kunne spart norske skattebetalere for tre års eksperimentering. Men sannsynligvis var det ingen som forklarte trygdeledelsen hva rapporten egentlig avdekket.

Sintef-rapporten ble gradert fortrolig. Den som gjorde det, må ha følt at rapporten inneholdt sprengstoff som utenforstående ikke burde få kjennskap til, før det ble ryddet opp på kammerset. Ulempen er at det ikke ble ryddet opp.

Hadde rapporten vært tilgjengelig, ville media satt store spørsmålstegn ved Tress-90. Kritisk omtale av offentlige prosjekter er noe politikere ikke kan unngå å ta stilling til, enten ved å gjøre noe med det, eller ved å klargjøre forutsetningene.

Spørsmålet er hvorfor det ikke ble ryddet opp? En av grunnene kan være at Sintef-rapporten har en vesentlig svakhet, den preges av snillisme. Deler av konklusjonene er klare, men Sintef forsøker å se det positive i bildet, at det blant deltakerne i prosjektgruppen fantes detaljkompetanse på de fleste problemstillingene.

Sintefs håp var at det ble foretatt en grundig revisjon med nok synergieffekt til at tekniske og trygdefaglige problemer ble løst. I desember 1992 uttalte samtlige prosjektdeltagere Sintef intervjuet, at designdokumentasjonen ikke hadde tilstrekkelig kvalitet til tross for at begge delsystemene Analyse og Design måtte ha blitt godkjent på det tidspunktet.

Oracles verktøy var ikke gode nok på revisjonstidspunktet. Ambisjonene for bruken oversteg funksjonaliteten. For eksempel kunne ikke Oracles Case tegne diagrammer av databasemodellen hvilket medførte uoverenstemmelser som forvirret systemutviklerne.

At forståelse for databasemodellene og grunnleggende objekter som sak og juridisk enhet, var mangelfull hos systemutviklerne, burde ha vært et så kraftig rødt flagg at det ble ropt høye varsko.

Med manglende trygdeforståelse med unntak av enkeltpersoner hos NIT og i fagmiljøet på Bø, er det ikke rart at modulspesifikasjonen, dvs. den logiske oppsplittingen av systemet ble elendig. Den var i tillegg utarbeidet under altfor knappe tidsfrister.

Trygdedatas største synd er egentlig ikke at de lagde en design som beskrives som tynn, mangelfull og delvis ubrukelig, men at de ikke sa fra på en slik måte at ledelsen av Tress 90 forsto at grunnarbeidet led under manglende forutsetninger.

Det virker som store deler av de mange involverte var for feige til å si fra. Prøv å gjøre jobben og bry deg ikke med andres problemer, kan synes å være en gjennomgangsmelodi. Typisk er det at konkurrerende IT-konsulenter aldri klarte å danne et homogent team hvor synergi kunne fremdyrkes.

For brukerne må konsulentene ha fremstått som tvilsomme fagpersoner. Abstrakte spesifikasjoner fra analyse- og designfasen ble først forståelige i realiseringsfasen Build. Dermed oppsto det et behov for å gjøre grunnleggende endringer i de tidligere fasene av systemet.

Brukermiljøet, dvs. skjermbildene, har brukt opptil tre ganger mer ressurser enn planlagt. Med de kravene brukerne kom med, brøt programgeneratoren delvis sammen, hvilket medførte behov for manuell programmering. Bare dette ene momentet tilsier at prosjektledelsen burde ha forstått at veien ikke var konstruert på forhånd, men ble til mens man gikk på den. Tidsfrister i slike tilfeller mister betydning.

At Norges største IT-prosjekt hadde så stor kompetansebrist på det faglige feltet er skremmende. Sintef-rapporten påviser at prosjektet kjennetegnes ved at de fleste systemutviklere og prosjektledere inklusive ansvarlig prosjektleder i desember 1992 ikke hadde trygdefaglig kompetanse.

At prosjektet heller ikke hadde en teknisk prosjektleder er utrolig. Uten en person med teknisk totalforståelse blir det ofte en alvorlig brist i samspillet mellom moduler og delsystemer. Sintef påpeker at grensesnittene mellom de enkelte modulene er for dårlig spesifiserte. Klarer man ikke å koble motoren til bilen, spiller det liten rolle at motoren og karosseriet hver for seg har høy kvalitet.

Viktige trygdefaglige avgjørelser ble dermed et stort problem. De ble tatt delvis på lavere nivå, men ofte ble avgjørelsene skjøvet oppover i hierarkiet med lang ventetid, beslutningsudyktighet og delvis motstridende beslutninger som resultat. At samarbeidet mellom brukere og utviklere dermed bare var delvis bra, er sannsynligvis en snill beskrivelse av problemstillingen.

Artikkel automatisk generert, 08/02-96, kl. 22.24 cw@oslonett.no