Nobody sets out to be late. Projects overrun for reasons that were present at the beginning, invisible for a while, and obvious in hindsight — and the moment the delay becomes visible is usually months after the decision that caused it.
That gap is the whole difficulty. By the time a project is behind, the useful conversation is about a decision taken in week three, and everyone is instead discussing the schedule. So this article is organised by mechanism rather than by symptom: six things that actually cause overrun, what each one looks like early, and what can be done about it before it becomes a date.
Two notes on framing. First, some overrun is not failure. A project that discovers in month two that it was solving the wrong problem, changes course, and lands late has done better than one that delivered the original plan on time. Second, none of this is unusual. These six mechanisms account for most of what goes wrong, and none of them requires anyone to be incompetent.
One — scope discovered rather than defined
The most common cause by a distance. The project was estimated against what everybody knew about the process, and the process contains things nobody had written down.
The exception found in month three: the customer type that is billed differently, the approval that only applies over a certain value, the branch that has always done it another way. Each is small. Each also arrives after the data model, the permissions and half the screens assume it does not exist.
Early signs. Estimates given without anyone examining the current process. A brief with no volumes in it. The phrase "it's basically the same as" applied to two things that differ in one important respect. Discovering, in the first fortnight of building, a rule nobody mentioned.
What reduces it. Tracing real cases before estimating, and specifically looking for exceptions rather than waiting for them. A useful question to ask everyone who touches the process: when do you not do it this way? The answers arrive quickly and they are almost never in the brief.
Two — the integration nobody examined
A single line in a document, integrate with the accounting system, that turns out to be a project.
The reasons are consistent. The other system has no documented interface. The vendor charges for access, and procurement takes six weeks. The interface exists but does not expose the one field you need. Data flows both ways, so someone must decide what happens when the two systems disagree. Or the other system is a version several releases behind the one the documentation describes.
Early signs. Nobody has looked at the actual interface documentation. Nobody has tested credentials. The plan says "integration" without naming which fields move in which direction. The other system's supplier has not been contacted.
What reduces it. Prove the connection early, with a small piece of throwaway code that moves one real record. Do that in the first fortnight, not in month four. It is the cheapest risk reduction available on most projects, and it is skipped constantly because it produces nothing demonstrable.
Three — decisions waiting
The most under-discussed cause, and the one that sits on the client's side of the table.
Development runs on answers. When a question goes unanswered, work either stops or proceeds on a guess. Which of these two behaviours is correct. Who is allowed to see this. Is the discount applied before or after tax. Stopping costs time directly. Guessing costs more, later, when the guess turns out wrong and everything built on it needs revisiting.
Early signs. No named decision-maker. Decisions requiring a committee that meets monthly. A client team who are all doing this alongside their actual jobs, with nobody's time formally allocated. Questions taking more than a few days to come back.
What reduces it. One named person who can decide, or say no, within a couple of days. A weekly slot in the calendar for open questions rather than a chain of emails. And a standing rule that unanswered questions get a documented default so work continues — the default is visible and can be revisited, which is much cheaper than a silent guess.
Four — the wrong thing, built well
The most expensive failure, and the only one that does not look like failure while it is happening. The project delivers what was asked for, on time, working. It changes nothing, because what was asked for did not address the underlying problem.
Nobody can point at a bug. The software is used briefly and then worked around, the old process quietly reasserts itself, and the money is gone with no visible defect to blame.
Early signs. A brief that names a solution rather than a problem. No statement of what will be true afterwards. Users who were not consulted before the build. The absence of anyone able to explain, in a sentence, what changes in the business when this exists.
What reduces it. A written success statement agreed before the build, specific enough to be judged a year later, and used to test every proposed feature. Then getting something in front of real users as early as possible — not a demonstration, but the actual thing, used for real work, while there is still budget to respond to what you learn.
Five — the states nobody counted
The project was scoped as a list of features and priced accordingly. It is built as a set of situations, and there are far more of them than the feature list implied.
Order management is one line. Underneath it sit ten states, each needing a screen, a rule about who can move it to the next state, and behaviour when something fails halfway. This is a mechanism, not carelessness: feature lists systematically undercount, because a feature is a headline and the work is what is beneath it.
Early signs. An estimate built from a feature list with no state diagram anywhere. No agreement on what happens to an order after payment, or a booking after cancellation. Testing that only covers the path where everything goes well.
What reduces it. Write out the lifecycle of your two or three most important objects before anyone estimates. It takes an afternoon and it is the single most accurate predictor of size available to either side.
Six — quality deferred
Not a cause of the first delay, but the reason small delays compound into large ones.
A project falls behind. Something is dropped to catch up: tests, tidy-up, the difficult states, documentation. That works for a fortnight. Then every subsequent change takes longer, because each one now risks breaking something nobody is checking. The pace declines, more is deferred, and the project enters the phase where it is always nearly finished.
Early signs. "We'll come back to that." A growing list of known issues nobody is scheduling. Fixes that produce new problems elsewhere. Nobody able to say confidently what still works.
What reduces it. When a project is behind, cut scope rather than quality. A smaller thing that is solid can be extended. A larger thing that is fragile gets slower for the rest of its life, and the interest is charged every month.
A summary of the mechanisms
| Mechanism | Shows up as | Cheapest prevention |
|---|---|---|
| Scope discovered, not defined | Exceptions appearing in month three | Trace real cases and ask "when do you not do it this way?" |
| The unexamined integration | One line becoming a project | Move one real record in the first fortnight |
| Decisions waiting | Progress stalling with no visible reason | One named decider, a weekly slot, documented defaults |
| The wrong thing, built well | Delivered on time, changes nothing | A success statement agreed before the build |
| Uncounted states | Everything taking longer than the feature suggested | Write the lifecycle of your key objects before estimating |
| Quality deferred | Always nearly finished | Cut scope, not quality, when behind |
What to do when you are already overrunning
Different problem, and the instinct is usually wrong. Pressing harder on the date rarely moves it.
Find out which mechanism you are in. The response differs completely. Waiting decisions are fixed in a week by naming someone. Discovered scope means the plan was wrong and needs rebuilding, not compressing.
Re-plan from where you are, once. A schedule everyone privately knows is impossible stops functioning as a schedule, and reporting against it becomes theatre. One honest re-plan is worth more than three optimistic revisions.
Cut, and cut structurally. Not five per cent from every area, which slows everything and finishes nothing. Remove whole capabilities, whole roles, whole states. Find what must be true for the first release to be genuinely useful, and defer the rest without embarrassment.
Do not add people to a late project expecting it to speed up. New people need context from the people who currently have it, which slows the ones already producing. This has been understood in software management for fifty years and remains the most frequently repeated mistake in the field.
Get something in front of real users, even if it is small. A late project with one part live is in a much better position than a late project with nothing live, both for morale and for the information it produces.
Common questions
Is it always the client's fault or the supplier's? It is usually neither, and the two most common mechanisms sit on opposite sides. Discovered scope is nobody's fault in particular; waiting decisions sit with the client; deferred quality sits with the supplier. A project that assigns blame before diagnosing the mechanism tends to acquire a second problem.
How much contingency should a plan carry? More for work that is new to the team and less for work they have done many times, which is a more useful rule than any percentage. A better protection than contingency is a scope that can be reduced without the project failing, which means knowing in advance which parts are essential.
Should we change supplier? Rarely helpful mid-project, because a new supplier begins by understanding what exists, which is expensive. It is justified when the relationship has stopped being honest, when work is going backwards, or when the supplier cannot explain what state the system is in. Before deciding, check whether you can get a full handover: code, accounts, data, documentation. If you cannot, that is itself the most urgent problem.
Do fixed-price contracts prevent this? They move who pays for it, and change what overrun looks like: instead of a larger invoice you get change requests, narrow readings of the specification, and pressure to accept less. The mechanisms are the same. How software work is priced covers the trade-offs.
The short version
- Overrun is a symptom. Six mechanisms cause most of it, and each has a different fix.
- Undocumented exceptions in your process are the most common cause. Ask people when they do not follow the usual route.
- Prove every integration in the first fortnight by moving one real record. It is the cheapest risk reduction available.
- Waiting decisions are the client's contribution. One named decider and a weekly slot removes most of it.
- The most expensive outcome is the wrong thing built well, and only an agreed success statement catches it early.
- When behind, cut scope rather than quality, re-plan honestly once, and do not add people expecting speed.
Where to take this next
Most of the prevention in this article happens before anyone writes code. What to work out before you ask anyone to build software is that groundwork, and what drives the cost of custom software explains why the mechanisms above translate so directly into money.
If a project of yours is in one of these six positions now, describing it is usually enough for someone outside it to tell you which one. Discuss your idea, or say hi on WhatsApp.
# Visual recommendations
Concepts only. Hairline drawing, ink and brass.
Hero visual — the gap between cause and symptom
Concept. A horizontal project timeline. Six small brass marks sit in the first third, each labelled with a mechanism. A single large ink mark sits in the final third labelled the delay becomes visible. Thin curved lines connect each early mark to the late one, so the reader sees six causes converging on one symptom months later.
Purpose. Establishes the article's organising idea: the useful conversation is about a decision taken long before the date slipped.
Alt text. Six causes marked early in a project timeline, each connected by a line to a single point much later where the delay finally becomes visible.
Supporting visual — cut scope, not quality
Concept. Two versions of the same project drawn as grids of small blocks. Left, cut quality: the full grid, with every block drawn in a broken hairline to show fragility, and an arrow beneath labelled slower every month after. Right, cut scope: two-thirds of the grid removed, the remainder drawn solid, with an arrow labelled extends cleanly.
Purpose. Carries the single most actionable recommendation in the article, and the one people most often get backwards under pressure.
Placement. In the "what to do when you are already overrunning" section.
Alt text. A full project built fragile becomes slower every month, while a smaller project built solidly can be extended cleanly.