Tell Your Team a Deadline Is at Risk Before It Becomes a Surprise

Say which deliverable is at risk, what changed, what the delay would affect and when people will hear from you next. If the date is no longer possible, say that plainly. A working estimate is not an approved new deadline, and a promise to send an update is not a promise to finish the work.

Miles Crawford

7 min read

This image was generated with AI

Name the state before choosing the wording

"Running a bit behind" can mean a possible risk, a certain miss or an already-agreed change. Those states need different decisions. Our table is a writing aid, not a project-management policy.

State	What the update needs
At risk	The condition threatening the date and what would change the forecast.
Will miss	A direct statement that the current commitment cannot be met, plus impact and options.
New date unknown	What must be checked and when you will report the result.
Revised plan agreed	The approved date and scope, decision owner, remaining conditions and updated record.

Communication specialist Chris Fenning recommends raising a delay as a risk before it becomes reality when possible. His advice also distinguishes a delivery date from a date for finding out the delivery date. That distinction lets you be specific without inventing an estimate.

Lead with the affected commitment

Give people the information they need to plan before the history of how you got here. Name the deliverable, the current commitment and the relevant evidence. All messages in this guide are fictional examples, not reports about real projects.

The venue checklist is at risk for the 3pm handoff. Two access details are still unconfirmed, so I cannot finish the arrival instructions yet. I am checking them with the venue contact. I will update this thread by 1pm Mexico City time, even if the answer is still pending.

This does not claim the deadline is already missed. It explains the specific condition and a next update time. If the remaining work cannot fit before 3pm even if the answer arrives now, use "will miss" rather than "at risk."

Atlassian's status-report guidance includes timeline, scope, budget, blockers and next steps with owners. A short chat update does not need a full report, but it should not hide a changed commitment behind a list of completed tasks. "Most of it is done" is less useful than naming the unverified part that prevents delivery.

When the miss is certain, do not soften it into a maybe

State the miss, take responsibility for your part and give the next practical choice. A brief apology can fit a missed commitment; it should not replace a plan. Describe dependencies without turning the message into a blame exercise.

I will miss the agreed noon delivery for the edited interview. I underestimated the audio cleanup, and the final review has not started. I am sorry for the short notice. I can send the checked transcript today, but the finished audio needs a revised review slot. Would the transcript keep your preparation moving while we agree the audio date?

Only offer the transcript if it is actually ready and useful on its own. Label incomplete or unreviewed work honestly. Do not quietly remove a quality, safety or compliance check just to make the original date appear met.

Ask which downstream work is affected. The person waiting may care more about a specific section than the whole package, or may need the full reviewed version. Fenning's delay guidance recommends understanding the business impact before settling on a solution.

If you cannot estimate yet, commit to the next check

Do not turn uncertainty into "tomorrow" because it sounds reassuring. Name the missing information and the check that will let you estimate. If you can support a range, explain its assumptions. If you cannot, say so.

I cannot give a credible completion date until we know whether the damaged files can be restored. The recovery check is in progress. I will report its result by 4pm and either give a delivery estimate or explain the next unresolved dependency. Please do not use tomorrow as a confirmed delivery date.

The 4pm update is a commitment of its own. Choose a time you can keep and send the update even if there is no resolution. "Still waiting" can be useful when it states what remains pending and what happens next. It is not useful when it silently repeats yesterday's forecast.

Avoid invented confidence percentages. If a date depends on a supplier response, describe that dependency rather than calling the plan "90% certain" without evidence. A target is what you are aiming for; an estimate describes what current information supports; a commitment is what you have agreed to deliver.

Offer choices without changing other people's commitments

A useful option names what changes and who can decide. Moving a date, reducing scope or borrowing another person's time may affect a client, budget or another team's plan. Do not treat posting the option as approval to act on it.

For the campaign review, we have two options: keep the current slot for the two checked layouts, with the third layout reviewed later, or move the full review after all three are ready. The project owner needs to confirm which scope works with the client before I change the invitation or delivery note.

Do not promise extra staffing, overtime, fee waivers or client concessions without the required agreement. If the only responsible option is to move the date, say that instead of presenting an unsafe shortcut as a choice. Our priority-tradeoff guide covers making capacity limits explicit.

GitLab documents a decision process with a named responsible individual, alternatives and a recorded choice. That is its own operating model, not a rule for your workplace. The useful idea here is to separate the person supplying information from the person authorized to change the plan.

Choose the right audience, then keep one current record

Tell the people who depend on the delivery and the person who can decide the tradeoff. Do not post private client, health or performance details to a wider channel merely to prove why the work is late. APM's stakeholder guidance recommends planning the audience, purpose, channel and frequency of communication.

When the impact is urgent or sensitive, use the appropriate direct conversation or escalation route rather than assuming a channel post was noticed. APM distinguishes interactive conversations from pushed updates and information people retrieve when needed. After the conversation, record the authorized outcome where the affected team can find it.

Decision recorded after the review: the project owner approved the two-layout review in the original slot. The third layout is excluded from that review and has a separate agreed deadline in the task. I updated the review note and linked the decision here. The remaining risk is the image approval, which we will check at the next update.

Only say those updates are done after doing them. Use text such as "at risk" beside a yellow marker rather than relying on color or emoji alone. A 👀 reaction can acknowledge an update under team norms, but it does not approve a new date or scope.

Agree on an update cadence that fits the risk. APM's practitioner interviews describe very different frequencies for different project conditions; they do not establish one correct interval for every team. Update sooner when the forecast, impact or needed decision changes. Once the issue is resolved, close the loop instead of leaving the old warning as the latest visible status.

Sources and limits

Reviewed October 29, 2026. The decision aid and fictional messages are our synthesis of professional advice and an organizational decision process. They are not evidence that one script protects a deadline, job or client relationship. Contractual, safety, incident and regulated reporting procedures take priority.

The hero is conceptual AI artwork about an early warning before a gap, not a photograph of a real project.