Om Martin
Martin liker
En kompleks virkelighet
27.06.11 • 1 kommentar
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.
Én kommentar
Har du synspunkter? Legg igjen en kommentar!
RSS og trackback
Med RSS kan du abonnere på nye kommentarer som postes til denne artikkelen.
Du kan legge igjen et trackback fra ditt eget nettsted ved å benytte trackback-adressen til denne artikkelen. Eventuelle tracback ser du under.
Flere artikler
- Facebook på børs
- Lightroom og metadata
- Holder de ord
- The Greatest Bits 3
- Røde kjemper
- Fremdrift
- Skydebatten
- Supertankere og robåter
- IT-realitetsorientering
- Altinn-skandalen
Enda flere artikler? Besøk arkivet.
Bekkelund.net er en blogg av Martin Bekkelund, hvor han lufter sine tanker om IT og IT-politikk. Martin arbeider til daglig som seniorrådgiver, foredragsholder og skribent i IT-bransjen, hvor han veileder bedrifter og organisasjoner i strategisk bruk av IT. Les mer...
© 1995-2012 Martin Bekkelund
Opphavsrett • RSS • Kontakt
Ola Thoresen
27. juni 2011 13.54
Etter å ha jobbet med sånne prosjekter i en del år selv har jeg tenkt på en del av det samme, men kommet til en litt annen konklusjon (men som vel tross alt henger delvis sammen med det du beskriver).
Hovedproblemet er unntakene. IT-systemer er helt geniale på å løse rutineoppgaver, presentere data i strukturerte, godt definerte formater osv. Og det er det “vi utviklere” liker å forholde oss til.
Problemet er at den informasjonen du skal forholde deg til i et større system er full av unntak – og jo større systemet blir, jo flere unntak får man, og jo flere regler og algoritmer må man lage for å ta høyde for dem.
Bare for å ta et lite eksempel:
Jeg kikka litt på et system for meldingsutveksling mellom skole og hjem. Det var ikke tenkt som noen svære saker, men ment å sikre at meldinger hjemmefra kom fram til lærerne, og at meldinger fra skolen ble lest (og bekreftet) av foreldrene. En slags digital meldingsbok, rett og slett.
Burde være enkelt, hver elev har en side, der lærere og foreldre kan legge igjen meldinger og bekrefte at de er lest.
Men så var det jo viktig at ikke elevene selv kunne bekrefte på foreldrenes vegne, så man måtte ha ganske strenge passord-rutiner som måtte implementeres, samtidig som de ikke måtte være så kompliserte at foreldrene og lærerne ikke klarte å bruke dem.
Og så var det noen elever som hadde flere foreldre – gjennom diverse skilsmisser og nye giftemål, og der man ønsket at _alle_ foreldrene – eller i alle fall både en fra mors-siden og en fra fars-siden fikk lest beskjedene. Dermed måtte man lage regler for i hvilke tilfeller en melding skulle markeres som lest – hvem og hvor mange som måtte ha “klikket på den”.
Så var det foreldre som hadde flere unger – og som ikke ville ha en innlogging per barn, eller en melding per barn dersom det var en fellesmelding som gjalt alle, og som kunne få opp en samleside med alle barna på ett sted, så da måtte man implementere noe søsken-opplegg.
Så var det jo også sånn at selv om noen elever hadde samme mor, som bare ville ha én innlogging – så hadde de kanskje hver sin far – og far til A skulle selvsagt ikke ha meldingene som angikk barn B – med mindre barn B til daglig bodde hos familie A…
Plutselig ble det som på papiret, og i utgangspunktet, hadde sett ut som et veldig enkelt og lite prosjekt en hel kaskade av forskjellige rettigheter og tillegg og innstillinger for å koble sammen barn og foreldre og hvilke lærere de hadde og hvilke vikarer som hadde hatt hvilke timer osv osv…
Jeg tror det er her mange sånne prosjekter feiler – i alle fall i forhold til tidsbruk og økonomi. Man blir 90% ferdig med den første, enkle løsningen, når noen kommer på at man har glemt noe, og så må fryktelig mye både tenkes ut og skrives på nytt.