Signal a deadline slip early, before certainty

A checkpoint review with an international client revealed a gap in the requirements document that nobody had caught in the first pass. The feature set was larger than the estimate assumed. The deadline was eight weeks out. I had three paths: wait until I was sure the date would slip, start reshaping the scope now, or signal the risk immediately even though I could not yet name the new date.

The instinct to wait is almost automatic. Certainty feels like the point at which you have something worth saying. You know where the gap is, but you don't yet know whether the team can absorb it through faster execution, whether you can cut a lower-priority piece, or whether some of the discovery work can run in parallel faster than planned. So you keep investigating. You run time estimates. You map dependencies. You gather the facts that will let you tell the client a firm new date.

By the time you have that certainty, it's often three days before the original deadline, and the conversation is no longer about the schedule. It's about why they weren't told.

The moment you first suspect a slip

The early warning signal is almost never a surprise to the people doing the work. A developer will tell you a feature is bigger than estimated. A designer will say the flow needs another revision round. A QA engineer will report a class of bugs that changes the scope of testing. These are all true facts that do not yet add up to a definite miss. They're possibilities. But they're specific possibilities, not guesses, and that matters.

I treated the moment I heard the first one of these signals as the moment to signal the client.

Why the temptation to wait is strong

The desire to be certain before speaking is not weakness. It comes from real things. A client who hears you might miss a date wants to know the new date and whether you can recover it. Saying "we might slip" without a next date feels incomplete. You sound unprepared. The conversation will probably include "well, how long do you need?" and you don't want to guess wrong a second time.

There's also a hope buried in waiting. Maybe the gap will shrink. Maybe you'll find an optimization. Maybe the team will execute faster than expected. Waiting preserves optionality. Speaking now closes the door on the possibility that you won't need to slip at all.

The cost of waiting is that the client loses the information they need to help. If they hear about the risk three weeks out, it's a planning problem. Can they shift their own downstream work? Can they bring in the people they thought they'd deploy somewhere else? Can they reduce the initial scope and catch the rest in a point release? These are conversations that take time and involve other stakeholders. A three-week heads-up makes them possible. Three days makes them impossible.

When the client learns about the slip from noticing it themselves, the entire frame shifts. They don't believe you didn't know. They believe you knew and didn't tell them. The schedule conversation becomes a trust conversation.

What to say when you don't yet know the new date

I called the client the day after the scope gap surfaced. I had been at Exprovia for seventeen months at that point and had run 50+ client onboardings directly in English, enough to know the shape this conversation should take.

I said: "We identified a gap in the requirements that affects the timeline. We found it during checkpoint review, which means we still have time to work through it together. I don't have a revised date yet because I need to run some estimates and see what options we have. Here's what I know happened, here's what we're looking at, and here's when I'll have specific dates for you."

That is the whole message. It is three sentences. The first names the problem and signals that action is already happening. The second explains why waiting to speak was not the right call. The third sets a time when the client will hear again, which usually kills the anxiety that comes from uncertainty.

I had the revised dates and three options for how to proceed within four business days. The client chose one. We executed to the new date. The conversation stayed on the schedule because the client had time to think, to consult their own stakeholders, and to plan.

When the client finds out themselves

I saw the opposite happen on a different program. The team discovered a similar gap about six weeks before the deadline. The technical lead estimated the work but didn't escalate to the project manager. The project manager had the slack in their own tracking and didn't escalate to the client. By the time the client asked "will we hit the date?" in a steering committee meeting, it was three weeks before go-live and the answer was no.

The client's response was immediate. They wanted to know why they hadn't been told sooner. They wanted to review the gap themselves and the estimates. They wanted proof that the delay was necessary. The conversation that had been a scheduling problem became an audit, and the relationship moved from planning together to defending a decision.

The client still hit their own downstream deadline, but by making a choice they wouldn't have made if they'd had more time. They absorbed the impact on their side instead of reshaping the work, because there was no time to reshape anything. The team felt blamed. The client felt ambushed. The work got done, but the collaboration had broken.

The rule that follows

Signal a deadline slip the moment you have specific information suggesting it might happen, not the moment you can prove it will. The client who hears about it early enough to help treats the news as data to plan around. The same client who hears it too late treats it as a failure that was hidden. The difference between these conversations is measured in days, and those days are your responsibility to claim.

You will not have the revised date when you make the call. You will have the gap, the estimate, and a commitment to specific timing for the revised number. That is enough to say.