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:
- 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.
- 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.
- 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.
- 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.
- 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.
Hennings mening 