Efter EFI-skandalen: Her er fem krav til din it-leverandør

Klumme: Polsag, EFI ... you name it. Forklaringerne på, hvorfor offentlige it-projekter fejler, er der nok af, men hvor skal vi starte med at tage fat? Løbende kvalitetssikring hos leverandøren og at lade brugernes reelle værdi af løsningen styre processen, er det rigtige sted at starte.

Så fik vi endnu en offentlig it-skandale. EFI er lukket ned, og nu har vi været gennem runden med at pege fingre og forklare årsagerne.

Blandt forklaringerne på, at større it-projekter fejler, er klassikere som:
  • Kravspecifikationer på flere tusinde sider uden iterationer og delmål.
  • Alt for komplekse systemer, der skal tage højde for ethvert brugsscenarie.
  • Leverandører, der overkomplicerer projektet for at kunne fakturere flere timer.
Men hvis det er årsagerne, hvor starter vi så med at forbedre løsningerne?

En effektiv måde at dæmme op for fejlene er ved at stille klare krav til leverandøren. Ikke ved at gøre kravspecifikationerne endnu mere detaljerede - tværtimod - delmål, brugerinddragelse og kvalitet bør styre udviklingsprocessen.

1. Opsæt KPI'er til at sikre kvaliteten
Krav til kvaliteten bør gå forud for krav til funktionaliteten.

I stedet for at udtænke smarte features i analysefasen, bør du tænke i konkrete mål. Hvordan kan du ellers vide, om systemet fungerer godt nok?

Et simpelt eksempel kan være en kommunes website.

Kommunen har lagt informationerne ud, men brugerne kan have svært at finde specifik information - spildtid og misinformation giver ikke nogen form for værdi.

Et konkret mål for, om kommunens website er brugbart, vil være at opstille KPI for, hvor mange brugere, der gennemfører et bestemt flow - det kan være at finde prisen på en daginstitutionsplads i kommunen.

KPI'et er her, hvor stor en andel af brugerne, der kan løse opgaven.

Hvis to ud af fem kan finde prisen i dag, bør flowet så ikke logisk forbedres, så mindst tre ud af fem kan løse opgaven?

2. Skriv djævelens advokat ind i udbudsmaterialet
En ulempe ved detaljeret funktionsbeskrivelse, som især offentlige it-projekter bliver ramt af, er, at der ikke stilles krav til, om funktionen fungerer i praksis.

Knappen kan være placeret helt som beskrevet i specifikationerne, men hvis brugerne misforstår betydningen, ikke kan finde knappen eller bliver ledt på afveje, er arbejdet spildt.

De bedste til at vise, om funktionen virker, er brugerne selv. Så sørg for, at udbudsmaterialet indeholder krav om, at leverandøren (eller din egen organisation) bruger en uvildig leverandør til test af løsningen på netop jeres brugere.

Jeg har set eksempler på større website-projekter, hvor udviklingshuset selv testede sit eget arbejde. Da det gik live, var konverteringen 25 procent lavere, end det gamle site, fordi websitet ikke fungerede i praksis hos kunderne. I grunden en skam, når der er blevet investeret et tocifret millionbeløb.

3. Mindre holdning og mere indsigt i brugernes adfærd
Det er ikke ønskerne fra brugerne, der er begrænsningerne. Men de indsamlede ønsker er ofte med til at overkomplicere uden at afspejle det reelle behov.

Derfor er det vigtigt at lade brugerne selv være djævelens advokat undervejs.

Så brug mindre tid på at spørge, hvad brugerne vil have. Brug i stedet mere tid på at undersøge, hvordan de løser opgaverne nu, og om det, der bliver leveret, fungerer i praksis.

Studier viser, at 40-50 procent af udviklingstiden går med at rette fejl eller forbedre funktioner, som ikke fungerer hensigtsmæssigt. Meget af den tid kan spares ved at skaffe indsigt i brugernes adfærd.

