Why software projects take so long, and what actually fixes it

The question is usually asked with a specific frustration behind it. The demo looked close in week six. It is now week twenty and the thing is still not live, and every status update contains the word nearly. Nobody can point to the month it went wrong, because it did not go wrong in a month. It went wrong in twenty small places nobody was watching.

The instinct is to blame the estimate. That is almost always misdirected. Estimates are wrong everywhere, including on projects that ship on time. What separates the two is not forecasting accuracy, it is how quickly the project finds out it is wrong.

Speed of typing has never been the bottleneck

This is worth settling first, because it is where most of the money gets spent. Writing code faster does not, on its own, make projects finish sooner, and there is now large-scale evidence for that rather than just opinion.

The 2025 DORA report, based on survey responses from nearly 5,000 technology professionals along with over 100 hours of qualitative data, found that 90 percent of respondents now use AI at work and more than 80 percent believe it has increased their productivity. On the face of it that should have collapsed delivery timelines.

It has not, and the same research says why. DORA observes a positive relationship between AI adoption and software delivery throughput, while AI adoption "does continue to have a negative relationship with software delivery stability". Code arrives faster and breaks more, so the time saved in writing is spent again in fixing. The report also records that 30 percent of respondents report little or no trust in the code AI generates, which is its own tax: work you do not trust has to be checked.

DORA frames the overall finding as amplification. AI magnifies an organisation's existing strengths and weaknesses rather than replacing them. A team with clear ownership and small releases gets faster. A team without those gets a larger mess sooner.

The four places the months actually go

• Decisions waiting on a person. A question is asked on Tuesday and answered the following Monday. Nothing is blocked in a visible way, so nobody escalates. Six of these is a month.
• Rework from a misunderstanding found late. The feature was built correctly against the wrong assumption. This is the most expensive category and the least visible, because the work looked like progress right up until it was deleted.
• Scope that arrived without a decision. Not a change request. A sentence in a meeting that everyone treated as agreed.
• Work that is finished but not shippable. Done on the developer's machine, sitting behind a release nobody has scheduled, accruing merge conflicts.

Notice that three of the four are communication problems wearing engineering clothes. That is why hiring another developer so often fails to help, and occasionally makes it worse.

Batch size is the variable with the most travel in it

If you change one thing, change how much work goes out at a time. A project that ships something real every week finds its wrong assumptions in week one. A project that integrates everything in month four finds all of them in month four, at once, when the budget is mostly spent.

This is not an argument for rushing. It is an argument for the feedback loop being shorter than the mistake. The cost of a wrong assumption is roughly the time between making it and discovering it, so halving that interval halves the cost of being wrong, and you will be wrong.

The one-week ceiling

The rule we use is simple and slightly uncomfortable: no single piece of work is allowed to be longer than one week without being broken down. If it cannot be broken down, that is the signal, not an exception. It means the work is not understood yet, and the honest next step is a day of investigation rather than three weeks of building.

The ceiling does two things at once. It forces the ambiguity to surface while it is still cheap, and it makes progress legible, because the difference between four things done and one thing nearly done is enormous and only one of them is real.

Ownership means one name

Most delayed projects have a decision that has been open for weeks and belongs to a committee. The fix is unglamorous. Every open question gets one person's name and a date, and if that person is not available at that cadence, they are the wrong owner regardless of seniority.

Where this gets missed most often is at the boundary between the business and the build. The developers are waiting on a rule about pricing or eligibility, the person who knows it is in meetings, and everyone assumes someone else is chasing it. That gap is where the schedule quietly goes.

The honest limit

Some projects genuinely take a long time, and no process removes it. Regulatory work, payment and banking integrations, migrations off a system nobody documented, anything requiring a third party to move at their pace: these have irreducible duration and pretending otherwise produces a missed date rather than an earlier one.

It is also fair to say that a plan of small increments can be run badly. Weekly releases of things nobody asked for is still waste, just faster waste. Short cycles help only when each one is pointed at a real question about whether the thing works.

And there is a category this advice cannot reach: a project with no decision maker. If nobody can say what the product should do when two stakeholders disagree, no amount of engineering discipline fixes the schedule, because the schedule is not the problem.

What to change on Monday

Take the current plan and find every item longer than a week. Break each one down or mark it as investigation. Then take every open question and put a single name and a date against it. That is an afternoon of work and it usually reveals that the project is blocked on four decisions rather than short of developer time.

If the exercise shows the scope was never really agreed, the cheaper move is to go back a step rather than push on, which is the argument in scoping a project before anyone writes code. And if you are trying to work out whether the timeline you have been quoted is plausible in the first place, the ranges in how long it actually takes to build a web app are a more useful benchmark than a supplier's confidence.

There is a parallel worth noting outside software, because the pattern is not unique to it. Sales teams hit the same wall and reach for the same wrong lever, which is more effort rather than a better system. The case is made well in BDG Labs' piece on business development as a system problem rather than an effort problem. Substitute developers for salespeople and the diagnosis is almost word for word the same.

The projects that finish are rarely the ones with the best estimates. They are the ones that were wrong early, cheaply, and in public.