Hvorfor IT-projekter fejler: 12 årsager, og hvordan du undgår dem

IT-projekter fejler sjældent fordi udvikleren ikke kan kode. Når jeg ser på hvorfor IT-projekter fejler, er årsagen oftest noget der blev besluttet, eller ikke besluttet, før den første linje kode: et uklart mål, et omfang der vokser, ingen der har det sidste ord, og en pris der blev sat før nogen forstod opgaven. Herunder får du 12 årsager set fra udviklerens stol og en konkret forebyggelse til hver.

Jeg er selv freelanceudvikler, og nogle af årsagerne ligger hos folk som mig. De er med på listen.

Den korte version: 12 årsager og det der forebygger dem

Et projekt kan fejle på tre måder: Det bliver aldrig færdigt, det bliver langt dyrere end planlagt, eller det bliver færdigt, men ingen bruger det. Den sidste er den mest oversete, fordi den ikke kan ses i budgettet.

Min tommelfingerregel: Kan du ikke svare på de første fire, så vent med at starte. De sidste otte kan rettes undervejs, men det bliver dyrere jo længere du venter.

Listen handler om det der sker efter du har valgt en udvikler. Står du stadig før det valg, så start med min guide til at hyre en udvikler.

Før første linje kode: fire årsager der bygges ind fra start

1. Ingen kan sige hvilket problem projektet løser

Mange projekter starter med en løsning: "Vi skal have en app" eller "vi skal have en kundeportal". Spørger du hvad der skal være anderledes om et år, er svaret uklart, eller tre personer giver tre forskellige svar.

Uden et klart mål kan ingen prioritere. Alle funktioner virker lige vigtige, og det bliver umuligt at sige nej til noget. Projektet kan blive leveret til tiden og alligevel fejle, fordi det løser et problem ingen havde.

Sådan undgår du det: Skriv målet på én sætning, og gør det målbart. Fx: "Kunderne skal selv kunne se og betale deres fakturaer, så bogholderiet får halvt så mange opkald." Tal med et par af dem der skal bruge systemet, før noget bliver tegnet. En funktion der ikke hjælper målet, er en kandidat til version to.

2. Alt skal med i første version

Når budgettet først er godkendt, føles det som nu eller aldrig. Derfor kommer alle ønsker med: rapporter, brugerroller, integrationer, måske en app ved siden af. Resultatet er et projekt der er langt større end nødvendigt, og som tager lang tid før nogen kan bruge det.

Set fra udviklerens stol er problemet ikke at store projekter er umulige. Det er at hver ekstra funktion også skal designes, testes, vedligeholdes og forklares til brugerne. Og hele lanceringen venter på den langsomste del.

Sådan undgår du det: Del ønskerne i to lister: det der skal med for at målet er nået, og det der kan vente. Vær hård ved den første liste. Første version skal være lille nok til at komme i brug hurtigt, så du lærer af rigtige brugere i stedet for at gætte. Hvordan du formulerer det over for en udvikler, kan du se i min skabelon til en projektbeskrivelse.

3. Ingen har det sidste ord

Udvikleren stiller et spørgsmål, og spørgsmålet går rundt i organisationen. Direktøren vil have én ting, salg en anden, og den der sidder med projektet, har ikke mandat til at vælge. I mellemtiden står arbejdet stille, eller udvikleren gætter.

Det omvendte er lige så slemt: en beslutningstager med mandat, men uden tid. Et svar der tager en uge, koster enten en uges ventetid eller en uges arbejde der skal laves om.

Sådan undgår du det: Udpeg én person der træffer beslutninger i det daglige, og sørg for at vedkommende har tid til det i kalenderen. Aftal hvilke beslutninger der skal op til ledelsen, og hvor hurtigt de skal træffes. Hvordan du sætter en fast rytme op, står i min guide til samarbejdet med en udvikler.

4. Prisen blev sat før opgaven var forstået

