Small teams vs. large consultancies: why fewer people build better software.
Something curious is going on in the IT sector. Everyone knows that large software projects fail. And yet we keep doing them. About the figures, the patterns, and what happens when you do things differently.
Something curious is going on in the IT sector. Everyone knows that large software projects almost always fail. It's no secret; it's in every study, every report, every post-mortem. And yet we keep doing it. Over and over. As if this time it will be different.
Last year I spoke with a CTO who had just been given the green light for an 18-month migration with an external team of 40. I asked him whether he knew the success rate of IT projects of that size. He did know. He cited the figure himself. And he went ahead anyway.
That is what this article is about. Not just the numbers (although they are quite sobering), but the question of why an entire industry collectively keeps choosing an approach that demonstrably doesn't work. And what happens when you do things differently.
Half a billion euros, and then back to square one
In 2011, Lidl started the eLWIS project: an SAP implementation for more than 10,000 stores in 29 countries. Lidl is no small business. The Schwarz Gruppe, the parent company, generates over €104 billion in annual revenue. This was not an organisation lacking resources or experience.
Seven years later, Lidl pulled the plug. An estimated €500 million had been spent. No working system. No rollout. Just invoices.
What went wrong? The core problem sounds almost trivial. Lidl based its inventory management on purchase prices, whereas SAP operates on selling prices. Rather than adapting their processes, they demanded extensive customisation. At peak moments, hundreds of external consultants were working on the project simultaneously.
"If a company wants to use standard software, it has to adapt its own processes."
Jean-Claude Flury, chairman of DSAG (the global SAP user group)
What is interesting here: Lidl knew this. Everyone in the SAP world knows this. But hundreds of consultants have no incentive to advise "don't do this". The project is the product.
After the shutdown, Lidl went back to its legacy system from the 1990s. In 2024 it started again, but this time with the small Hamburg agency Freiheit: its own system, its own cloud, no SAP, no large consultancies. The lesson cost half a billion.
The figures the industry would rather ignore
Enough research has been done into the failure of large IT projects to fill a small library. A few numbers stand out for me.
Sources: Standish Group CHAOS Report (50,000+ projects), McKinsey/Oxford (5,400+ projects)
That last figure deserves some context. The McKinsey/Oxford research looked at large IT projects with budgets above $15 million. Nearly one in five turned into a complete disaster: not tens of percent over budget, but hundreds. These are the projects that sometimes threaten the survival of the companies running them.
And then the SAP world in particular. A Horvath study from 2025 of 200 SAP users found that only 8% of S/4HANA migrations stayed on schedule. Eight per cent. More than 60% simultaneously deviated in budget, planning and quality. You would think those results would give anyone pause.
The small-team advantage is no myth
That small teams perform better is not just a feeling or a Silicon Valley cliché. It is one of the most consistently confirmed patterns in software engineering. And the mechanism behind it is actually fairly simple.
A mathematical problem
In 1975, Fred Brooks formulated what is now known as Brooks's Law: "Adding manpower to a late software project makes it later." Fifty years on, nobody has disproved it. The reason is mathematical: n people create n(n-1)/2 communication channels. A team of 5 has 10 interconnections. A team of 50 has 1,225.
That sounds abstract, but in practice it means this: the more people you have, the more time everyone spends aligning rather than building. At some point you spend more time coordinating than doing the actual work. I have seen it happen. Several times.
Not confirmed once, but time and again
QSM analysed 491 software projects and concluded that the optimal team size is 3 to 7 people. The ISBSG database (1,000+ projects) confirms this: teams of 9+ are significantly less productive. Harvard psychologist J. Richard Hackman, after decades of research, arrived at 4 to 6 as the optimal size.
Jeff Bezos's well-known "two-pizza team" rule didn't come out of nowhere. AWS and Amazon Marketplace were built by teams of fewer than 10 people. Not because Bezos dislikes large groups, but because he saw that small teams delivered faster and better work.
A pattern that keeps repeating itself
Lidl is no exception. It is an example from a long, depressing series. What stands out: the script is almost identical every time.
The Elias Parliamentary Committee estimated in 2014 that ICT failures in the Dutch central government cost €1 to €5 billion a year. Every year. The pattern: the A-team pitches, but juniors run the project. Scope grows, deadlines slip, invoices keep coming.
"Despite 20 years of SAP implementations, companies still spend millions and still get it wrong."
Derek Prior, former Gartner SAP analyst
The counterexample is just as instructive. When the $600M+ Healthcare.gov project by CGI Federal crashed at launch, it was a small "tech surge" team of around 20 engineers that stabilised the site within weeks. Not 200 people. Twenty. This led to the creation of the US Digital Service, a permanent acknowledgement that small and good beats large and expensive.
Small teams, big results
While large consultancies watch projects worth hundreds of millions go up in smoke, handfuls of people are building some of the most valuable software companies in the world. That should give us pause for thought.
Cursor
Four MIT students founded Cursor in 2022. In less than a year they went from $1M to $100M in annual revenue, the fastest growth in SaaS history. Valuation at the end of 2025: $29.3 billion. Four people. No steering committee.
Midjourney
No external investors. No marketing budget. Profitable after one month. Estimated revenue between $300 and $500 million, with revenue per employee above $3 million. A figure most companies would not dare dream of.
Bolt.new
A team of around 15 people. From zero to $4M annual revenue in 4 weeks. At its peak, they were adding half a million dollars a day in recurring revenue.
And this pattern is nothing new. Instagram had 13 employees when it was acquired for $1 billion. WhatsApp had 55 when Facebook paid $19 billion. The most impactful software is not built by armies of consultants. It is built by small groups who know what they are doing and are given the room to do it.
Three things to take away
More people means more risk
Every additional team member adds communication complexity. That is not an opinion, it is arithmetic. The reflex to "put more people on it" when things go wrong makes projects slower, not faster. Brooks knew it in 1975. The Standish Group confirms it with 50,000 data points. And yet.
Choose people who stay
A small team of specialists who understand your domain delivers more than 50 consultants who will be on a different project next month. Look for partners who have a stake in the result, not in the number of hours billed.
Deliver something working, quickly
The most successful software projects don't begin with a 200-page requirements document. They begin with a clear problem, a small team, and working software within weeks. Not a presentation about software. Software.
Recognisable?
If you're thinking about a new software project and this story sounds familiar, talk to us. No pitch deck, just a good conversation about what you need.
Get in touch