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.
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.
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å.