Why your software project is late (and it's almost never the devs' fault)

Everyone has lived through this: the project that was going to take three months turns into six. Every week, the same question in the meeting — "why isn't it done yet?" — and the same answer hanging in the air: the developers are slow. It's the easiest explanation. And it is, almost always, the wrong one.

Because when you open up a late project and really look, the cause is rarely the speed of whoever is typing. It's a decision made way back, before the first line of code — a method choice that scheduled the delay without anyone noticing. Here are the six that show up most often.

01The scope nobody sized

"We'll figure it out as we go." Said at the start, that sentence is a delay agreed upon before the work begins. A project with no understanding of the problem doesn't have a deadline — it has a guess. And a guess, once it becomes a calendar commitment, always slips.

Discovering while you build means reworking what's already done every time a new truth surfaces. And it always surfaces: the integration nobody mapped, the business rule only the operations manager knew, the edge case that breaks everything. The antidote isn't guessing better — it's discovery before code. Understand the process, the integrations and where it really hurts, and only then commit to a deadline that holds. A deadline without discovery is a guess; we only promise what we've sized.

02Rewriting everything at once

The big bang is seductive: throw out the old system, deliver the new one whole, flip the switch on a Sunday night. It looks bold. It's just risky. The bigger the single cutover, the bigger the surface for error — and the bigger the chance the date slips and takes the operation down with it.

Large systems don't have a clean "end"; they have a thousand details that only show up when real users touch them. Doing it all at once concentrates every risk at the worst possible moment: launch day. The alternative is incremental migration — each new module is born alongside the old one and takes over traffic gradually, with production live the whole time. Risk becomes a series of small, reversible steps instead of a leap in the dark.

03Rebuilding the foundation from scratch

Every serious application needs the same things underneath: login and permissions, payments, continuous integration, monitoring, a component library. None of that is your business problem — it's plumbing. And yet many projects spend their first weeks rebuilding that plumbing from scratch, as if nobody in the world had ever solved authentication before.

Each of those weeks is a delivery that doesn't ship. The way out is not starting from zero: a proprietary platform that already comes with the foundation ready frees the team to focus on what's truly yours — the business rule, the screen that creates value. You don't pay again for plumbing that already exists.

04Integration (and decisions) left for the end

Two classics that travel together. The first: "we'll integrate later." The ERP, the SSO, the legacy system get pushed to the final stretch — and that's exactly where everything stalls, because integration is where assumptions meet reality. What's left for the end becomes the bottleneck at the end.

The second: the decision stuck in email. Every approval takes days because it passes through layers of management relaying messages. The project doesn't stop working — it stops to wait. The cure is both technical and human: integration and CI/CD from day 1 (ship to production early, integrate early, find the problem early) and direct access to whoever decides and whoever writes the code, with no game of telephone in between.

05The "almost done" that never closes

Perhaps the cruelest one. Without a working delivery early on, nobody knows where the project really stands — and the "90% done" drags on for months, because the last 10% hides the work nobody saw. Progress becomes a bar that never reaches the end.

The defense against this is rhythm: frequent working deliveries, starting with the first one in two weeks. Not a demo screen — something that actually runs, in production. When you see the product working every short cycle, "where we are" stops being an opinion and becomes an observable fact. And a project you can see is a project that doesn't surprise you at the end.

06Delay is a method choice

Notice what none of these six causes is: "the devs are slow." Every one of them is a decision about how the project is run — and every one has a well-known opposite. Discovery before code. Incremental migration. A ready-made foundation. Integration and CI/CD on day 1. Direct access. Short, frequent deliveries.

That's why we sum up our own way of working in three words: weeks, not months. Not because we cut corners — but because at each of these six points we choose the method that doesn't produce delay. And if the first sprint still doesn't convince you, it's risk-free: 100% of your investment back.