Projektet bliver beskrevet på et kort møde, og kort efter ligger der en fast pris. Budgettet bliver godkendt på det tal. Problemet er at ingen, heller ikke udvikleren, vidste præcis hvad der skulle bygges. Så enten er der lagt en stor buffer på, eller også bliver alt der ikke stod i beskrivelsen, til tillægsregninger og diskussioner.

Fra den anden side af bordet kan jeg sige det sådan: Et estimat er aldrig bedre end den forståelse det bygger på. Når jeg estimerer, er det de ukendte dele der skaber usikkerheden: integrationer, gamle data og regler der kun findes i hovedet på én medarbejder.

Sådan undgår du det: Bed om et interval tidligt og en fast pris senere. Ved større projekter er et kort, betalt forprojekt den mest pålidelige vej. Mål, omfang og ukendte dele bliver afklaret og skrevet ned, og først derefter bliver der estimeret. Sådan starter jeg selv større opgaver, til fast pris. Hvad en afklaring koster, og hvornår den betaler sig, har jeg skrevet om i prisen på en discovery-fase. Hold desuden en del af budgettet fri til det uforudsete. Min tommelfingerregel er 15-20 %.

Undervejs: når projektet glider uden at nogen opdager det

De næste tre årsager opstår når arbejdet er i gang. De er sværere at få øje på, fordi alt kan se fint ud i en statusmail.

5. Du ser først noget når det er for sent

Planen er at du ser systemet når det er færdigt. Indtil da får du at vide at det går godt. Ved afleveringen viser det sig at en central del er forstået forkert.

Jo længere tid der går mellem at noget bliver bygget, og at du ser det, jo mere er der bygget ovenpå. Derfor er sene opdagelser dyre: Det er sjældent én skærm der skal laves om, men alt det der bygger på den.

Sådan undgår du det: Aftal en kort demo hver eller hver anden uge, hvor du ser noget der virker. Få adgang til et testmiljø (staging), hvor du selv kan klikke rundt mellem demoerne. Brug et kvarter efter hver demo på at skrive ned hvad der skal ændres. Små rettelser hver anden uge er billigere end én stor rettelse til sidst.

6. Nye ønsker bliver lagt oveni

Undervejs dukker der gode idéer op. Det er sundt, for du lærer noget når du ser systemet. Problemet opstår når de nye ønsker bliver lagt oveni, uden at noget andet ryger ud, og uden at nogen siger hvad det betyder for tidsplanen. Hver ændring er lille. Tilsammen flytter de deadlinen, uden at nogen har besluttet det.

Sådan undgår du det: Hav én liste over ønsker, prioriteret af beslutningstageren. Når noget nyt kommer ind, skal det have en pris eller en plads i køen, og måske skal noget andet ud. Skriv ind i aftalen hvordan ændringer bliver estimeret og godkendt, før der bliver arbejdet på dem. Hvad aftalen ellers skal dække, har jeg samlet i de 14 punkter en kontrakt med en freelanceudvikler bør have.

7. Integrationer og gamle data bliver undervurderet

I tilbuddet står "integration til økonomisystemet" på én linje. I virkeligheden har systemets API begrænsninger som ingen kendte til, og de gamle kundedata ligger i tre regneark med hver sin stavemåde.

Integrationer og datamigrering (flytning af data fra det gamle system til det nye) er typisk de dele af et projekt der er sværest at estimere. Ingen ved hvad der gemmer sig, før nogen har kigget.

Sådan undgår du det: Lav en liste over alle systemer der skal kobles på, og alle data der skal flyttes. Lad udvikleren se API-dokumentationen og et udtræk af de rigtige data, før der bliver estimeret. Det er en typisk opgave i et forprojekt. Er der personoplysninger i dataene, så tænk GDPR ind fra start: hvad må flyttes, og hvad skal slettes.

Teknikken: årsager der først gør ondt senere

