Why enterprise software projects run late (and the planning habit that fixes most of it)
Late software projects aren't an engineering failure — they're an estimating failure. The predictable places schedules slip, and how to plan for reality instead of hope.
Ask why the project is late and you’ll hear specifics: the integration was harder than expected, a key person left, requirements changed in month three. All true, and all beside the point — because some version of those things happens on every project. The schedule wasn’t wrong because of surprises. It was wrong because it assumed there wouldn’t be any.
After enough years of consulting-side delivery, you notice the slips cluster in the same few places. None of them are exotic.
Where the time actually goes
The estimate was for typing, not for building. Teams estimate the happy path: the feature, coded. Real delivery includes testing, code review, bug-fixing, deployment plumbing, documentation, and the meetings to align on all of it. If the plan books 100% of everyone’s hours against features, the schedule was fiction before day one.
Integrations with other people’s systems. The single most reliable source of slippage in enterprise work. The vendor API’s documentation is wrong, the sandbox doesn’t match production, the other team’s change window is next quarter. Any line item that depends on an external system deserves double the estimate and an early start — test the connection in week one, not week twenty.
Decisions that wait. The team is blocked for four days waiting on a stakeholder to pick option A or B. Multiply by twenty decisions across a project and you’ve silently lost a month. Slow decisions are invisible in status reports — the team is always “working” — but they’re often the largest hidden line item.
The last 10% that’s actually 30%. “Feature-complete” and “done” are separated by edge cases, performance under real data, security review, UAT feedback, and migration of the old data — which is always dirtier than anyone believed. Every experienced engineer knows this tail exists; almost no schedule contains it.
The habit that fixes most of it: plan from evidence, not intention
The single most effective change is boring: measure how long your last projects actually took versus their estimates, and apply that ratio forward. If your organization historically delivers in 1.6× the estimate, then a new project’s honest schedule is its estimate times 1.6 — regardless of how much better everyone intends to do this time. Optimism is not a delivery strategy; your own track record is data.
Alongside that, three supporting habits:
- Front-load the risky bits. Do the scary integration, the data migration dry-run, and the performance test on real volumes in the first weeks, when there’s still time to react. Late projects usually saved the hard parts for the end, exactly when there was no slack left.
- Cut scope, not corners, when the date is fixed. A fixed date with fixed scope means quality is the variable — and quality debt comes back with interest. Rank features honestly and let the bottom of the list slide to a phase two.
- Track decisions like blockers. Put stakeholder decisions in the plan with owners and due dates, and chase them like you’d chase a failing server. It feels bureaucratic. It’s the cheapest schedule recovery available.
The uncomfortable summary
Projects don’t run late where the work is hard. They run late where the plan was dishonest — about overhead, about integration risk, about the tail, about how long the organization takes to decide things. Fix the honesty and the same team, doing the same work, starts hitting its dates. We’ve watched it happen often enough to promise it’s not luck.