Why Do Projects Run Late? An Autopsy of Schedule Overruns

After years of running projects, let's admit it up front: we've been late too. So this isn't a vendor deflecting blame — it's an autopsy report. We're cutting open the corpse of a delayed project to see what's actually inside. Conclusion first: delays are rarely caused by "engineers coding too slowly" — most are eaten alive by the waiting and rework baked into the process.

The four real causes of delay

1. Scope changes (the biggest one)

"Just add this while you're at it." "This tweak should be quick, right?" Each small change is reasonable on its own; added together they're death by a thousand cuts to the schedule. More insidious is "I only knew what I wanted when I saw the finished thing" — items nodded through at the spec stage get torn up and redone once built. This isn't about good or bad actors; it's human nature. But without a change-management mechanism to catch it, human nature rolls right over the timeline. This topic deserves its own article — we wrote it in how to handle scope changes.

2. Waiting: assets, content, credentials

Here's a fact every vendor knows and no client believes: the longest-stuck stage of a project is often waiting for the client to deliver things. Product photos, company copy, payment gateway application documents, domain access — things only the client can provide. Every week they're late, launch slips a week. And it compounds: our staffing is scheduled like a relay, so your gap collides with our next project's slot, and a one-week delay snowballs into three.

3. Decision gridlock

The design mockups go out and two weeks pass in silence. Or worse: three mutually contradictory opinions come back and nobody makes the call. Every "pending confirmation" in a project is a button that stops time. We now ask before every contract: who is the single decision-making contact? A project with no answer to that question has a schedule that's purely decorative.

4. Third-party surprises

Payment gateway review takes longer than expected, the platform rejects the submission, the external API's documentation doesn't match reality. This risk can't be zeroed out — only front-loaded: submit every third-party application in week one, never the moment before you need it.

A project schedule isn't destroyed by one big disaster. It bleeds out through a dozen "small things — just a moment" cuts.

Our prevention mechanisms

Autopsy done — now the prescription. What we do today: ship an operable version every two weeks, so "built the wrong thing" is caught within two weeks instead of three months later (the details of this cadence are in this article); hand the client a delivery checklist on day one — assets, credentials, documents, each with a hard deadline and an honest note on what happens if it's late; set response deadlines on feedback — for example, design mockups get seven days, after which comments roll into the next round; and estimate waiting and rework into the schedule — a timeline that only counts engineering hours is fiction from day one.

One more thing matters as much as prevention: how you handle a delay when it actually happens. Our principles are speak early, speak the truth, offer options — flag schedule risk the moment we see it rather than on deadline day; explain the real cause without spinning a story; and present the trade-offs: push the launch date, or cut part of the scope and ship the core on time. Most clients can accept a delay. What they can't accept is being kept in the dark until the last moment. A slipped schedule doesn't necessarily kill a partnership — lost credibility does.

Finally, an honest tip for clients: when choosing a vendor, swap "will you run late?" for "have you ever run late? How did you handle it?" The first question only gets you promises; the second gets you the truth. A team that never admits to a delay and a team that guarantees zero delays are the same team.