Martin Koksrud Bekkelund

Virkeligheten er kompleks. Er det derfor omfattende IT-prosjekter så ofte feiler? Eller er det fordi vi ikke evner å modellere virkeligheten på en enklere måte?

Vi bruker IT til å beskrive virkeligheten digitalt. Et pasientjournalsystem beskriver pasienter og deres helsetilstand. Et CRM-system beskriver dine kunder og ditt forhold til de. En nettbutikk selger varer eller tjenester. Eksemplene er mange og varierte.

Hvis IT skal beskrive virkeligheten, hvorfor feiler allikevel mange IT-prosjekter?

Det finnes ikke et enkelt, uttømmende svar på spørsmålet. Hadde det vært det, ville ikke prosjektene feilet, naturlig nok. Problemet er sammensatt og årsakene kan oppstå forskjellige steder i et prosjekt. Allikevel er jeg overbevist om at overadministrasjon og byråkrati er overordnede årsaker til at IT-prosjekter feiler, trekker ut i tid, sprenger budsjetter, eller gjerne en kombinasjon av disse.

Tradisjonell tankegang

Tradisjonelle prosjekter består av prosjektledere, arkitekter, utviklere og teknikere, i tillegg til representanter fra prosjekteieren, det vil si kunden. Utfordringen består i å formidle kundens virkelighet til prosjektorganisasjonen som i sin tur skal implementere kundens virkelighet i en IT-løsning. Kunden har kompetanse på egen virksomhet og virkelighet, utvikleren kompetanse om IT og programvareutvikling. Men de færreste har kompetanse om begge deler.

Tradisjonelt sett har derfor kunden beskrevet sin virkelighet overfor en arkitekt, som i sin tur lager en teknisk beskrivelse som utvikleren skal lage løsningen etter. Langt på vei gjør man en viss faglig kvalitetssikring, men ofte opplever man også at kundens virkelighet blir lost in translation. Problemet oppstår fordi prosjektprosessene er for omfattende.

En enklere tilnærming

Jeg har selv arbeidet som arkitekt i slike prosjekter i mange år, og er det en suksessfaktor som skiller seg fra alle andre, så er det verdien av å sette en dyktig utvikler sammen med en kompetent kunde. Ofte insisterte jeg på å ta med meg utvikleren ut til kunden, og la dem programmere løsningen sammen. Løsningen blir til på stedet, slik kunden vil ha den, ferdig testet.

En slik tilnærming krever høykvalifiserte mennesker. Utvikleren må forstå hva kunden vil ha (for det er ikke alltid like klart), og kunden må ha god innsikt i egen organisasjon og egne prosesser. Det er også en god del andre faglige hensyn som må tas, som for eksempel brukervennlighet og faglig kvalitetssikring av arkitekten. Men dette er bagatellmessige utfordringer som enkelt lar seg løse.

Papirpesten

Poenget er å unngå for mange ledd hvor feil kan oppstå. Virkeligheten beskrevet i prosjektdokumenter og papirer gir ingen garanti for at løsningen blir slik kunden vil ha. Noen mennesker blir skremt av å ikke ha dokumentert hele virkeligheten før den implementeres i en IT-løsning.

Men virkeligheten lar seg ikke beskrive før den implementeres, fordi virkeligheten først og fremst endrer seg kontinuerlig, men også fordi virkeligheten vanskelig lar seg beskrive slik vi tradisjonelt sett har gjort i IT-prosjekter. Da er det langt enklere å beskrive virkeligheten direkte gjennom løsningen. Det er raskere, billigere og reduserer risikoen for både programmeringsfeil og ikke minst logiske feil.

Tvangstanker om kontroll

Mennesker er av natur opptatt av å dokumentere virkeligheten, spesifisere fremtiden og kontrollere og regulere. Problemet er at virkeligheten er så kompleks at det vi ønsker å oppnå som regel løses bedre når man ikke kontrollerer og regulerer og spesifiserer ned til minste detalj.

Uttrykket «det enkle er ofte det beste» har blitt en klisjé. Men det er riktig som uttrykket sier — det enkle er som regel det beste, og det enkle er også langt enklere og raskere å endre. Og ikke minst kontrollere.

Generelt