Hvorfor fejler IT-projekter, og hvordan redder man dem?

Ni måneder inde i projektet er lanceringen flyttet tre gange. Hvert statusmøde ender med, at systemet er “90 % færdigt”. Medarbejderne arbejder stadig i de samme regneark, som systemet skulle erstatte, og fakturaerne er nået op på det dobbelte af det oprindelige budget. Ingen har gjort noget decideret forkert, og alligevel er projektet ved at gå i stå. Den historie kender mange ledere, og den følger næsten altid det samme mønster.

Det gode er, at mønstret kan genkendes tidligt. Denne guide gennemgår de ni mest almindelige årsager til, at IT-projekter fejler, de advarselssignaler I kan holde øje med fra første måned, og en redningsplan til et projekt, der allerede er kørt fast. Tallene er eksempler; årsagerne er dem, vi ser i praksis, når virksomheder kommer til os med et projekt, der er gået i stå.

Hvorfor fejler IT-projekter? De ni mest almindelige årsager

Læg mærke til, hvor få af årsagerne der handler om programmering. Dårlig kode findes, og den skaber teknisk gæld, som gør hver ændring dyrere. Men selv den dårligste kode er som regel et symptom på noget andet: et omfang, der voksede, en deadline, der blev presset, eller et team, der skiftede undervejs.

Det starter oftest med omfanget

Det mest almindelige mønster er, at første version skal kunne alt. Når salg, økonomi, lager og kundeservice hver får deres ønsker med, bliver projektet langt, og ingen af ønskerne bliver testet af rigtige brugere, før alt er færdigt. Det er derfor, vi anbefaler at starte med en afgrænset første version, et MVP, og at beskrive funktionerne som brugerhistorier, så det er tydeligt, hvem der får gavn af hvad. Det gør det også let at prioritere, når budgettet strammer.

Integrationer er den største ukendte

Et system, der skal tale med e-conomic, et ERP, MitID eller en fragtleverandør, afhænger af noget, ingen af parterne styrer. Dokumentationen kan være mangelfuld, abonnementet kan mangle adgang til API’et, eller data kan ligge i et andet format end forventet. Når integrationerne bygges til sidst, opdages problemerne til sidst. Byg dem i de første uger, også selv om de kun virker med testdata. Vores guide hvad er et API forklarer, hvad der skal på plads.

Hvilke advarselssignaler viser, at et IT-projekt er ved at fejle?

• I har ikke set noget, der virker, i mere end fire uger.
• Status er “næsten færdig” flere møder i træk.
• Lanceringsdatoen er flyttet mere end én gang uden en ny, konkret plan.
• Leverandørens spørgsmål ligger ubesvaret hos jer i over en uge.
• Timeforbruget vokser hurtigere end listen over færdige funktioner.
• Nye ønsker kommer ind, uden at noget andet bliver taget ud.
• Integrationerne er “planlagt til sidst”.
• De folk, der byggede starten, er skiftet ud.
• I har ikke adgang til koden eller testmiljøet.
• Ingen kan sige, hvad der sker dagen efter lanceringen.

“90 % færdig” er det mest sigende signal. I software er de sidste ti procent ofte det sværeste: fejlhåndtering, kanttilfælde, datamigrering, integrationer og test på rigtige enheder. Når et projekt har været 90 % færdigt i to måneder, er det typisk, fordi de svære dele er skubbet til sidst. Bed om at se de konkrete funktioner køre, og bed om en liste over det, der mangler.

Hvordan ser et sundt IT-projekt ud i forhold til et projekt i problemer?

Det er værd at bemærke, at begge kolonner kan forekomme med både agil og vandfald som metode. Metoden er mindre afgørende end rytmen: korte leverancer, tidlige integrationer og klare beslutninger. Vi har skrevet mere om, hvordan fast pris og agil udvikling spiller sammen, i agil vs vandfald.

Hvordan redder man et IT-projekt, der er gået i stå?

Trin to er det, der giver jer frihed. Uden adgang til koden kan I hverken få en uafhængig vurdering eller skifte leverandør, og I står svagt i enhver forhandling. Har I ikke adgang i dag, så start med at få den; vores guide om hvem der ejer koden har en tjekliste til netop den situation.

Skal I reparere, bygge om eller skifte leverandør?

Den sidste række er blevet mere almindelig. Mange virksomheder har fået lavet en hurtig prototype med AI-værktøjer, som virker i en demo, men mangler login, adgangsstyring og test. Det kan være et glimrende udgangspunkt, hvis det bliver behandlet som en prototype. Læs fra AI-prototype til produktion. Er systemet ældre og svært at ændre, så se modernisering af ældre systemer.

Hvad kan I gøre før start, så projektet ikke fejler?

1. Skriv ét målbart mål for projektet, fx “halvere tiden på fakturering”.
2. Definér en første version, der kan lanceres inden for få måneder.
3. Udpeg én beslutningstager hos jer med tid og mandat.
4. Vælg leverandør med en fast proces og ens kriterier.
5. Aftal fungerende leverancer hver anden til fjerde uge.
6. Planlæg integrationer og datamigrering tidligt i forløbet.
7. Få kode, data og konti skrevet ind i jeres navn.
8. Aftal drift og ejerskab internt, før I lancerer.

Punkt fire er så stort, at vi har skrevet en hel guide om det: sådan vælger I et softwarehus, med en pointtabel til at sammenligne leverandører. Og når tilbuddene kommer ind, så brug røde flag i et IT-tilbud til at finde risiciene, før de bliver jeres.

Hvad gør vi hos Ceptiv for at holde projekter på sporet?

Vores måde at arbejde på er bygget op omkring årsagerne ovenfor. Vi giver fast pris på et afgrænset omfang, så der ikke er åbne timer at løbe tør for. Design og udvikling sker i ét senior-team uden overleveringer mellem afdelinger. Vi bruger mere end 40 færdige integrationer, blandt andet til e-conomic, Dinero, MobilePay, PostNord, Penneo og MitID, så de mest almindelige ukendte er kendte på forhånd. Og I følger fremdriften i kundepanelet, hvor leverancer og beslutninger ligger samlet.

Store løsninger kan sagtens bygges i dele. Til Vaskekonerne har vi lavet otte løsninger i ét kredsløb, fra hjemmeside og booking til drift. Har I et projekt, der er gået i stå, så beskriv situationen her. Vi vurderer, hvad der kan genbruges, og I får et skriftligt bud på vejen videre inden for 24 timer.