Det er ofte kravene som er feil, ikke løsningen

To av mine gode kolleger i A-2 Norge har skrevet en artikkel i Ukeavisen ledelse om tre grep for å få mer vellykkede IT-prosjekter i offentlig sektor. Dette gjenspeiler dyp erfaring fra en rekke IT-prosjekter vi har fulgt over mange år. Jeg vil her ta tak i ett av momentene de tar opp og spinne videre på det, nemlig selve utgangspunktet:

• Hvilke behov det er som skal dekkes?
• Hvilke krav er beskrevet?
• Er det en fare for at en ny løsning bygges ut i fra noe som er svakt fundert?

Som kvalitetsikrer av store IT-prosjekter undersøker vi alltid selve fundamentet for prosjektet. Det har å gjøre med behovsanalyse, kravformulering, organisatorisk forankring, ledelsens engasjement, teknologivalg, samt ikke minst om det er utarbeidet en dekkende business case. Gjentatte ganger har vi sett at dette fundamentet er ustabilt. Behov og krav kan være beskrevet med varierende presisjon og ikke minst på veldig ulikt detaljeringsnivå. Jeg opplever ikke at det er teorien det er noe galt med. Å utarbeide en behovsanalyse eller beskrive overordnede behov før kravene blir detaljert ut er fornuftig. Men praksisen derimot, den kan man innvende mye mot.

Jeg har konkludert med at fem sentrale forhold må være på plass for å gi IT-prosjektet et solid fundament når det gjelder behov og krav, både før prosjektet starter og underveis i gjennomføringen. Det er lett å nikke til disse punktene, men det er ikke dermed sagt at de er enkle å realisere. Og overraskende mange kunder og ikke minst leverandører med mye erfaring viser manglende forståelse for hva som må til for å gjennomføre dette i praksis. De fem punktene er:

1. Riktig kompetanse. De som beskriver behov og krav må kjenne virksomheten, primært arbeidsprosesser og regelverk, meget godt. Jeg har ofte sett at kompetente folk bare har vært med sporadisk og i en tidlig fase av arbeidet. Det holder ikke.
2. Solid forankring gjennom både arbeidet med å lage en kravspesifikasjon og ikke minst under gjennomføringen av prosjektet. Dette er ikke et «one man show». Som er krevende når store løsninger med hundrevis av krav skal innføres. Det tar tid å forankre, ikke minst for de det skal forankres hos. Når disse ikke har den tiden, bytter jobb internt eller slutter kan man lett få et vakuum – som lett kan føre til at man skyver på vanskelige avklaringer til senere i prosjektet.
3. Tenk nytt, ikke bare kopier funksjonaliteten i en gammel løsning. Overraskende mange går i denne fella. Man snakker om å optimalisere arbeidsprosesser og tenke smart i en ny løsning, men når alt kommer til alt ender man opp med at den nye løsningen blir for mye av det gamle, laget på en ny teknisk plattform. Og gjerne unødvendig komplisert.
4. Visualiser løsningen så tidlig som mulig. Det er mye mer effektivt å kommunisere ved bruk av skjermbilder kontra beskrivelser. Når et krav er at løsningen skal ha «et moderne og effektivt brukergrensesnitt», må man så tidlig som mulig konkretisere hva det i praksis betyr. Da blir visualisering helt avgjørende. Både for at kunde og leverandør skal bli enige om en felles forståelse, men også fordi tidlige designvalg kan bli veldig arbeidskrevende å endre senere i prosjektet. Går det helt til akseptansetesten kan man også risikere store økonomiske krav i form av endringsordre.
5. Dynamisk samarbeid i et konstruktivt klima. Begge parter bør være innstilt på at endringer i krav vil komme. Ingen kunde klarer å definere krav så presist at man bare kan designe og bygge uten videre. I tillegg kan (og bør) standard funksjonalitet i mange applikasjoner også påvirker realiseringen av krav. Dette skal normalt dekkes i kontrakten, men ofte ser man det ikke godt nok før prosjektet er i gang. Da blir det viktig med en åpen og fleksibel samarbeidsform. Dessverre ser jeg for ofte at kunden «står på krava», både fordi man er er usikre (kompetanse) og forankringen er vanskelig å få til, samt at viljen til å tenke nytt ikke er nok til stede (her kan man også være bundet av det offentlige reglementet for anskaffelser, men det gjelder jo ikke i privat sektor).

La meg snu på det: Hvis man bygger et IT-system hvor kravene er laget av noen som ikke kjenner virksomheten inngående, det har vært dårlig forankring i linjen eller forretningen underveis i prosjektet, man er mest opptatt av å kopiere det bestående (hvis det finnes), ingen ser demo av løsningen før langt ute i prosjektet, og det er rigide fronter mellom partene – da er det en sikker oppskrift for at det blir nok et mislykket prosjekt.

Reklame

To prosjekter: Så like, men likevel tar det ene tre ganger mer tid …

