How do you tell stakeholders a project is late?

Tell stakeholders a project is late as soon as you would bet against the promised date, in one short message with four parts, sent before the date passes. The four parts are what was promised, in the words of the original commitment; what changed and why, naming the cause without naming a culprit; the new date with your confidence in it, or the decision you need and by when; and what happens in the meantime. Do not wait until you are certain, and tell the person who was promised the work directly, before they read it in a status report. Then record the change against the original commitment, with the reason, so the old date stays visible beside the new one instead of being overwritten.

How to tell stakeholders a project is late

A late project rarely costs you the stakeholder. Hearing about it after the date has passed does. Tell the people you promised as soon as you would bet against the date, in one short message with four parts, and record the change against the original commitment instead of quietly replacing it. This page gives you the wording.

As with the scripts for declining a request, none of the five emails works anything out for you. Get the new date, or the options, from the delivering team first, then replace everything in square brackets.

When to send it

Send it the day you would bet against the date. Not the day you are certain, and not the day the date passes. The test is private: offered an even bet that this lands when promised, which side would you take? Once the honest answer is "against", everyone planning around that date is working from information you know to be wrong.

A warning loses value with every week it is held back: told a month ahead, a stakeholder can move a launch or warn a customer. Told on the day, they can only absorb it.

Tell the person who was promised the work directly, before the next status report. A status marked at risk, with its reason attached, is the early warning; this message follows the day you would no longer bet on the date. Nobody should learn that their date moved from a line in the at-risk section of a report.

The four parts of a project delay email

What was promised. The outcome and the date, in the words of the original commitment, not a softened memory of them.
What changed, and why. Name the cause without naming a culprit: "the identity migration we depend on moved to November", not "the platform team let us down".
The new date, or the decision you need. A date with your confidence in it, or a decision with who makes it and by when. If the team has not re-estimated yet, do not wait for it: say so, and give the day you will have the new date.
What happens meanwhile. What the team is doing now, what the reader should stop planning around, and when they will next hear from you.

1. A new date

When to use it: the scope stands, the cause is understood, and the team has given you a date it believes.

Subject: [Project]: moving from [old date] to [new date]
Hi [name],
We committed to [outcome] by [old date]. We are not going to make that date.
What changed: [the cause, in one or two sentences].
The new date is [new date]. The team gave me that date this week, and my confidence in it is [high / medium / low] because [reason].
The scope has not changed. Please stop planning around [old date]. I will confirm on [check date] that we are still on course.
[You]

Put the old date beside the new one, so nobody has to work out how far it moved. State your confidence too: the second slip is the one that damages trust.

2. A choice between scope and date

When to use it: the date can still hold if something comes out, and which matters more is not your call.

Subject: [Project]: a decision needed by [decision date]
Hi [name],
We committed to [outcome] by [date]. We cannot deliver all of it by then, because [the cause].
There are two options, both sized by the team.
A. Keep [date] and leave out [named scope]. You still get [what ships].
B. Keep the full scope and move to [new date].
I would choose [A or B], because [one reason]. It is your promise to [their customer or team] that is affected, so the decision is yours. I need it by [decision date]. Until then the team continues on [the default option].
[You]

Without the recommendation you have handed over your homework; without the default, a slow reply becomes a third option nobody chose. And name what comes out precisely: the exclusion is the part that has to hold later.

3. A dependency outside the team

When to use it: your own work is on course, and something it cannot finish without is late: another team, a vendor, a legal review.

Subject: [Project]: [old date] depended on [dependency], which has moved
Hi [name],
We committed to [outcome] by [old date]. That date depended on [the dependency] being ready by [date]. It is now expected [on new date / with no date yet].
We need about [duration] once it arrives, so the earliest we can deliver is [new date / that long after it lands].
What would help: [the specific decision or escalation, and who can make it].
Meanwhile the team is [doing the parts that do not depend on it]. I will write again on [date].
[You]

Describe the dependency as a fact with a date, and copy its owner so they read the same sentence your stakeholder does. If it was asked for but never confirmed, that part of the cause is yours.

4. The estimate was wrong

When to use it: nothing outside the team changed. The work turned out larger than the figure the commitment was built on.

Subject: [Project]: [old date] will not hold; the work is larger than we estimated
Hi [name],
We committed to [outcome] by [old date], on an estimate of [original figure]. That estimate was wrong, and it was ours.
What we found: [the specific thing, e.g. "the billing data must be migrated first, and we had sized that as a configuration change"].
The team's figure for what remains is [remaining figure], which puts delivery at [new date]. It is better founded than the first because [what is now known]. Still uncertain: [the open item].
If [new date] does not work, tell me this week and I will come back with what we could leave out.
[You]

One sentence of ownership, then facts. More apology than that asks the reader to manage your feelings. What earns the next commitment is saying why this figure is better founded, and what is still uncertain in it.

5. Stopping the work

When to use it: the decision to stop has been made with the person who was promised the outcome, and others now need to know. Whether to stop is a separate question.

Subject: [Project]: stopped
Hi [name],
We committed to [outcome] by [date]. We have stopped the work, and it will not be delivered.
Why: [the reason, and when it became true, e.g. "the customer this was for ended their contract in September"]. [Decision-maker] and I decided this on [date].
What exists: [what shipped, if anything; what is in a branch; what could be reused].
What happens now: the team moves to [next work] from [date]. If you were planning around [outcome], please treat it as not coming. If the need is still real, bring it back as a new request.
[You]

Use the word "stopped". "Paused" and "on hold" describe something that might resume, and without a date for looking again they are not true.

What not to write

"A slight delay." Give the number of weeks. The reader will ask anyway.
"We are ninety per cent done." That is effort spent, not work remaining. Give the remaining figure.
A named culprit. The email will be forwarded, and you will need that person's help next month.
A date nobody gave you. A figure produced to finish the email will be quoted back as a promise. That is how an estimate hardens into a commitment.
The news in paragraph four. That the date will not hold belongs in the subject line or the first two sentences.

Re-baseline, do not overwrite

The message is half the job. The other half is the record. Once the new date or the smaller scope is agreed, restate the commitment: the new version beside the original, with the reason and the day it changed.

The tempting alternative is to open the roadmap and type over the date. That erases the only evidence that the promise was changed on purpose, with the stakeholder told. Three months later the record shows a project that was always due in November, or one that missed September. Neither is what happened.

Who decides a re-baseline, and when a change is small enough to absorb, is covered in a change request process that fits on one page. The rule here is narrower: a date you have announced as moved gets recorded as moved, the same day.

If you use DeliverySheet

DeliverySheet does not send any of these messages. No notification goes out when a check-in is posted or a commitment changes; the only email about the work is an optional weekly summary to the workspace owner. The message is yours; the product holds the record on either side of it.

Before the message: a check-in on a committed demand records one of three statuses (on track, at risk, off track), with a field for what changed and another for the decision or help needed. It can be marked as changing the committed baseline, which opens the re-baseline form once it is posted.

After it: a re-baseline cannot be saved without a reason. It is recorded as a new baseline and the original is kept, so the Commitment ledger in Reports shows the old quarter or end date struck through beside the new one, with the reason underneath. To close stopped work, record the delivery outcome as not delivered; that also requires the reason.