Why Custom Software Projects Fail: They Rarely Die of Code

Custom software projects rarely fail because of code. They fail because of three things that were missing before a single line was written: no observable definition of what "done" means, no one person empowered to decide, and no moment when the wish list stopped growing. When a build collapses, everyone inspects the technology and finds something to blame, but the technical verdict is usually wrong. Research covering 1,471 IT projects found that one in six becomes a runaway, and that shape points at unsteered momentum rather than bad engineering. The good news hiding in that is how cheap the defense is. It costs one meeting held before anyone writes code: name the single owner, write the one sentence that defines success, and open a parking lot where every future idea waits its turn. Then pick a partner whose deal structure makes drift expensive for them, not only for you.

The short version

• The autopsy usually blames the wrong thing. By the time a project visibly fails, the symptoms look technical, but the cause sits upstream of code, in decisions never made.
• One in six is a die roll, not bad luck. Most projects wobble a survivable amount; a sixth of them detonate, which is the fingerprint of no hand on the wheel.
• Absence one is a fuzzy finish line. A project aimed at four soft targets hits none, because nobody can say the moment it is finished.
• Absence two is decision by committee. When no single person can say no, everything defaults to yes, and yes is the most expensive word in a build.
• Absence three is a wish list that never froze. "While we're at it" additions compound like interest and explain overruns that had no single reckless decision.
• The whole defense fits in one meeting, and almost nobody holds it, which means escaping the one-in-six is a matter of steering rather than luck or budget.

Is one in six really just a coin toss?

The scale of the problem has been measured carefully. Bent Flyvbjerg and Alexander Budzier studied 1,471 IT projects in research published by Harvard Business Review, and the headline was almost reassuring: the average cost overrun was a survivable 27 percent. The danger was hiding in the tail. One in six projects became what they called a black swan, running 200 percent over budget on average and nearly 70 percent over schedule.

Read that distribution slowly, because its shape tells you what kind of failure this is. Most projects miss by a manageable margin. A sixth of them do not miss, they explode. That pattern is not what incompetence produces, because incompetence would drag the whole average upward evenly. It is what unsteered momentum produces: most projects keep a hand on the wheel, and the ones that do not simply keep going in whatever direction they were last pointed, spending the entire way. So one in six is not rare and it is not mysterious. It is a die roll, and the difference between the projects that wobble and the ones that detonate keeps reducing to the same three absences, not one of them technical.

Absence one: is there a single outcome that defines success?

Ask everyone involved in a struggling project what "done" means and you will collect a different answer from each mouth. The owner wants invoicing to stop eating two days a month. The operations lead wants the inventory count to finally be trustworthy. The developer is building whatever the last conversation implied. Nobody is wrong, and that is precisely the trouble: a project aimed at four soft targets lands on none of them, and there is never a moment when anyone can declare it finished, because finished was never defined.

The fix costs one sentence, written before the work starts: "This project succeeds if X," where X is observable and singular. "Quotes go out the same day instead of next week." "Month-end closes without the reconciliation spreadsheet." That single sentence then acts as the referee for every later request: does this serve X, or not? A project without the sentence has no referee, so every idea gets waved through and the budget quietly pays for all of them. Writing that sentence in plain language, without technical jargon, is the discipline we walk through in software requirements without the tech jargon, and it is worth more than any specification document.

Absence two: can one person actually say yes or no?

Software is assembled from hundreds of small decisions. Should this field be required? What happens when a customer has two open orders at once? Who is allowed to see cost prices? Each question is minor, but somebody has to answer it, and the answer has to hold.

In the projects that detonate, decisions get made by committee, or by whoever happened to reply to the email, or twice and differently by two people who never compared notes. Every reversed decision throws away the work built on top of it. Worse, when nobody is empowered to say no, everything defaults to yes, and yes is the most expensive word in software. The fix is structural rather than diplomatic: one named person owns the project on the client side. Not the most senior person, the most available one, someone who knows the daily work, can get answers fast, and holds real authority to decide. Others advise; one person decides. When we begin an engagement and cannot get a client to name that person, we treat it as the single strongest predictor of trouble we know, and we say so before taking the work, because no amount of engineering compensates for a project that cannot make up its mind.

Absence three: did the wish list ever freeze?

