Når et softwareprojekt er kørt fast, er det bedste første skridt at holde igen med store beslutninger i et par uger og samle fakta. Afgør, om I ser en enkelt fejl eller et mønster, og skaf svar på fire ting: det, der er bygget, det, der virker, det, der mangler, og hvem der ejer det hele. Først derefter kan I vælge mellem at fortsætte, rette op, skifte eller starte forfra. De fleste dyre fejl i den situation sker, fordi nogen handler i vrede, eller fordi endnu en faktura bliver betalt uden en plan.
Enkeltfejl eller mønster?
Alle softwareprojekter har dårlige perioder. En forsinkelse efter en stor ændring i jeres ønsker, en udvikler, der blev syg, eller en teknisk overraskelse er ikke i sig selv et brud på tilliden. Spørg derfor, om problemet har en klar årsag, og om det kunne undgås af dem eller af jer.
Mønsteret ser anderledes ud:
- Datoer bliver flyttet gang på gang med nye forklaringer.
- Timerne vokser, mens det, I kan klikke på, står stille.
- Fejl kommer igen, når de er rettet.
- Udviklerne på opgaven skifter, uden at I får besked.
- I kan ikke få svar på enkle spørgsmål om status.
Vær også ærlig om jeres egen del. Skiftende ønsker og uklare beslutninger er en almindelig medvirkende årsag. Det er sværere at læse, men det afgør, om det samme sker igen hos den næste.
Stilstanden før beslutningen
Lav en aftalt pause, hvor I undgår nye større forpligtelser. Stands nye funktioner, hvis I kan, og aftal med leverandøren, at I gør status. Betalinger og aftalebrud er juridiske spørgsmål, så tal med en advokat, før I holder penge tilbage eller skriver noget, der ligner en opsigelse.
Sideløbende indsamler I materialet:
- Aftalen, tilbuddet og eventuelle tillæg.
- Alle fakturaer og timeopgørelser.
- Mails og referater, hvor ændringer og forsinkelser er nævnt.
- En kopi af koden med historik, hvis I kan få den.
Materialet bruger I både til at forstå sagen og til at stå stærkt, hvis det ender i en tvist.
De fire spørgsmål
Hvad er bygget? Bed om en liste over det, der findes, og sammenhold den med det aftalte. Listen skal komme i almindeligt sprog, sat op efter funktioner og fra kundens side.
Hvad virker? Prøv det selv. Find et miljø, I kan logge ind i, og gennemfør de forløb, en rigtig kunde skal igennem. Notér, hvor det stopper. Det kræver ingen teknisk baggrund, og det er ofte det, der flytter samtalen fra løfter til fakta.
Hvad mangler? Her er det nødvendigt at skille det ufærdige fra det usynlige. Sikkerhed, drift, test og sikkerhedskopier fylder lidt i en demo, men de skal være der, før produktet kan bære kunder. Spørg konkret til hvert punkt.
Hvem ejer det? Gennemgå kode, konti og domæner med ejer I selv koden og kontiene. Svaret afgør, hvor frit I kan vælge. Rettighederne er et emne for sig, se hvem ejer koden.
Spørgsmålet om, hvordan koden er indeni, kræver udviklerkendskab. Har I brug for svaret, er det en opgave for en uafhængig udvikler, se uafhængig gennemgang af koden. Bed om en rapport, som ledelsen kan læse.
Fire veje videre
Med svarene i hånden står I reelt med fire muligheder.
Fortsætte. Årsagen var klar, leverandøren erkender den, og tillid kan genopbygges. Tilføj bedre styring, se sådan styrer I en udviklingsleverandør.
Rette op. Aftal en konkret plan med datoer, nye folk på opgaven eller en mindre næste leverance, og sæt en grænse for, hvornår I går videre. Planen skal være målbar og kort.
Skifte. Koden kan bruges, men tilliden eller evnen er væk. Følg skift af udviklingsleverandør, og tag rækkefølgen alvorligt.
Starte forfra. Det er den dyreste vej og kun rigtig, når det bestående ikke kan bære produktet, eller når I kun har en lille del af det, der skal bygges. Forslaget kommer ofte fra den næste leverandør, og derfor skal grunden holde, se tre spørgsmål til det forslag.
Lad økonomien i de resterende muligheder afgøre valget. Det, der allerede er brugt, kommer ikke tilbage, uanset hvilken vej I går. Spørg kun, hvad det koster herfra, og hvad I får.
Når grundlaget er samlet, skal nogen stå for valget og for styringen bagefter. Det kan Nielco IT gøre som fractional CTO, afgrænset til ledelse, leverandører og teknologivalg, mens bedømmelsen af selve koden hører til hos en uafhængig udvikler.
Det skal I lade være med
- At betale for mere uden en plan · endnu en måned giver sjældent et nyt resultat.
- At sende en vred mail · skriftlig tone kan ikke kaldes tilbage og hjælper sjældent sagen.
- At vælge at starte forfra alene på den næstes råd · den, der foreslår det, får opgaven.
- At springe jeres egen del over · ellers sker det igen hos den næste.
Det skal I kræve af den eksterne
- ☐ En skriftlig status på, hvad der er bygget, virker og mangler.
- ☐ Afklaring af ejerskab til kode og konti.
- ☐ En anbefaling mellem de fire veje med begrundelse og risici.
- ☐ Tydelig adskillelse af tekniske og juridiske spørgsmål.
- ☐ Uafhængighed af den leverandør, I vælger.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Skal udviklingen hjem? · Sådan følger I fremdriften, når I ikke selv kan læse koden
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
