Name the changed expectation
Say which milestone is affected and what you currently expect. “We have encountered some complexity” leaves the listener guessing about impact. “The integration is now likely to finish next week rather than Friday” gives them a useful starting point.
Distinguish a confirmed delay from a risk. If the remaining work is still being investigated, explain the range or dependency instead of selecting a precise date for comfort. State when you expect to have better information and what will produce it.
Explain the cause without building a defense
The audience needs to understand what changed, not every reason you worked hard. Separate newly discovered requirements, an invalid assumption, external dependencies, and mistakes in the original estimate. Each suggests a different response.
Take responsibility for what your team controls without assigning blame for everything. “We assumed the export included historical corrections; it does not, and we did not validate that early enough” is more useful than “the other team gave us a bad API.” Keep the explanation factual and proportionate.
Offer choices and recommend a path
A delay can create a scope, sequencing or timing decision. State the options in terms of outcomes: ship the core workflow on the original date and defer historical imports, move the whole release, or run a narrower pilot. Explain the risk each option retains.
Do not present extra hours as the only recovery plan. If the problem is uncertain behavior or an external decision, working longer may not remove it. Recommend a path that addresses the actual constraint and be clear about any help or approval needed.
Agree on the next checkpoint
Close with what is happening next, who owns it, and when the audience will hear more. The checkpoint can be a validated integration test or a decision meeting. Make it observable enough that “we are making progress” will not be the only possible update.
If your new estimate changes again, explain the new evidence rather than silently replacing the old commitment. Consistent updates let people recalibrate and reveal whether the plan is reducing uncertainty.
Keep the decision in the explanation.
- What changed: the original expectation and the new one.
- Impact: the milestone, users or dependent work affected.
- Why: the most relevant new information.
- Response: actions and realistic options.
- Recommendation: your proposed trade-off.
- Checkpoint: remaining uncertainty and the next update.
Same situation. Clearer explanation.
The project is a bit behind because the API team took too long and the data is more complicated than expected. We are working hard and should be done soon.
The reporting release is likely to move from Friday to next Wednesday. We discovered that historical corrections need a separate import path, which we did not include in the estimate. We can either defer historical data and keep Friday, or move the full release. I recommend the later release because incomplete reports would confuse customers. We will validate the import tomorrow and update the date by 3 p.m.
Illustrative examples. Adapt the facts and commitments to your situation.
Common mistakes to catch
- Using “soon” instead of a checkpoint.
- Giving a precise date while a critical unknown is unresolved.
- Spending most of the update assigning blame.
- Offering options without explaining which you recommend.
Now try saying it out loud.
Use the framework for one attempt. Listen back, choose one improvement, and try again.
Practice this conversationA couple of useful questions
Should I communicate a possible delay before it is certain?
Yes, when it could affect another person's planning. Label it as a risk, explain the condition that would cause it, and name the next checkpoint. Do not present a risk as an already confirmed outcome.
What if I made the original estimate?
Say which assumption was wrong or what you missed. Explain how the current plan addresses that mistake. Accountability is more useful when it comes with evidence and a changed approach.