The most expensive phrase in custom software is "while we're at it." The build is open anyway, so let's also add the export. And the customer portal. And a small dashboard. Each addition sounds marginal, and each one is really a tiny unfunded project smuggled inside yours, carrying its own edge cases, its own testing, and its own maintenance tail. Scope that grows a little every week compounds exactly like interest, and it explains how a project reaches 200 percent over budget without any one decision that felt reckless at the time.

The defense is not to refuse new ideas, because mid-project ideas are often genuinely good; nobody understands the system better than the people watching it take shape. The defense is a parking lot: a written list where every new idea goes, deliberately, to wait for version two. The idea is honored, the scope stays frozen, and version two gets planned on purpose, funded by the results of version one rather than stuffed into its budget. This is the specific failure mode we take apart in how scope creep kills software projects, and the projects that actually ship are not the ones with no new ideas. They are the ones where new ideas have somewhere to wait.

Why do clarity problems look exactly like code problems?

Here is why the technical post-mortem keeps reaching the wrong verdict. By the time an unsteered project visibly fails, the symptoms genuinely are technical: missed dates, bugs, rework, a system that does not match what people pictured. Code problems and clarity problems end up looking identical from the outside. What separates them is their behavior over time. A real code problem gets found and fixed in days, because that is what competent developers do all day long. A clarity problem compounds for months, generating an endless stream of plausible-looking technical churn, because the team is efficiently building the wrong things, rebuilding them each time the target moves, and filing all of it under "development."

So when a build feels stuck, the useful diagnostic is not "is the code bad?" Run this quick check instead, and if any box goes unchecked, no amount of engineering will rescue it:

• Can everyone state the one outcome in the same words, without hedging?
• Can everyone name the one decision-maker, the same person, without a committee attached?
• Is the wish list actually frozen, with a parking lot holding the new ideas rather than the build absorbing them?
• Does each recent change trace back to the outcome, or are things being built because someone mentioned them?
• Are demos showing working software, not status updates about work in progress?

A failing score here is not a reason to change frameworks or developers. It is a reason to stop coding and go fix the steering, because fixing the code fixes nothing while the target is still moving.

How should the deal structure defend you?

The three absences are the client's half of the defense. The other half is how the engagement itself is shaped, because good structure makes drift visible early, while it is still cheap to correct. This is why we run every build as a sequence of small fixed-scope phases instead of one long march. The first phase is deliberately modest: a defined deliverable, a price agreed before any code is written, and a working demonstration at the milestone, software you can click rather than a status report. Payment attaches to delivered milestones, which keeps the incentives honest in both directions, so you are never paying for momentum and we are never coasting on a signed contract. And every phase boundary is a legitimate exit, because you own the code and the data outright at each milestone, so stopping is a real option rather than a threat. When leaving is easy, staying becomes a decision, and projects made of decisions do not drift. The full shape of this is in how we build custom software, step by step, and how the phases map to money is in what custom software costs.

That same structure doubles as your vendor test. Ask any developer you are weighing: what is the first phase, what exactly does it deliver, what does it cost, and what do I own if we stop there? Clear answers mean you are talking to someone who plans to earn phase two. Vague answers, one enormous number, or a contract that only makes sense if you stay forever are the conditions black swans grow in, and the wider set of questions worth asking before you sign is collected in questions to ask before you accept a build quote.

When is the right build no build at all?

The most honest defense of all happens before the project exists, because some builds should never start. If an off-the-shelf tool covers 90 percent of the need, buy it and pocket the difference. If the process you want to automate changes every month, automate it later once it settles, because software freezes a process and freezing wet cement helps no one. And if the one-sentence outcome simply cannot be written, that is not a paperwork failure, it is the project telling you it is not ready to exist yet. We have talked clients out of projects in the first meeting for exactly these reasons. A developer who has never once told you "do not build this" is not advising you, they are selling to you. If the hesitation itself is what you are wrestling with, we wrote about that fear directly in being afraid to build custom software.

Common pitfalls

The pitfalls are not exotic; they are the three absences taking concrete shape, usually more than one at a time. A project starts with genuine enthusiasm and a fuzzy goal, gathers a committee instead of an owner, and welcomes every good idea into the active build, and none of that feels like a mistake in the moment. That is what makes it dangerous. Each individual yes is defensible; only the sum is fatal.