Et eksempel: Jeg talte med en virksomhed, der havde lavet et flot digitalt magasin: Det scorede topkarakter i brugernes holdning til det, designet var i skabet, og medarbejderne var begejstrede.

Men det bidrog ikke til forretningen, fordi kunderne ikke kunne finde ud af at købe produkterne i magasinet, som ellers var hele fidusen med det. Det blev opdaget alt for sent.

4. Stil krav til omfang og undgå at starte fra scratch
Alt for ofte ender brugerinddragelse som punkt 387 i kravspecifikationen. Udviklingsprocessen bliver langt mere smidig - og oftest også hurtigere - ved at lade brugerne teste i flere faser og på flere platforme i udviklingsprocessen.

Brugerinddragelsen sker også tit for sent. Inddrager du brugerne midt i udviklingen, er der sandsynligvis allerede begået flere fejl. Fordi:
  • Du har ikke defineret projektet korrekt. 
  • Du ved reelt ikke, hvad brugeren kan finde ud af.
Ideelt set starter brugerinddragelsen i det øjeblik, ledelsen proklamerer, at I skal have en ny digital løsning.

Syv ud af ti projekter fejler, når brugerne ikke bliver inddraget som fundament for udviklingen. Jo flere beslutninger, der bliver truffet på mavefornemmelser, desto større er risikoen.

Så start med at få brugerne til at løse konkrete opgaver med jeres nuværende løsning - eller på tilsvarende løsninger i udlandet eller andre brancher - for at indsamle værdifuld viden om, hvad der fungerer godt og mindre godt i dag. Og test så undervejs, om det virker efter hensigten.

5. Business-cases er altid en vinder
Med disse ovenstående krav til leverandørerne, har du også opstillet et benchmark på, hvor du kan monitorere arbejdet med at gå fra nulpunkt til noget bedre.

Meningen med at investere i digitale løsninger vil altid være at skabe mere effektive processer. Det omfatter også at forbedre brugervenligheden og den oplevede værdi. Så definér, hvilke processer du vil forbedre og opsæt KPI'er for det.

Med afsæt i disse KPI'er kan du beregne, hvad en stigning på for eksempel 20 procent af brugere, der gennemfører et bestemt flow, betyder for besparelser på den manuelle administration.

På den måde kan du udforme en business-case og måle effekten, når løsningen bliver rullet ud.

Kan fremtiden give færre fejlslagne it-projekter ved stille krav til leverandørerne om kvalitet og brugerinddragelse? Jeg er overbevist om, at det er det bedste sted at starte, men vil meget gerne høre din mening også.



Premium
Test: Dette smartwatch er som skabt til at krydse Gobi-ørkenen – men det fungerer også fint herhjemme
Garmin Instinct Solar er et af de første smart-ure, som slet ikke behøver at blive opladet – det har sin fordele og naturligvis også sine begrænsinger.
Computerworld
Biden sender skjult besked til kode-folket: "Hvis du læser dette, har vi brug for din hjælp”
En stående invitation er blevet opdaget i kildekoden på Det Hvide Hus' hjemmeside. Men den er kun til de eksperter, der selv kan finde den.
CIO
Podcast: Her er seks gode råd om ledelse og digitalisering fra danske top-CIO'er
The Digital Edge: Vi har talt med 17 af Danmarks dygtigste digitale ledere - og samlet deres seks bedste råd om digitalisering og ledelse. Få alle rådene på 26 minutter i denne episode af podcasten The Digital Edge.
White paper
Gratis whitepaper: Hvad er EDI, og hvordan kan det styrke min forretning?
Overvejer du EDI, og ønsker du at undersøge, om EDI er den rette investering for din virksomhed? Har en af dine kunder eller leverandører for nyligt bedt dig om at udveksle elektroniske dokumenter (EDI)? Så hent dette whitepaper og få et overblik over, hvad EDI er, og hvilke fordele producenter og grossister som dig kan se frem til, når du investerer i EDI til din forretning.