The full answer
Most delays have identifiable causes: an integration that behaves differently from its documentation, a third-party approval that takes longer than expected, feedback or content arriving late, or scope growing through small additions. Tracking work sprint by sprint makes these visible early.
When a risk appears, we do not hide it until the deadline. The engineering lead raises it in the sprint update or demo with a short explanation of what is affected and what the realistic options are.
Typical options include keeping the date and moving a less important feature to a later release, keeping the scope and adjusting the date, or splitting a milestone so the most valuable part ships first. You choose, with a clear view of the trade-offs.
Any agreed change to the milestone plan is recorded in writing, together with its effect on scope, timeline and payments, so the plan always matches reality.
Prevention matters as much as response. Discovery identifies technical risks up front, risky integrations are tackled early in the build rather than left until the end, and senior engineers make estimates based on products they have shipped before.