Project delay notice

How to use it well

• →Lead with the new date, not the apology — the reader's first question is "when", and burying it under context reads as evasion.
• →One honest reason beats three small ones; a list of reasons reads as a list of excuses.
• →Send it the day you know. A delay announced early is planning; the same delay announced late is a broken promise.

Part by part

revised delivery date: {{new_date}}

The new date in the subject line. Bad news buried in the body is read as an attempt to soften it, which costs more trust than the delay itself.

{{slip_size}} later than planned

Quantifies the slip rather than leaving it to be calculated. Stating it plainly is what makes the message read as candid.

What this doesn't change: {{protected}}

Bounds the damage. Without it a client assumes everything has moved, which is usually a worse conclusion than the truth.

To make the new date reliable: {{mitigation}}

Explains why the new date is different from the old one. A revised date with no change in approach is a guess, and clients read it that way.

tell me what's immovable and I'll re-plan around it

Invites the constraint you may not know about, which is how a delay gets absorbed rather than escalated.

Common mistakes

• Burying the new date in the third paragraph.

  The reader is looking for one fact. Making them hunt for it reads as evasion, and the goodwill lost is larger than anything the surrounding explanation buys.

• Announcing the delay on the original delivery date.

  Timing is most of what is being judged. The same message a fortnight early is a plan; on the day it is a notification that something already went wrong and was not shared.

• A long explanation of why it happened.

  Length reads as justification. One clear sentence on the cause and considerably more on what makes the new date reliable is the ratio that rebuilds confidence.

Questions