Kleine teams vs. grote consultancies: waarom minder mensen betere software bouwen
Er is iets merkwaardigs aan de hand in de IT-sector. Iedereen weet dat grote softwareprojecten mislukken. En toch blijven we het doen. Over de cijfers, de patronen, en wat er gebeurt als je het anders doet.
Er is iets merkwaardigs aan de hand in de IT-sector. Iedereen weet dat grote softwareprojecten bijna altijd mislukken. Het is geen geheim, het staat in elk onderzoek, elk rapport, elke post-mortem. En toch blijven we het doen. Steeds opnieuw. Alsof het deze keer anders zal zijn.
Vorig jaar sprak ik een CTO die net groen licht had gekregen voor een migratie van 18 maanden met een extern team van 40 man. Ik vroeg hem of hij wist wat het slagingspercentage is van IT-projecten van die omvang. Hij wist het. Hij noemde zelf het getal. En hij ging toch door.
Dat is waar dit artikel over gaat. Niet alleen over de cijfers (hoewel die behoorlijk ontnuchterend zijn), maar over de vraag waarom een hele industrie collectief blijft kiezen voor een aanpak die aantoonbaar niet werkt. En over wat er gebeurt als je het anders doet.
Een half miljard euro, en dan terug naar af
In 2011 startte Lidl het project eLWIS: een SAP-implementatie voor meer dan 10.000 winkels in 29 landen. Lidl is geen klein bedrijf. De Schwarz Gruppe, het moederbedrijf, doet jaarlijks ruim €104 miljard omzet. Dit was geen organisatie zonder middelen of ervaring.
Zeven jaar later trok Lidl de stekker eruit. Naar schatting €500 miljoen uitgegeven. Geen werkend systeem. Geen uitrol. Alleen facturen.
Wat was er misgegaan? Het kernprobleem klinkt bijna banaal. Lidl baseerde haar voorraadbeheer op inkoopprijzen, SAP draait op verkoopprijzen. In plaats van hun processen aan te passen, eisten ze vergaand maatwerk. Op piekmomenten werkten er honderden externe consultants tegelijkertijd aan het project.
"Als een bedrijf standaardsoftware wil gebruiken, moet het zijn eigen processen aanpassen."
Jean-Claude Flury, voorzitter DSAG (wereldwijde SAP-gebruikersgroep)
Wat hier interessant is: Lidl wist dit. Iedereen in de SAP-wereld weet dit. Maar honderden consultants hebben geen prikkel om "doe dit niet" te adviseren. Het project is het product.
Na de stopzetting keerde Lidl terug naar hun legacy-systeem uit de jaren negentig. In 2024 startten ze opnieuw, maar nu met het kleine Hamburgse bureau Freiheit: een eigen systeem, eigen cloud, geen SAP, geen grote consultancies. De les kostte een half miljard.
De cijfers die de industrie liever negeert
Er is genoeg onderzoek gedaan naar het falen van grote IT-projecten om er een kleine bibliotheek mee te vullen. Een paar getallen die er voor mij uitspringen.
Bronnen: Standish Group CHAOS Report (50.000+ projecten), McKinsey/Oxford (5.400+ projecten)
Dat laatste getal verdient context. Het McKinsey/Oxford-onderzoek keek naar grote IT-projecten met budgetten boven $15 miljoen. Bijna een op de vijf werd een complete ontsporing: niet tientallen procenten over budget, maar honderden. Dat zijn de projecten die bedrijven soms in hun voortbestaan bedreigen.
En dan de SAP-wereld specifiek. Een Horvath-studie uit 2025 onder 200 SAP-gebruikers vond dat slechts 8% van S/4HANA-migraties op schema liep. Acht procent. Bij meer dan 60% waren er tegelijkertijd afwijkingen in budget, planning en kwaliteit. Je zou denken dat die resultaten iemand aan het denken zetten.
Het kleine-teams-voordeel is geen mythe
Dat kleine teams beter presteren is niet zomaar een gevoel of een Silicon Valley-cliche. Het is een van de meest consistent bevestigde patronen in de software engineering. En het mechanisme erachter is eigenlijk vrij simpel.
Een wiskundig probleem
In 1975 formuleerde Fred Brooks wat nu bekend staat als Brooks's Law: "Adding manpower to a late software project makes it later." Vijftig jaar later heeft niemand dit weerlegd. De reden is wiskundig: n personen creeren n(n-1)/2 communicatiekanalen. Een team van 5 heeft 10 onderlinge verbindingen. Een team van 50 heeft er 1.225.
Dat klinkt abstract, maar in de praktijk betekent het dit: hoe meer mensen, hoe meer tijd iedereen kwijt is aan afstemmen in plaats van bouwen. Op een gegeven moment breng je meer tijd door met coordineren dan met het eigenlijke werk. Ik heb het zien gebeuren. Meerdere keren.
Niet een keer bevestigd, maar keer op keer
QSM analyseerde 491 softwareprojecten en concludeerde dat de optimale teamgrootte 3 tot 7 personen is. De ISBSG-database (1.000+ projecten) bevestigt dit: teams van 9+ zijn significant minder productief. Harvard-psycholoog J. Richard Hackman kwam na decennia onderzoek op 4 tot 6 als het optimale formaat.
Jeff Bezos' bekende "two-pizza team"-regel komt hier niet uit de lucht vallen. AWS en Amazon Marketplace zijn gebouwd door teams van minder dan 10 mensen. Niet omdat Bezos een hekel heeft aan grote groepen, maar omdat hij zag dat kleine teams sneller en beter werk leverden.
Een patroon dat zichzelf blijft herhalen
Lidl is geen uitzondering. Het is een voorbeeld uit een lange, deprimerende reeks. Wat opvalt: het script is elke keer bijna identiek.
De Parlementaire Commissie Elias schatte in 2014 dat ICT-mislukkingen bij de Rijksoverheid €1 tot €5 miljard per jaar kosten. Per jaar. Het patroon: het A-team presenteert bij de pitch, maar juniors draaien het project. Scope groeit, deadlines schuiven, facturen lopen door.
"Ondanks 20 jaar SAP-implementaties geven bedrijven miljoenen uit en verprutsen het nog steeds."
Derek Prior, voormalig Gartner SAP-analist
Het tegenvoorbeeld is net zo leerzaam. Toen het $600M+ Healthcare.gov-project van CGI Federal bij lancering crashte, was het een klein "tech surge"-team van circa 20 engineers dat de site binnen weken stabiliseerde. Niet 200 man. Twintig. Dit leidde tot de oprichting van de US Digital Service, de permanente erkenning dat klein en goed beter werkt dan groot en duur.
Kleine teams, grote resultaten
Terwijl grote consultancies projecten van honderden miljoenen de mist in laten gaan, bouwen handjes vol mensen de meest waardevolle softwarebedrijven ter wereld. Dat zou ons aan het denken moeten zetten.
Cursor
Vier MIT-studenten richtten Cursor op in 2022. In minder dan een jaar gingen ze van $1M naar $100M jaarlijkse omzet, de snelste groei in SaaS-geschiedenis. Waardering eind 2025: $29,3 miljard. Vier mensen. Geen stuurgroep.
Midjourney
Geen externe investeerders. Geen marketingbudget. Winstgevend na een maand. Geschatte omzet tussen de $300 en $500 miljoen, met een omzet per medewerker van meer dan $3 miljoen. Dat is een getal waar de meeste bedrijven niet eens van durven dromen.
Bolt.new
Een team van circa 15 mensen. Van nul naar $4M jaaromzet in 4 weken. Op het hoogtepunt voegden ze een half miljoen dollar per dag toe aan recurring revenue.
En dit patroon is niet nieuw. Instagram had 13 medewerkers bij de $1 miljard overname. WhatsApp had er 55 toen Facebook $19 miljard betaalde. De meest impactvolle software wordt niet gebouwd door legers consultants. Het wordt gebouwd door kleine groepen die weten wat ze doen en de ruimte krijgen om het te doen.
Drie dingen om mee te nemen
Meer mensen is meer risico
Elk extra teamlid voegt communicatiecomplexiteit toe. Dat is geen mening, dat is wiskunde. De reflex om bij problemen "meer mensen erop te zetten" maakt projecten langzamer, niet sneller. Brooks wist het in 1975. De Standish Group bevestigt het met 50.000 datapunten. En toch.
Kies voor mensen die blijven
Een klein team van specialisten die jouw domein begrijpen levert meer op dan 50 consultants die volgende maand op een ander project zitten. Zoek partners die belang hebben bij het resultaat, niet bij het aantal uren.
Lever iets werkends, snel
De succesvolste softwareprojecten beginnen niet met een requirements-document van 200 pagina's. Ze beginnen met een helder probleem, een klein team, en werkende software binnen weken. Niet een presentatie over software. Software.
Herkenbaar?
Als je nadenkt over een nieuw softwareproject en dit verhaal je bekend voorkomt, praat eens met ons. Geen pitch deck, gewoon een goed gesprek over wat je nodig hebt.
Neem contact opLaten we van start gaan
Samen zorgen wij voor slimme digitale oplossingen voor de uitdagingen van jouw organisatie. Geen gehaaste en kortstondige producten maar doordachte, kwalitatief hoogwaardige oplossingen met UX Design en technologische kennis als fundament. Zodat jouw organisatie klaar is voor morgen.
Of bekijk onze cases , blogposts of leer ons team kennen.