When a project runs to twice its estimate, the cause is rarely slow engineering. It is work that existed from the start and was never discussed — integrations nobody mentioned, data migration nobody scoped, approvals nobody knew about.
Estimate journeys, not features
A feature list invites everyone to imagine a different scope behind each line. Complete user journeys — from the trigger through every branch to the outcome — expose the states, permissions and failure paths that a feature list hides. Most overrun lives in those branches.
Feature lists hide the work. Journeys expose it, including the branches nobody mentioned.
The four questions that find hidden work
What existing systems must this talk to, and can we see their documentation? What historical data must move, and what condition is it in? Who must approve before launch, and what will they require? What must be true for this to be legal in your sector? Each routinely uncovers weeks nobody had counted.
Integrations are the classic underestimate
'It has an API' says nothing about rate limits, sandbox availability, authentication complexity, data quality or the vendor's support responsiveness. Budget for the integration being harder than documented, because it usually is — and ask for sandbox access before quoting, not after.
Estimate in ranges with named assumptions
A single number implies a precision nobody has. A range with the assumptions written down — 'assuming their sandbox is available in week one, assuming under 50,000 records to migrate' — makes the uncertainty explicit and gives both sides a shared basis when an assumption turns out to be wrong.
Sequence by risk, not by comfort
Building the easy parts first produces visible progress and defers the discovery that the hard integration is infeasible. Tackle the riskiest unknown in the first fortnight, so that if the project needs to change shape, it changes while there is budget left to change it.
Agree how change gets handled
Requirements will change; the question is only whether that is a process or an argument. A lightweight change procedure — impact stated in time and cost, decided before work begins — keeps scope creep visible rather than absorbed silently until the deadline slips.
