The short answer
Most overruns trace to something established before the build: an unclear scope, an integration nobody tested, data nobody looked at, or an approval chain nobody mapped. By the time it shows up as a late sprint, the cause is months old.
That is good news, because all four are cheap to check at the start and expensive to discover later.
Cause one: scope that moved
Not scope creep in the blaming sense. Requirements genuinely become clearer once people see software, and a process described in a meeting differs from the one people follow.
The fix is not to freeze scope, which does not work. It is to build in an order that surfaces the disagreements early, and to agree explicitly how changes get handled before the first one arrives.
Cause two: integrations
- An API that is documented but does not behave as documented
- Rate limits that make the intended approach unworkable
- A field the other system does not expose
- Authentication that needs a vendor's help and their timeline
- A sandbox that behaves differently from production
Each of these is discovered by trying, not by reading. Building a throwaway proof against every integration in the first fortnight is the cheapest risk reduction available on any project with integrations in it.
Cause three: the data
Migration estimates made without seeing the data are wrong more often than not. Real data has duplicates, missing fields, values that violate the rules the system supposedly enforced, and history in formats nobody remembers.
Get a real extract early, even a partial one. An afternoon looking at it will change the estimate more than a week of planning.
Cause four: decisions
| Symptom | Underlying cause |
|---|---|
| Work blocked awaiting an answer | No named decision-maker |
| Decisions reversed later | Wrong person decided |
| Approval takes weeks | Chain nobody mapped |
| Conflicting direction | Two stakeholders, no tie-break |
Development waiting on a decision is the most common and least visible source of delay, because it does not look like anyone is behind. Map who decides what before you start.
What to check in the first fortnight
- Prove every integration with a throwaway call against the real system.
- Get a real data extract and look at it.
- Name the decision-maker for each area and confirm their availability.
- Build one end-to-end slice, however thin, and deploy it.
- Agree how scope changes will be handled, in writing.
Two weeks of this removes more risk than any amount of up-front documentation, because it tests assumptions against reality rather than against opinion.