The same software project failure patterns repeat from one build to the next, and they have very little to do with the choice of language or framework. Most projects fail because the requirements were misunderstood, because the scope grew without anyone putting a price on it, or because nobody owned the technical outcome. I've lived in Vietnam since 2014 and run a team of senior developers here, and I keep seeing the same scenarios with very different clients. Here's what the numbers say, followed by the four patterns I try to catch as early as possible.
- 📊 Historical figures: only 16.2% of projects come in on budget and on time, according to the Chaos Report.
- ⚠️ Fuzzy scoping: misunderstood requirements wreck more projects than technology does.
- 🏗️ Code with no owner: AI produces fast, but nobody is accountable for the architecture.
- 🎯 My take: a closely managed senior team lowers the risk, offshore included.
What the numbers say about software project failure
The Chaos Report is the Standish Group's annual study, published since 1994 and based on more than 50,000 projects according to bestofbusinessanalyst.fr. It sorts projects into three categories: successful, challenged (delivered late or over budget) and failed (cancelled before deployment). In the historical figures it reports, 16.2% of projects come in on budget and on time, 52.7% overrun, and 31.1% are abandoned along the way.
What share of software projects really fail?
Challenged projects cost on average 189% of their original estimate, according to orgatypik.com, which draws on the same report. A 2015 update from the Standish Group, cited by bestofbusinessanalyst.fr and reussirsesprojets.com, puts the overall failure rate at 71%, with the improvement attributed largely to wider use of agile approaches. At the enterprise level, McKinsey warned back in 2020 that 17% of large IT projects go so badly wrong they threaten the very existence of the company, again according to orgatypik.com.
These figures are dated, and their definition of failure is strict: software delivered 20% late but used every day still counts as "challenged". I read them as an order of magnitude, not as a probability for your project.
The problem isn't that projects fail. It's that they always fail the same way.
| Measure | Result | What it means | Cited source |
|---|---|---|---|
| Successful projects | 16.2% | On budget and on time | Chaos Report (via bestofbusinessanalyst.fr) |
| Challenged projects | 52.7% | Average cost overrun of 189% | Chaos Report (via orgatypik.com) |
| Failed projects | 31.1% | Cancelled before deployment | Chaos Report (via bestofbusinessanalyst.fr) |
| Overall failure rate, 2015 edition | 71% | Improvement attributed to agile | Standish Group (via reussirsesprojets.com) |
| Large IT projects that threaten survival | 17% | Put the company's existence at risk | McKinsey, 2020 (via orgatypik.com) |
SOURCE: Standish Group Chaos Report, McKinsey, via the pages cited · UPDATED 11/2026
Should you trust the study that blames agile?
A study reported by agile.developpez.com in June 2024, based on a survey of 600 British and American engineers, claims that projects using agile requirements engineering practices are 268% more likely to fail. According to the study, 65% of those projects aren't delivered on time, on budget and to the expected quality, compared with 10% for projects following a method called "impact engineering".
I draw a very different conclusion. The study was produced for a book, Impact Engineering, which sells precisely the winning method: the conflict of interest is built into the source. More importantly, what it measures looks like a problem of poorly defined requirements rather than a flaw in agile itself, which brings us to the next pattern.
Patterns 1 and 2: misunderstood requirements and scope creep
The first software project failure pattern is a misread requirement. The second is scope that keeps expanding while the budget stays put. The two are linked: a vague specification lets each side understand something different, then demand or bill for the difference.
Why are vague requirements so expensive?
The guide on reussirsesprojets.com puts "misinterpreted requirements" at the top of its 33 causes of failure. Its example is deliberately exaggerated: you're asked to go to Paris, you head for France, and the client meant Paris, Texas. Every week of development then builds on an assumption nobody has checked.
A senior developer doesn't guess: they ask questions as soon as something is ambiguous, rather than filling in the gaps themselves. That's what I expect from every developer I place, and it's also what separates a usable quote from an optimistic budget line. My article on a mobile app quote annotated line by line shows what a scope looks like when it's precise enough to be challenged before the first commit.
How do you catch scope creep before it costs 189%?
Scope creep shows up in deliverables, not in meetings. Three warning signs come up again and again: no visible demo for two weeks, extra requests accepted "because it's small" without being costed, and a backlog where nobody can say what the priority is.
My antidote comes down to one habit: start with a 5-day batch, measure actual speed and quality, then project the rest from data rather than promises. The client stays in control of priorities, and the team costs each addition as it comes in.
Pattern 3: code shipped fast, but with no technical owner
The third pattern is a recent one: a product generated quickly with AI, with no engineer accountable for it. Vibe coding means generating code with an AI assistant and judging the result by eye rather than actually reviewing it. It's useful for prototyping and dangerous for building a serious product without technical oversight.
Why does vibe coding sink serious projects?
A non-engineer can get snippets of code that run. They won't necessarily know how to handle architecture, security, maintenance, bugs and edge cases, and those are exactly what kill a product by its third release. A product generated without technical oversight costs far more to fix than it would have cost to build properly from the start.
I think a lot of companies are going to lose money believing AI is enough. They'll still need real technical ownership, meaning someone who can say "no, that architecture choice won't hold up". I've covered where that line falls in vibe coding and offshore developers.
When does AI actually reduce the risk of failure?
When it's in the hands of an engineer. A developer working with Claude Code or Cursor is still an engineer, not a prompt operator: they keep ownership of testing, code review and architecture decisions, and AI multiplies their output. A good developer becomes more productive, a bad developer becomes more dangerous, and the gap widens.
That's why headcount matters less than it used to. What changes a project's outcome is the team's ability to use AI intelligently, under clear technical ownership. For a closer look at how that works, see how developers use Claude Code.
Pattern 4: offshore projects fail through misunderstandings, not skill gaps
An offshore project rarely fails because the developers aren't good enough. It fails because the requirements get lost between the French client and the remote team. The technical talent available in Vietnam is more than enough to build SaaS products, mobile apps and serious business platforms, and I think many European companies still underestimate the country.
How does an offshore project typically go off the rails?
The scenario is familiar: the client describes what they need in a few lines, the team delivers what it understood, and the gap only surfaces at acceptance testing. It comes from technical, cultural and organisational misunderstandings that nobody took ownership of. Without a point person who speaks both languages of the project, every ambiguity stays unresolved.
That's exactly the role I play: bridging the gap between what French clients need and what the Vietnamese team can deliver. If you're evaluating a provider, the checklist of what to verify with an IT provider in Vietnam and the article on the French-speaking point person in offshore projects give you the questions to ask.
When is offshore not the right answer?
If you have neither a specification nor anyone on the client side who can settle priorities, offshoring will amplify the vagueness instead of fixing it. The same goes if the project needs someone physically on site every day. In those cases, proper scoping first, or a smaller local team, beats moving fast.
My verdict: what really reduces the risk of failure
Software projects fail along four recurring patterns, and each one is visible before the end of the first month: vague requirements, uncosted scope, code with no technical owner, and no bridge between client and team. Three things reduce the risk: requirements written down and challenged before the first commit, something visible delivered every week, and a senior engineer accountable for the result.
What should you check before signing?
Before kicking off a project, I check four things, with the client and with the team alike:
- The requirements are written down, reviewed by two people, and every ambiguous area has an open question attached.
- A short first batch (5 days) measures speed and quality before committing to the rest.
- A named person is accountable for architecture, testing and security, even when AI writes part of the code.
- Code, access and documentation sit in the client's accounts from day one, so they're free to speed up, slow down or bring the work in-house.
I don't just sell development time: my clients pay for the ability to turn an idea into software people can actually use. If you'd like to see what that model looks like in practice, you can hire a senior developer in Vietnam, with profiles within 48 hours and a start in under 7 days.
Frequently asked questions
What is the failure rate of software projects?
According to the Standish Group's Chaos Report, as reported by bestofbusinessanalyst.fr, 16.2% of projects come in on budget and on time, 52.7% overrun and 31.1% are cancelled. A 2015 edition puts the overall failure rate at 71%. These figures use a strict definition of failure and should be read as an order of magnitude.
Why do IT projects go over budget?
The most common causes are requirements misread at the outset and scope that grows without being re-costed. According to orgatypik.com, challenged projects in the Chaos Report cost on average 189% of their estimate. Costing every addition and delivering a visible demo every week keeps that drift in check.
Does agile cause software projects to fail?
No, not on the available evidence. A 2024 study of 600 engineers claims agile practices multiply the risk of failure, but it was produced for a book promoting a competing method. The underlying problem is usually poorly defined requirements, whatever the management method.
Is vibe coding risky for a product in production?
Yes, if there's no engineer to review and structure the code. Vibe coding is fine for prototyping, but architecture, security, maintenance and edge cases require technical oversight. A product generated without that oversight usually costs more to fix than to build properly in the first place.
Does offshoring increase the risk of project failure?
Not because of the teams' technical skills, but it does shift the risk towards communication. Without a point person who understands the client's needs and translates them for the team, misunderstandings pile up until acceptance testing. With a clear specification and a short first batch to measure quality, offshoring to Vietnam remains a solid choice.
