Waarom mislukken software projecten? 10 oorzaken en hun impact

Software projecten lopen vaker mis dan goed. Het meest recente onderzoek van het Project Management Institute (december 2025) toont aan dat slechts de helft van alle projecten als succesvol wordt beoordeeld. Voor bedrijfstransformaties is het beeld nog scherper: Bain becijferde in april 2024 dat 88% van zulke trajecten niet de oorspronkelijke ambities haalt. IEEE Spectrum vatte het begin 2026 zo samen: de wereldwijde IT-uitgaven zijn sinds 2005 verdrievoudigd, maar de slaagpercentages voor software zijn al twee decennia nauwelijks vooruitgegaan.

Dichter bij huis levert de Belgische actualiteit met regelmaat een nieuw voorbeeld. Eind 2025 trok minister Quintin de stekker uit i-Police, het digitaliseringsproject van de federale politie: van een contract van 299 miljoen euro werd 75,8 miljoen uitbetaald, zonder operationeel resultaat. Volgens een reconstructie van De Tijd en L'Echo lopen de werkelijke maatschappelijke kosten in de honderden miljoenen. Begin 2026 stopte de Vlaamse regering om dezelfde redenen het onderwijsproject Persona na 16 miljoen euro. Professor Overheidsdigitalisering Lieselot Danneels vatte het beeld op Radio 1 zo samen: "Slechts 1 op de 4 projecten slaagt, bij de overheid is dat zelfs 1 op 5." Overheidsprojecten zijn zichtbaarder dan B2B-trajecten, maar de onderliggende patronen zijn opvallend gelijk.

We zitten al een tijdje in het vak (eerst als freelancers, nu samen onder Tandem), en zien telkens dezelfde tien valkuilen terugkomen bij B2B-projecten. Hieronder zetten we ze op een rij. En omdat het te makkelijk is om te zeggen "ja, wij doen het natuurlijk beter", leggen we er meteen onze aanpak naast. Inclusief de plekken waar wij ook geen wonderen doen.

De tien redenen waarom het misgaat

1. Onduidelijke requirements. Klanten weten niet altijd precies wat ze nodig hebben. Wat aan de oppervlakte ligt is vaak het huidige proces, terwijl de eigenlijke businessbehoefte een laag dieper zit. Het resultaat: software die voldoet aan de specificatie op papier, maar de werkelijke werkvloer niet vooruithelpt.

2. Zwakke product owner aan klantzijde. Iemand moet beslissingen mogen én kunnen nemen. Als dat ontbreekt, blijft elke knoop wekenlang hangen, terwijl de leverancier wel doortikt op de teller en het team momentum verliest bij elke escalatie.

3. Stakeholders niet uitgelijnd. Sales, ops, finance en IT willen vaak andere dingen. Als dat niet vooraf is uitgeklaard, komt het tijdens de bouw boven, en op dat moment wordt herstellen duur: features afbouwen die net opgeleverd zijn, andere alsnog bijbouwen, en de tijd om dat tot één coherent product te smeden komt er gratis bij.

4. Onderschatte integraties. Legacy ERP's, vieze databases, ongedocumenteerde API's. "We sluiten even aan op systeem X" blijkt steevast een factor 2 tot 5 zwaarder dan ingeschat, en dat ontdek je meestal pas wanneer het kritieke pad er al van afhangt.

5. Big-bang oplevering. Twaalf maanden bouwen zonder echte gebruikers is een gokje. Pas bij oplevering ontdek je wat er écht ontbreekt, of erger: dat het product zoals gevraagd niet doet wat het zou moeten doen. Tegen die tijd is een groot deel van het budget al weg en is het draagvlak voor een tweede ronde meestal zoek.

6. Geen adoptie. De software werkt, maar niemand gebruikt hem zoals bedoeld. Training, change management en interne politiek worden chronisch vergeten, en de investering verdampt in stilte: de oude Excel-bestanden blijven in gebruik, de officiële tool wordt een lege schil waar enkel het verplichte vinkje in wordt gezet.

7. Verkeerde contractvorm. Fixed-price op onbekend terrein zet leverancier en klant tegenover elkaar: de ene wil scope minimaliseren, de andere maximaliseren. Niemand bouwt nog product, iedereen managet het contract. Vergaderingen gaan over wat wel of niet in de offerte staat, in plaats van over wat de eindgebruiker écht nodig heeft. Een minder zichtbaar gevolg: om marge en zekerheid in te bouwen rond een onzekere scope, kiest de leverancier vaak voor meer architectuur dan strikt nodig. Dat patroon noemen we overengineering, en het werkt als een verborgen kostendrijver die zich ook in meerdere andere oorzaken hierboven en hieronder verstopt

8. Security en GDPR achteraf. Compliance pas bij oplevering bedenken vraagt om architecturele wijzigingen op het slechtst denkbare moment: vlak voor go-live, wanneer alles bevroren zou moeten zijn. Het resultaat: uitgestelde lanceringen, dure herwerking, en in gereguleerde sectoren een no-go bij audits.

9. Scope creep zonder discipline. Elke nieuwe wens erbij zonder prijskaartje is begroting-erosie in slow motion. Tegelijk verschuift de deadline mee, daalt de kwaliteit, en raakt het team uitgeput van steeds wisselende prioriteiten. Het einde komt niet in zicht, want het einde wordt elke week opnieuw onderhandeld.

10. Het laatste 20%. Hardening, edge cases, foutafhandeling, productie-stabiliteit. De demo na drie maanden ziet er goed uit, maar het taaie afronden wordt structureel onderschat. Hoe langer een project bovendien sleept, hoe sneller het uit de hand glijdt: het team raakt vermoeid, sleutelmensen vertrekken, en wat in de demo werkte breekt in productie onder echte gebruikers en echte data.