Noen ganger kan prosjekter tilsynelatende se ganske like ut, men vise seg å bli veldig forskjellig å gjennomføre. Eksempelet jeg skriver om her handler om to virksomheter som begge skulle skifte ut sine økonomisystemer. Den ene er en dynamisk, mellomstor privat bedrift («BEDRIFTEN») og den andre en litt større statlig etat («ETATEN»). Begge hadde et ganske likt utgangspunkt med en eksisterende ERP-løsning som måtte skiftes ut.

BEDRIFTEN brukte under ett år på et forprosjekt, utarbeide en kravspesifikasjon, gjennomføre en tilbudskonkurranse og et prosjekt og ta i bruk løsningen. ETATEN er fortsatt ikke i mål etter tre år. Hvorfor blir det slik? Er det noen tydelige indikatorer som kan fortelle hvorfor noe som er ganske likt tar så mye lenger tid i ETATEN enn hos BEDRIFTEN? Ja, jeg tror det.

Jeg har satt opp noen viktige parametere og gjort en liten vurdering av de to prosjektene opp imot disse:

• Kontrakttype: Statens standard for begge.
• Ledelsen engasjement: Høy for begge.
• Løsningens kompleksitet: Høyere for ETATEN.
• Grad av tilpasning: Mye høyere for ETATEN.
• Rammebetingelser: Mer krevende for ETATEN.
• Tidspress: Mye høyere for BEDRIFTEN.

ETATEN er pålagt å følge og benytte statens regelverk for IT-anskaffelser, men også BEDRIFTEN valgte å benytte denne prosessen og kontrakt – riktignok med mulighet for en helt annen fleksibilitet enn ETATEN kan gjøre. Og uten den gjennomsyrende frykt i det offentlige for å gjøre noe feil i prosessen. Etter mitt syn viser det at både prosessen og kontrakten er god, men regelverket som staten må følge er meget rigid. Gjør man en liten feil kan hele prosessen bli underkjent. Rykk tilbake til start! Det risikerte man ikke i BEDRIFTEN og kunne derfor kjøre en rask og smidig prosess, men uten å gå på kompromiss med etiske normer. Flere av tilbyderne sa i ettertid at de hadde satt pris på den ryddige og profesjonelle prosessen som var gjennomført. ETATEN derimot, brukte mye tid på å sikre seg at alt gikk riktig for seg, og hadde gjennomgående mye lengre frister på alt enn BEDRIFTEN. Så der BEDRIFTEN brukte 6 måneder på å få en avtale på plass, brukte ETATEN halvannet år. Det samme gjaldt gjennomføringen.

Ser man på ETATEN er det tilsynelatende ikke noen spesielt skremmende faktorer som spiller inn. Likevel tar det altså så mye lenger tid. Jeg tror BEDRIFTEN kom bedre ut primært av tre grunner:

1. Valg av standard løsning fremfor skreddersøm
2. Større grad av fleksibilitet i gjennomføringen
3. Stort tidspress

BEDRIFTEN bestemte seg tidlig for å velge en standard løsning og gjøre så få tilpasninger som mulig på denne. De var villige til å endre sin måte å jobbe på i tråd med systemets standard prosesser hvis det var nødvendig. De tok utgangspunkt i en løsning hvor man kunne jobbe interaktivt hele tiden og se systemet live og legge inn sine regler fortløpende, uke for uke. Prosjektteamet jobbet kontinuerlig med detaljdesign, dialog med utviklerne, testing og evaluering. ETATEN, derimot, jobbet på en tradisjonell måte med mye lenger avstand mellom sine prosjektdeltakere, utviklerne hos leverandøren og selve løsningen. De var veldig opptatt av å få ting på sin måte, og hadde enkelte krav som var meget kompliserte å realisere.

Dette, sammen med en dynamisk holdning til de kravene som var utarbeidet, gjorde at BEDRIFTEN gjennom prosjektgjennomføringen hele tiden tilpasset seg og tok mange små beslutninger som ga trygghet på at de var på riktig vei. Dette kunne ikke ETATEN gjøre, deres krav var «hellige», enten de var fornuftige eller ikke. Det sto jo i kontrakten og var en del av evalueringsgrunnlaget.

Og så kan man ikke komme unna tidspresset. Av forskjellige grunner måtte BEDRIFTEN bli ferdig på ett år, mens ETATEN ikke på langt nær hadde det samme presset fra ledelsen. Når presset reduseres akseptere man mye lettere at «ting tar tid». For BEDRIFTEN var det ingen nåde: Eierne var veldig tett på ballen, og alle visste akkurat hva som var forventet av dem.

Begge løsningene kommer sikkert til å bli bra for virksomhetene. Men det er skremmende at et prosjekt i det offentlige skal tvinges gjennom rammebetingelser og forutsetninger som gjør at det tar så mye lenger tid og dermed også blir betydelig dyrere (for oss skattebetalere). Hvor mye dyrere? Vet ikke sikkert, men tipper at vi snakker om en faktor på 10 til slutt. Da begynner vi å snakke om mye penger.