Hvorfor offentlige IT-prosjekter feiler

Foto: Lise Åserud / NTB scanpix

Det er beklagelig nok en rekke eksempler på store offentlige IT-prosjekter som feiler, og man kan spørre seg om det er et mønster, og i så fall hvorfor. Det foreligger flere forskjellige typer av offentlige IT-prosjekter, her skal vekten legges på utvikling av IT-systemer, mens drift av IT-systemer belyses i en senere artikkeldetaljeringer

I stikkords form kan de forskjellige fasene IT-systemutvikling, ideèlt sett, beskrives slik:
• Et prosjekt starter med en bestilling, inneholdende en tilsynelatende komplett     kravspesifikasjon.
• Dette resulterer i et IT-system – en applikasjon – som dekker kravspesifikasjonen, enkelt og greit.

Slik er det ikke, så langt der ifra, virkeligheten er tvert imot:
• Kravspesifikasjon, viser seg utilstrekkelig, idet utviklerne raskt kommer tilbake med detaljspørsmål.
• Bestillerens nødvendige detaljeringer og utvidelser øker i rykk og napp slik at prosjektets ramme og overordnede egenskaper øker både i bredden og dybden.
• Stemningen mellom bestiller og utfører blir dårligere og dårligere. Bestilleren opplever utviklerne som til dels nedlatende og svært lite samarbeidsvillige, mens utviklerne opplever at bestillernes ønsker stadig detaljeres, i praksis øker, uten at bestilleren tar dette innover seg.
• Prisen øker – og leveransen forsinkes.

Hvorfor er det slik? Svaret er enkelt; i alt annen enn små applikasjoner er mulighetene for tolkning av spesifikasjonene som oppleves som uklare og ufullstendige, ikke fordi bestilleren er inkompetent, men fordi antall mulige alternativer er uhåndterlig, dvs. at det ikke er mulig å tenke gjennom alle detaljer ved bestillingen. Under prosjektarbeidets gang dukker det også opp ønsker fra bestiller som opplever av utviklerne som utvidelser som har potensiale for å innebære vesentlig økning av systemets størrelse.

Årsaken til dette kan beskrives slik: system-spesifikasjonen (også kalt –definisjonen) er en del av systemutviklingen, og omvendt. Dette har vært kjent lenge, den første som beskrev en empirisk utviklet teori som tar høyde for dette var en glup nederlender ved navn Rittel, allerede på slutten av 60-tallet. En avledet metode er «smidig systemutvikling».

Nå har fornektelse av dette ubehagelige faktum resultert i flere spektakulære, og meget dyre, feilslåtte IT-utviklingsprosjekter med offentlige bestillere. Dette skjer selvfølgelig også i privat virksomhet, men i mindre omfang. Årsaken til de offentlige institusjoners ofte lite heldige rolle som bestillere er selvfølgelig basert på flere forhold. Det viktigste er dog manglende IT-kompetanse, slik at den prosjekt-enheten som skal kontrollere arbeidet gang, styringsgruppen, ikke kan gå inn på ønsket faglig detaljnivå, men overlater dette til utvikleren. En klassisk «bukken og havresekken». Det finnes nødvendig «hard» faglig kompetanse der ute, som effektivt kan bistå en styringsgruppe, men dette oppleves nok som uønsket innblanding og også en fallitterklæring til egen kompetanse. Beklagelig, unødvendig og svært dyrt for samfundet!


Takk for at du leser Resett. For å kunne fortsette å produsere kvalitetsmateriale avhenger vi av din støtte. Klikk her for å finne ut hvordan du kan støtte oss.

The following two tabs change content below.

Bjørn Brevik

En av de første med cand. real. graden, fra Universitetet i Oslo 1973, med hovedfag konsentrert rundt avansert IT, nærmere bestemt basis programvare (system software). Hovedinteresse er å følge med i utvikling av (applikasjoner med funksjonstype) kunstig intelligens, AI, og bidra til øket forståelse av denne utviklingen.

