Plans decompose work into components, estimate each, and add them up. Integration appears as a short task at the end, if at all. It is regularly the single largest source of overrun, because the work between components belongs to nobody.
Assumptions only meet at the boundary
Two teams implement against the same specification and still disagree about whether a field is optional, what a timestamp's timezone is, how errors are signalled, and what happens on retry. The specification was not wrong; it was silent, and each side filled the silence sensibly.
None of this is visible until the systems are connected, which is why it is discovered late by construction.
Integrate on day one, not at the end
Connect the components while they are stubs that return fixed data. It surfaces the mismatches immediately, when each is a five-minute conversation rather than a fortnight of rework, and it means integration is never a phase.
Write down what the specification leaves out
Timeouts, retry behaviour, idempotency, ordering guarantees, partial failure, and what happens when the other side is unavailable. These are where integrations actually fail in production, and they are almost never in the interface definition.
An hour agreeing them explicitly saves a great deal of debugging later.
Give the boundary an owner
When two teams share an interface, name someone accountable for it. Otherwise every problem at the boundary begins with a discussion about whose problem it is, and that discussion is frequently longer than the fix.
Third parties are slower than you plan
External integrations add sandbox access, credentials, review processes, and support responses measured in days. None of that is technical work and all of it is on the critical path. Start it far earlier than seems necessary.
Estimating components accurately and ignoring the space between them produces a plan that is precisely wrong in a predictable direction.