Why software projects run late, and how we plan against it
Late software is the norm and the causes repeat. Six reasons, the planning habit that counters each, and what a realistic schedule contains.
The short answer
Software projects run late so reliably that lateness is the norm and an on-time delivery is the story people tell. The causes are not mysterious; they repeat. Scope that was never written down precisely. Complexity discovered inside an integration or a data migration that looked simple. Waiting on decisions, content and access from the client side. Estimates made with optimism when the least was known. Changes requested mid-build. And schedules with no slack, so the first surprise becomes the first delay. Each cause has a planning habit that counters it, and a realistic schedule shows the client’s dependencies as explicitly as the builder’s work.
The six causes and their counters
| Cause | What it looks like | Planning counter |
|---|---|---|
| Unclear scope | ”We assumed that was included” in month two | Written scope with a not-included list, signed before build |
| Discovered complexity | The accounting integration has an API that does half of what was promised | Technical spikes on every risky piece before the price and date are fixed |
| Waiting on the client | Content in month three, a decision after the next board meeting, system access after a fortnight of emails | A decision and content calendar with the client’s names and dates, tracked like tasks |
| Optimistic estimates | Points instead of ranges, made in the sales phase | Ranges, re-estimated at each stage; the date committed after spikes |
| Mid-build changes | Good ideas that arrive once people see something real | A change process: priced, scheduled, traded against scope or date |
| No slack | Any surprise becomes a delay | Buffer per stage; the planned date is one you would bet on |
How we plan
- Discovery first, producing a written scope with what is in and what is out, and the list of risks.
- Spikes on every risk before the price and the schedule are fixed.
- Stages with a working release at the end of each: the most valuable slice first, usable on its own.
- A client calendar alongside the build plan: decisions, content, access, approvals, with names and dates.
- Ranges that narrow: an estimate at discovery, tightened after spikes, committed per stage.
- Buffer in each stage, visible, not hidden in the tasks.
- A change process that prices and schedules every change and shows what it displaces.
What a realistic schedule contains
Stages with dates and what each delivers. The client’s dependencies with names and dates. The risks and the spikes that retired them. Buffer, shown. The change process and how it moves dates. A first working release early enough that the business gets value even if later stages slip. That schedule is longer on paper than the optimistic one and shorter in reality, which is the only comparison that matters.
What this means for you
Expect a plan with stages, spikes, a client calendar, ranges that narrow and visible buffer. Do your part on the calendar: decisions, content and access on the dates named. Use the change process rather than the corridor for new ideas. Projects planned this way still meet surprises; they meet them early, at stage boundaries, with the useful part already shipped, which is what on time looks like in software.
Frequently asked questions
Why do estimates always seem too optimistic?
Because they are made when the least is known, by people imagining the work going well, for a scope that will grow. Countering it is procedural: estimate in ranges, spike the risky parts before committing, add explicit buffer, and re-estimate at each stage with what was learned. An estimate revised at stage boundaries is honest; one defended from day one is a hope.
How much lateness is caused by the client?
More than clients expect and less than builders claim. Content that arrives late, decisions that wait for a meeting, access to systems that takes weeks, a stakeholder who appears in month three: these are real and common. A plan that names them as client dependencies with dates makes them visible and shared rather than a surprise at the end.
What is a realistic buffer?
Enough that the planned date is one you would bet on, not one you hope for. For a well-scoped project with spikes done, a modest buffer at each stage covers the ordinary surprises. For a project with unknown integrations or unclear scope, no buffer is enough and the fix is to reduce the unknowns before committing to a date.