Latest posts by Bjørn Brevik (see all)

  • Terje Skappel

    Som om jeg skulle ha skrevet det selv… (jeg skjønner bare ikke hvorfor andre ikke skjønner det også! lol )

  • Ingvar Nilsen

    Interessant artikkel! Jeg programmerer selv, har eget datafirma. Og jobber både for andre som konsulent, og med mine egne produkter. Det er tragisk å se den enorme, den vanvittige pengesløsingen. Hvordan offentlige midler bare forsvinner ned i det store, sorte hullet.

    Jeg har selv vært utviklingssjef en gang, og sett noe av dette på nært hold. Og jeg er helt overbevist om at enkelte av disse prosjektene til flere hundre millioner kroner, som går overende, de kunne vært løst for et par-tre millioner kroner, med de rette folkene på plass.

    Det som artikkelforfatteren her tar opp, blir verre, desto større prosjektet er. Og hovedgrunnen til alle disse problemene, er manglende forståelse for hva programvare er. Kunsten er å stykke opp prosjekter i handterbare størrelser. Men Slike modeller passer ikke inn i offentlige systemer for bevilgninger og budsjetter!

    Og så får vi disse megaprosjektene, med utallige «stakeholders», blandet med prosjektledere og haugevis med folk ellers. Alle med sine egeninteresser, der mye tid og krefter brukes på å rettferdiggjøre sin egen berettigelse i prosjektet.

    Jeg har kommet opp med et eget navn på dette, jeg kaller det «interne stater i staten». Dette at folk springer rundt på interne møter, kurser hverandre, sender mails, produserer dokumenter, som igjen krever nye interne møter, nye Powerpoint-presentasjoner. Og – den samlede forflytning framover er null.
    Som solo-programmerer er det litt enklere å holde styr på fremdriften 😉

  • Zylark

    Som leverandør og utvikler bør steg en i etthvert oppdrag å opparbeide seg domenekunnskap. Sette seg inn i hvordan eksisterende systemer – manuelle som maskinelle – fungerer hos bestiller, hvordan de benyttes og hvordan brukere og eiere ønsker å se forbedringer. Dette gjøres nær sagt som en selvfølge.

    Samtidig – og i større organisasjoner bør ikke det være noe problem – må bestiller også besitte eller internt tilknytte seg nødvendig IT kompetanse til å kunne kommunisere effektivt med leverandør. Man tar seg gjerne bryet med å sette advokat til å utarbeide kontrakten, men om man ikke også setter en IT kompetent person til å overse spesifikasjoner og fremgang, så prøver man å spare penger i feil ende.

  • Tor Anders Engen

    Ja det er tragisk. Men som artikkel forfatteren skriver er at det er for dårlig forarbeid. Pluss at “ekstra” ønsker blir lagt til under utvikling. Erfaringer her viser at hvis slikt skjer flyr tiden. Eller TTT (ting tar tid).

    Hvis dette skal utvikles i utlandet, blir det enda mer problematisk. Fordi man kolliderer med språk og kultur.

    Hadde dem vært Nazi. Laget moduler og grensesnitt i forkant, krever godt forarbeid. Så sier at dette er standarden, mens tillegg må tilpasse i etterkant. Etter at prosjektet er ferdig.

    Vil da tro at mange “høye herrer” bli “butt-hurt”. Fordi dem ikke får viljen sin.

  • Scott Johansen

    Dette er ikke noe ukjent fenomen i offentlig sektor. Var selv inne i katastrofe prosjektet Oslo Kommune Applikasjonsdrift (OKAD), hvor utvikling og kompetanseetaten i kommunen fakturerte 60 mill som diverse. Da ble denne etaten innkalt til ledelsen på rådhuset med spørsmål om hva inn i f…dette var for noe.
    Så det er ikke tvil om at landets kommuner og offentlige etater har en sterk manglende IT-kompetanse og hvor kammeraderi ser ut til å være det rådende av annsettelser i ledende stillinger…