8. Der er ingen automatiske tests

Uden automatiske tests er den eneste måde at vide om noget virker, at nogen klikker det igennem. Det går i starten. Men jo større systemet bliver, jo mere er der at klikke igennem, og en ny funktion kan ødelægge fx login eller betaling, uden at nogen opdager det før en kunde gør.

Det sidste stadie er det dyreste: Udvikleren tør ikke ændre noget, fordi ingen ved hvad der går i stykker. Så tager selv små ændringer dage.

Sådan undgår du det: Spørg før start hvordan udvikleren tester. Du behøver ikke kræve tests af alt. Men de dele forretningen afhænger af, som betaling, login og beregninger, bør være dækket af tests der kører automatisk hver gang koden ændres. Til en lille hjemmeside er det sjældent nødvendigt. Til et system din forretning kører på, er det.

9. Teknologien passer til udvikleren, ikke til projektet

Nogle projekter bliver bygget med det nyeste værktøj, fordi udvikleren gerne vil prøve det. Andre bliver bygget som om de skulle klare millioner af brugere fra dag ét, med en opbygning der er langt mere kompliceret end opgaven kræver. Begge dele gør projektet dyrere at bygge og sværere at overtage. Det samme gør en sjælden teknologi som få andre udviklere kan arbejde med.

Sådan undgår du det: Bed om en begrundelse for teknologivalget der handler om dit projekt: antal brugere, integrationer og hvem der skal vedligeholde det bagefter. Vælg som udgangspunkt udbredte værktøjer med mange udviklere bag, så du ikke er låst til én person. Jeg arbejder selv primært med Laravel og React/Next.js, så jeg har en interesse i den anbefaling. Princippet gælder dog uanset værktøj.

10. Genveje under tidspres bliver aldrig ryddet op

Når en deadline nærmer sig, tager alle genveje. Det er ofte den rigtige beslutning. Problemet opstår når genvejene bliver permanente: en hurtig løsning her, en opdatering der bliver skubbet igen og igen. Det kaldes teknisk gæld, og den har renter: Hver ny ændring tager lidt længere tid end den forrige.

Sådan undgår du det: Bed udvikleren om at skrive genvejene ned når de bliver taget, så de ikke bliver glemt. Sæt fast tid af til oprydning og opdateringer, fx en lille del af hver måned. Det er kedeligt at betale for noget du ikke kan se. Alternativet er at betale mere for alt det du kan se.

Efter lanceringen: når ingen ejer systemet

11. Alt afhænger af én person

Koden ligger på udviklerens konto, serveren er betalt med udviklerens kort, og den eneste dokumentation findes i udviklerens hoved. Det fungerer fint, indtil personen bliver syg, får for travlt eller stopper. Så kan selv en lille fejl blive til uger uden løsning.

Det gælder også freelancere som mig. Én udvikler er et godt valg til mange projekter, men kun hvis opgaven kan gives videre uden at starte forfra.

Sådan undgår du det: Få koden i et repository (kodearkiv) på virksomhedens egen konto fra første dag, og opret domæne, hosting og andre tjenester i virksomhedens navn. Bed om kort dokumentation af hvordan systemet bliver sat op og sat i drift. Hos mig er koden kundens fra dag ét, og sådan bør det være uanset hvem du hyrer.

12. Lanceringen bliver set som målstregen

Budgettet er brugt når systemet går live, og ingen har planlagt hvad der sker bagefter. Men det er efter lanceringen at rigtige brugere finder fejl, beder om ændringer og opdager hvad der mangler. Samtidig skal framework og pakker opdateres løbende for at lukke sikkerhedshuller.

Et andet overset punkt er at medarbejderne faktisk skal tage systemet i brug. Uden oplæring og nogen at spørge til råds falder folk tilbage til det gamle regneark.

