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!