Hoe wij dat anders proberen aan te pakken

Onze aanpak draait om twee dingen die elkaar versterken: werken in spikes en werken met event sourcing.

Spikes als werkmethode

Een spike is een korte, afgebakende iteratie waarin we iets concreet bouwen of toetsen. In plaats van maandenlang alles vooraf te willen specificeren, doen we eerst een spike op het stuk waar de meeste onzekerheid zit: typisch een integratie, een complexe businessregel, of een usability-vraag.

Na elke spike weet iedereen meer, en weten we wat de volgende fase écht gaat kosten. Dat raakt direct aan punten 1, 4, 5, 7 en 9:

• requirements worden concreet en toetsbaar in plaats van speculatief;
• vieze integraties en legacy-rotzooi vinden we vroeg, niet halverwege;
• er is geen big-bang oplevering, want elke spike levert iets toetsbaars op;
• we contracteren per fase met een vaste prijs, geen mega-budget vooraf;
• elke nieuwe wens krijgt automatisch een prijskaartje, want hij komt in de volgende spike.

Het is overigens de richting waar zelfs de Belgische overheid na de i-Police-affaire publiekelijk naar grijpt. Minister Quintin kondigde bij de stopzetting aan voortaan in te zetten op "kleinschalige en modulaire projecten" in plaats van mega-contracten.

Werken met event sourcing

Event sourcing is onze standaard architectuurkeuze waar het past. In plaats van enkel de huidige toestand op te slaan, registreren we alle bedrijfsgebeurtenissen ("klant geregistreerd", "factuur betaald", "order verzonden") als onveranderlijke feiten. Dat klinkt abstract, maar het heeft drie concrete effecten:

• In de analysefase dwingt het stakeholders om in domeingebeurtenissen te denken in plaats van in schermen of tabellen. Sales, ops en IT komen sneller op dezelfde lijn omdat ze het over dezelfde feiten hebben (punt 3).
• Tijdens de bouw wordt elke gebeurtenis een natuurlijk koppelvlak. Een nieuw systeem subscribet zich op events zonder dat de core hoeft te wijzigen, wat directe winst oplevert voor integraties (punt 4) en voor scope-flexibiliteit (punt 9).
• Voor compliance krijg je er gratis een complete audit trail bij: wie deed wat wanneer, onveranderlijk vastgelegd. In gereguleerde B2B-sectoren is dat goud waard (punt 8). Right-to-be-forgotten vraagt wel een bewuste ontwerpkeuze, maar dat is perfect oplosbaar.

Daarbovenop hosten we standaard op Europese cloud, met code en data in eigendom van de klant en zonder vendor lock-in. Dat sluit de cirkel rond punt 8.

Waar wij óók geen wonderen doen

Twee punten waarvoor geen leverancier een complete oplossing heeft. Wij ook niet.

Een zwakke product owner aan klantzijde (punt 2). We kunnen veel compenseren door dicht bij de klant te zitten en zelf de vragen op te halen. Maar als intern niemand mandaat heeft om knopen door te hakken, blijft elk project hangen. Dit bespreken we liever vooraf dan tijdens.

Adoptie en change management (punt 6). Onze UX-aanpak helpt: we vertrekken vanuit de mensen die de software gaan gebruiken, niet vanuit het systeem. Maar de organisatorische kant (training, communicatie, processen aanpassen) blijft grotendeels bij de klant zelf. We helpen waar we kunnen, we kunnen het niet overnemen.

Tot slot

De cijfers schuiven al decennialang nauwelijks op. Niet omdat we slechtere ontwikkelaars zijn dan vroeger, wél omdat de niet-technische kant van software bouwen onderschat blijft. Daarom beginnen wij liefst waar het écht spannend is: bij de mensen die het gaan gebruiken, en bij de aannames die we durven toetsen vóór we ze als waarheid in code gieten.

Wil je eens samen kijken waar in jouw zaak de grootste valkuil zit? Plan een kennismaking.

Bronnen

Internationaal onderzoek

• Project Management Institute, Step Up: Redefining the Path to Project Success with M.O.R.E. (december 2025). Onderzoek bij 5.800+ projectprofessionals: slechts de helft van projecten wordt globaal als succesvol beoordeeld.
• Bain & Company, 88% of business transformations fail to achieve their original ambitions (april 2024). Slechts 12% van bedrijfstransformaties haalt de oorspronkelijke doelstellingen.
• IEEE Spectrum, Software Failures and IT Management's Repeated Mistakes (januari 2026). Mondiale IT-uitgaven zijn sinds 2005 verdrievoudigd, terwijl slaagpercentages voor software al twee decennia stagneren.
• Giulio Arcidiacono, Comparative research on IT project failure rates: a 2025 longitudinal update, PM World Journal (januari 2026). Standish CHAOS-data uit de cyclus 2020-2024 bevestigen een blijvend hoog faalpercentage en stagnerende succesratio's.

Belgische context

• De Tijd, Parket opent onderzoek naar mislukking i-Police, (27 januari 2026). Investigatieve reconstructie van het i-Police-dossier samen met L'Echo.
• VRT NWS, Nu ook Demir stekker eruit trekt: waarom mislukken IT-projecten bij overheid zo vaak? (27 januari 2026). Analyse met interview met professor Overheidsdigitalisering Lieselot Danneels.
• VRT NWS, Digitalisering politie mislukt: minister trekt streep door monstercontract van 299 miljoen euro (26 december 2025). Aankondiging van de stopzetting en de aangekondigde koerswijziging naar kleinschalige projecten.