Here is a concrete case, details changed to protect the business. A distributor set out to replace a tangle of spreadsheets with a proper inventory and ordering system, and the ambition was sound. But three things were never settled. "Done" meant different things to the warehouse, the sales team, and the owner, so the target drifted with whoever was in the room. Decisions went to a weekly group call where four people negotiated and often reopened last week's conclusions, so the developer kept rebuilding on ground that shifted underneath. And every call surfaced a reasonable new request, a report here, an integration there, all folded straight into the active scope because refusing felt petty. Six months in, the system did a great deal and finished nothing, the budget had roughly doubled, and everyone blamed the technology. When the project was restarted, no code changed first. One person was named to decide, a single sentence defined the first release, and a parking lot swallowed the rest of the wish list. The same developers shipped a working first phase inside two months. Nothing had been wrong with the engineering; everything had been wrong with the steering, and steering was free to fix.

The one-meeting defense

Strip it all down and the whole protection fits in a meeting held before anyone writes a line. Run it in this order:

1. Name the one owner. Pick the single person on your side who will decide, prioritizing availability and knowledge of the daily work over rank. Write their name down and make it real.
2. Write the one sentence. Define success as one observable, singular outcome, in plain language, and get everyone to agree it is the target.
3. Open the parking lot. Create the written list where every future idea will wait for version two, and agree out loud that the current scope is now frozen.
4. Set the phase structure. Break the work into small phases with a demo and a payment at each boundary, so drift shows up early and stopping stays possible.
5. Choose the partner by the same test. Prefer the developer whose small-phase, paid-milestone, real-exit structure makes drift expensive for them too, not just for you.

That is the entire defense, and the strange, encouraging part is that almost nobody mounts it. Escaping the one-in-six is not a matter of luck or a bigger budget. It is a matter of steering, and steering is the cheapest thing on the whole project. If you are planning a build, or you are inside one that feels like it has lost its wheel, tell me where it stands and you will get a straight read: what the one sentence should be, where the drift is coming from, and whether the honest next step is a first phase, a rescue, or no build at all.

FAQ

Why do most custom software projects fail?

They fail upstream of the code, in decisions that were never made. The runaways almost always share three gaps: no single observable definition of success, no one person with the authority to decide, and no point at which the feature list was frozen. Those absences let a project drift, and drift is what produces the missed dates, rework, and bugs that later get misdiagnosed as technical problems. The pattern in the research, where a minority of projects explode rather than the average creeping up, is the signature of unsteered momentum rather than weak engineering.

What is the single biggest cause of software project failure?

If forced to pick one, it is the absence of a single empowered decision-maker, because it quietly causes the other two failures. Without one person who can say no, scope has nothing to stop it and the definition of done keeps shifting to match whoever spoke last. Decision by committee reverses yesterday's calls, throws away the work built on them, and defaults everything to yes. Naming one available, knowledgeable person with real authority to decide is the highest-leverage move a client can make before any code exists.

How do I stop scope creep from wrecking my project?

Freeze the scope and give new ideas somewhere legitimate to go. Create a parking lot, a written list where every mid-project idea is recorded to wait for version two, so the idea is honored without being smuggled into the current budget. Then plan version two deliberately, funded by the results of version one. The goal is not to reject good ideas, since the best ones often appear once people see the system taking shape; it is to keep the active build fixed so a stream of small, reasonable additions cannot compound into a doubled budget.

Who should be the decision-maker on a software project?

The most available person who knows the daily work and holds real authority to decide, which is frequently not the most senior person in the organization. This owner answers the constant stream of small questions a build generates and makes those answers stick, so the team is never blocked or building on decisions that get reversed. Others can and should advise, but exactly one person decides. If no such person can be named and freed up, that is itself a strong signal the project is not ready to start.

How can I tell if my software project is heading for trouble?

Check the steering, not the code. Ask whether everyone can state the one outcome in the same words, whether everyone names the same single decision-maker, and whether the wish list is genuinely frozen with new ideas parked rather than absorbed. If any of those is shaky, you are looking at a clarity problem, which compounds for months while masquerading as technical churn. A real code defect gets fixed in days; a project that generates endless plausible technical work without ever finishing is showing you a drift problem instead.

Can a great developer rescue a project that lacks these three things?

Not on their own, because the missing pieces are the client's to supply. A skilled developer can build cleanly and fix real bugs quickly, but if the target keeps moving, no one can approve decisions, and scope grows every week, that talent gets spent efficiently building the wrong things. The rescue almost always starts by fixing the steering first: naming an owner, writing the one sentence, and freezing the scope, after which good engineering can finally aim at something that holds still long enough to be finished.