How to Talk About Delays and Uncertainty in English
Author: Ksenia Izotova
Last updated: September 2026
Last updated: September 2026
How do you explain a delay clearly?
State what has changed, which milestone it affects, what you know about the cause, and what happens next. If a revised date is uncertain, explain its assumptions and give a time for the next update. Distinguish a forecast from an agreed commitment. People need enough information to adjust their own plans, even when you cannot yet tell them exactly when the work will finish.
“We should be fine for Friday.”
That sentence might mean “the current plan points to Friday,” “Friday is possible if testing goes well,” or “I really hope we finish by Friday.” The listener cannot reliably choose between them.
A clearer version is:
“Friday is our current target for staging. It depends on completing the integration tests on Thursday. I’ll confirm the result after that test run.”
Now the milestone and dependency are visible. Production release has not accidentally been promised.
“We should be fine for Friday.”
That sentence might mean “the current plan points to Friday,” “Friday is possible if testing goes well,” or “I really hope we finish by Friday.” The listener cannot reliably choose between them.
A clearer version is:
“Friday is our current target for staging. It depends on completing the integration tests on Thursday. I’ll confirm the result after that test run.”
Now the milestone and dependency are visible. Production release has not accidentally been promised.
All dates, names and project situations below are illustrative examples. The wording is practical editorial guidance, not a universal delivery policy.
Decide whether you are reporting a risk or a missed date
A risk is a possible future change. A delay is a change that has already occurred or is now confirmed. The wording should reflect that distinction.
Risk: “Thursday's handover is at risk because the access approval is still pending. If we don't receive it by 12:00 UTC tomorrow, testing will move.”
Confirmed delay: “We won't meet Thursday's handover. The access approval arrived too late to complete testing. I’ll send a revised schedule after we review the remaining tests at 15:00 UTC.”
Do not keep calling something “a risk” after you know the agreed date will be missed. Equally, do not announce a definite delay when you are still checking whether the work can be recovered.
Risk: “Thursday's handover is at risk because the access approval is still pending. If we don't receive it by 12:00 UTC tomorrow, testing will move.”
Confirmed delay: “We won't meet Thursday's handover. The access approval arrived too late to complete testing. I’ll send a revised schedule after we review the remaining tests at 15:00 UTC.”
Do not keep calling something “a risk” after you know the agreed date will be missed. Equally, do not announce a definite delay when you are still checking whether the work can be recovered.
Four phrases that create the wrong expectation
1. “It will be ready soon”
A fix has been implemented but not validated. “Soon” may mean this afternoon to the client and next week to the engineer.
“The fix is implemented. Validation is still pending, so I can't confirm release timing yet. I’ll update you after tomorrow's test run.”
If validation timing is itself uncertain, give a checkpoint you can control instead of promising the test will happen.
“The fix is implemented. Validation is still pending, so I can't confirm release timing yet. I’ll update you after tomorrow's test run.”
If validation timing is itself uncertain, give a checkpoint you can control instead of promising the test will happen.
2. “We will try our best”
A client asks whether the original deadline can still be met. “We will try our best” reassures them about effort, but leaves the planning question unanswered.
Try: “The original deadline is no longer achievable with the full scope. We’re checking whether a smaller release is viable. I’ll bring the options to our planning call tomorrow.”
Only offer reduced scope as an option after considering whether it is usable and safe to release. A communication shortcut cannot settle that technical decision.
Try: “The original deadline is no longer achievable with the full scope. We’re checking whether a smaller release is viable. I’ll bring the options to our planning call tomorrow.”
Only offer reduced scope as an option after considering whether it is usable and safe to release. A communication shortcut cannot settle that technical decision.
3. “The vendor is blocking us”
A third party has not supplied the credentials needed for integration testing. The sentence can sound like blame without explaining the impact or your own next action.
“Integration testing is waiting on the vendor credentials. We requested them on Monday and followed up today. We can continue the local tests, but we can't complete the integration check until access arrives.”
Naming an external dependency is appropriate. Explain it factually and say what your team is doing about it.
“Integration testing is waiting on the vendor credentials. We requested them on Monday and followed up today. We can continue the local tests, but we can't complete the integration check until access arrives.”
Naming an external dependency is appropriate. Explain it factually and say what your team is doing about it.
4. “It’s basically done”
The feature works in one environment, while migration and release checks remain. Other teams may hear “basically done” and start announcing availability.
“The feature works on staging. Migration and release checks remain, so it is not available to customers yet.”
This is also useful in stand-up updates: name the milestone instead of using an approximate completion label.
“The feature works on staging. Migration and release checks remain, so it is not available to customers yet.”
This is also useful in stand-up updates: name the milestone instead of using an approximate completion label.
Make the degree of certainty explicit
These are suggested working definitions. Agree how your team uses them, especially in customer-facing roadmaps.
A word such as “committed” does not eliminate delivery risk. If an agreed date becomes unachievable, address the change directly with the people affected.
Avoid assigning a confidence percentage just to sound precise. “80% sure” is difficult to interpret unless the team has a shared method for producing and using that estimate.
Avoid assigning a confidence percentage just to sound precise. “80% sure” is difficult to interpret unless the team has a shared method for producing and using that estimate.
A delay message that someone can plan around
Here is an example for an internal project channel:
“Update on the reporting export: we won't meet the staging handover planned for Tuesday. Testing found that larger files are incomplete, so we’re holding the handover while we investigate. Small-file exports passed the current checks; the large-file case is unresolved. Maya is investigating that path today. We don't have a reliable revised date yet. I’ll post our findings and scheduling options by 16:00 UTC.”
For a client who was relying on that handover, add acknowledgement and the practical consequence:
“I’m sorry we’re missing the handover we agreed. This means your planned acceptance testing cannot start on Wednesday. Could we discuss how that affects your team's schedule when we share the update?”
An apology can recognise the disruption. It should accompany a useful account of the situation. Several apologetic sentences will not help the client reschedule their work.
“Update on the reporting export: we won't meet the staging handover planned for Tuesday. Testing found that larger files are incomplete, so we’re holding the handover while we investigate. Small-file exports passed the current checks; the large-file case is unresolved. Maya is investigating that path today. We don't have a reliable revised date yet. I’ll post our findings and scheduling options by 16:00 UTC.”
For a client who was relying on that handover, add acknowledgement and the practical consequence:
“I’m sorry we’re missing the handover we agreed. This means your planned acceptance testing cannot start on Wednesday. Could we discuss how that affects your team's schedule when we share the update?”
An apology can recognise the disruption. It should accompany a useful account of the situation. Several apologetic sentences will not help the client reschedule their work.
What if your manager asks for a date anyway?
Clarify what the date will be used for:
“Is this for internal planning, or will it be communicated as a customer commitment? I can give a provisional planning range, but validation is still open.”
If no defensible estimate exists:
“I don't have enough evidence to give a reliable finish date. By 14:00 UTC we should know whether the proposed fix addresses the issue. I’ll update you then, including if the test is inconclusive.”
Do not confuse confidence in your communication with certainty about the work. You can be direct about an unknown.
For external conversations, see how to explain a technical problem to a client.
“Is this for internal planning, or will it be communicated as a customer commitment? I can give a provisional planning range, but validation is still open.”
If no defensible estimate exists:
“I don't have enough evidence to give a reliable finish date. By 14:00 UTC we should know whether the proposed fix addresses the issue. I’ll update you then, including if the test is inconclusive.”
Do not confuse confidence in your communication with certainty about the work. You can be direct about an unknown.
For external conversations, see how to explain a technical problem to a client.
Before you send the update
- Name the milestone: implementation, review, staging, acceptance testing or release.
- State whether the delay is possible or confirmed.
- Give the known reason without speculation or blame.
- Identify dependencies behind a new target.
- Specify the next action and owner.
- Use a date, time and time zone when a deadline needs precision.
- Follow up at the promised checkpoint, even if the answer is still incomplete.
Frequently asked questions
Is “hopefully” unprofessional?
It is common in conversation, but it is insufficient for a delivery update. Pair any hopeful target with the actual dependency and a checkpoint, or use a more explicit forecast.
How do I say that I do not know the completion date?
“We don't have a reliable completion estimate yet. We’re checking [specific issue], and I’ll update you at [time].” Use only an action and update time you can support.
Should I explain every technical cause?
Give enough detail for the audience to understand the impact and available choices. An engineering team may need investigation details; a client may need the effect on their acceptance testing or launch.
Can better wording prevent delays?
It can make risks and dependencies easier to discuss. It cannot remove missing capacity, unresolved technical problems or a planning process that discourages early warnings.
Practise explaining the uncertainty
UnifyHub works on these conversations through English for product managers and English for client-facing engineers. Book a team assessment to discuss the communication situations your programme should address.
Choose a past project update and write three versions: an early risk, a confirmed delay and an update after a recovery plan has been agreed. Each version should contain only what was known at that point. If they all sound the same, the degree of certainty probably needs to be clearer.
Choose a past project update and write three versions: an early risk, a confirmed delay and an update after a recovery plan has been agreed. Each version should contain only what was known at that point. If they all sound the same, the degree of certainty probably needs to be clearer.
Author: Ksenia Izotova
Last updated: September 2026
Last updated: September 2026