Sådan undgår du det: Sæt budget af til drift og videreudvikling før projektet starter, og udpeg en intern ejer af systemet efter lanceringen. Planlæg selve ibrugtagningen: hvem skal have oplæring, hvornår bliver det gamle system lukket, og hvem samler feedback de første uger.

Tidlige advarselstegn: sådan opdager du at projektet er på vej mod problemer

Projekter fejler sjældent på én dag. Der er næsten altid tegn undervejs:

• Demoer bliver udskudt, eller du får præsentationer i stedet for noget der virker.
• En opgave har været "næsten færdig" i flere uger.
• Estimatet for resten ændrer sig hver gang du spørger.
• Du kan ikke se hvad timerne er gået til.
• De samme fejl kommer igen, efter de er blevet rettet.
• Udvikleren fraråder ændringer, fordi "det kan gå i stykker".

Ser du to eller flere af dem, så stop op. Bed om en ærlig status: hvad er færdigt, hvad mangler, og hvad er usikkert. Prioritér listen igen, og overvej at skære i omfanget frem for at forlænge tidsplanen. Er tilliden væk, kan det være rigtigt at skifte. Sådan gør du det uden at miste det der allerede er bygget: guide til at skifte udvikler midt i et projekt.

Næste skridt: tjek de første fire før du går i gang

Brug listen her før du skriver under på et projekt, og igen når projektet er et par uger i gang.

Kan du ikke sætte kryds ved de fire første, er det næste skridt ikke at hyre en udvikler. Det er at afklare opgaven, enten selv med en projektbeskrivelse eller i et betalt forprojekt. Nogle gange viser afklaringen at du slet ikke skal have noget bygget, fordi et standardsystem dækker behovet. Det er også et godt resultat. Vil du se hvordan jeg prissætter forprojekter og de projekter der følger efter, så står det på siden med mine priser.

Ofte stillede spørgsmål

Hvor mange IT-projekter fejler egentlig?+

Der findes ikke ét tal jeg vil stå inde for. De tal der cirkulerer, bygger på forskellige definitioner af hvad det vil sige at fejle: forsinket, over budget, aldrig færdigt eller ikke taget i brug. Det vigtigste er at aftale jeres egen definition før start. Et projekt der er til tiden og inden for budget, er stadig fejlet hvis ingen bruger det.

Kan et projekt der er gået i stå, reddes?+

Ofte ja, men ikke altid i sin nuværende form. Start med en ærlig gennemgang af koden og en liste over hvad der virker, hvad der mangler, og hvad der er usikkert. Typisk kan en del af koden bruges videre, mens resten bliver ryddet op eller bygget om. At starte helt forfra er sjældent det billigste, men det kan være det rigtige hvis fundamentet ikke holder.

Beskytter en fast pris mod at projektet fejler?+

Kun delvist. En fast pris flytter den økonomiske risiko over på udvikleren, men den løser ikke et uklart mål eller en manglende beslutningstager. Er opgaven uklar, ender fast pris ofte i diskussioner om hvad der var med. Fast pris fungerer bedst når omfanget er afklaret, fx efter et forprojekt, og når ændringer har en aftalt proces.

Er agil udvikling løsningen på problemerne?+

Agil udvikling hjælper på flere af årsagerne, især sen feedback og nye ønsker, fordi du ser noget der virker med få ugers mellemrum og kan prioritere løbende. Men metoden kræver mere af dig som kunde: en beslutningstager der er til stede, og vilje til at skære fra. Uden det bliver agil bare et andet ord for at der ikke er en plan.

Hvem har ansvaret når et IT-projekt fejler?+

Som regel ligger ansvaret begge steder. Udvikleren har ansvar for faglig kvalitet, ærlige estimater og for at sige til når noget er uklart. Kunden har ansvar for mål, beslutninger og adgang til den viden projektet kræver. Hvad der gælder juridisk, afhænger af jeres kontrakt. Står I i en reel tvist, så tal med en advokat.