When to send a project status update
A project status update is the document your sponsor uses to decide whether you have the project under control. The dashboard, board, and slide deck support it. The email is where your judgment about state, risk, and confidence goes on record.
Send it when the reader needs to know whether work is on track, at risk, blocked, or changed, and whether they need to act. Skip it when nothing changed since the last update and no decision is pending. Empty updates train people to skim the useful ones.
Use these for client work, internal projects, implementation updates, and cross-functional handoffs. For a recap after a live discussion, use the meeting follow-up templates. For recurring follow-up hygiene, use the follow-up email workflow.
Choose the project state
Choose the state before adapting the update for a stakeholder or client audience. If the state is wrong, the reader has to ask a side question before the update helps.
| Project state | State test | Reader action | Common mistake |
|---|---|---|---|
| On track | The next milestone holds without intervention this week. | No decision. Read for confidence and next date. | Calling it on track when one named dependency is still floating. |
| At risk | The date can still hold if one thing changes. | Pick an option by the decision date. | Burying the decision under the explanation of what went wrong. |
| Blocked | Work has stopped and can't move without outside input. | Provide the missing input. | Describing the blocker without pricing the wait. |
| Changed | Scope, owner, or date moved. | Confirm the new handoff. | Hiding the change inside a normal progress update. |
State test
- On track
- The next milestone holds without intervention this week.
- At risk
- The date can still hold if one thing changes.
- Blocked
- Work has stopped and can't move without outside input.
- Changed
- Scope, owner, or date moved.
Reader action
- On track
- No decision. Read for confidence and next date.
- At risk
- Pick an option by the decision date.
- Blocked
- Provide the missing input.
- Changed
- Confirm the new handoff.
Common mistake
- On track
- Calling it on track when one named dependency is still floating.
- At risk
- Burying the decision under the explanation of what went wrong.
- Blocked
- Describing the blocker without pricing the wait.
- Changed
- Hiding the change inside a normal progress update.
Build the update before picking a template
Write these four lines before opening a template. If one line is blank, the reader will fill the gap with a chat thread, a meeting, or a private guess.
Before sending, name what the update is supposed to produce. PMBOK frames work performance reports as documents meant to generate decisions, actions, or awareness. If the update produces none of the three, hold it.
- Delta: One sentence on what changed since the last update: work completed, a moved date, a surfaced blocker, a closed risk, or a new owner. If nothing changed, hold the update.
- Decision: Either no decision needed, or the exact decision, the owner, and the date by which silence becomes a problem. Use the BLUF email convention: put the bottom line above the explanation of what caused it.
- Confidence: High only when every owner is named and every dependency for the next milestone is confirmed. Drop to medium when one dependency loses an owner or date. Drop to low when work has stopped, the next owner is unknown, or the most recent milestone slipped.
- Next update: A specific date, not a cadence promise. Readers should know when silence means progress and when silence means drift. If the state is at risk or blocked, the next update should be no more than 48 hours out.
Five ways status updates fail
A status update can be short and still fail if it leaves the reader asking what changed, whether they need to act, or how much to trust the date. Run the draft against these before sending.
- Watermelon status: Green on the outside, red underneath. If a single unowned dependency could still move the date, the update is medium, not green. PMI separates risks from issues: risks might happen, issues already are, and reporting green while an issue is live is a forecast dressed up as status.
- Decision without an owner: A decision line stalls when no one is named. Bind the decision to one person, one date, and one consequence: what slips if the decision waits.
- Unpriced blocker: A blocker without a cost reads like background detail. State what waits, who owns the unblock, and the concrete cost, such as two days of QA, the demo on the 19th, or a delayed launch.
- Activity log: Listing what the team did since last week isn't status. A completed task belongs in the update only when it moved confidence, closed a risk, changed the milestone, or unblocked someone else.
- Status drift: Three updates in a row with the same state means the state is wrong or the recovery plan isn't working. At risk for four weeks is functionally blocked. On track for six weeks with no completed milestone is drifting.
Who goes on the To line
A status update isn't a meeting recap, so it doesn't go to everyone who was in the room. Put the owner of any open decision or action on To, keep routine progress and dependency-watchers on Cc, and when a tolerance on time, cost, or scope is breached, move the sponsor up to To so the exception can't be skimmed as FYI traffic.
A worked example, filled in
Here's the four-line frame carrying a real email end to end: an at-risk update on a billing-system migration, written for the sponsor who owns the QA budget.
Template 2 filled in, so the delta, decision, confidence, and next-update lines read as a concrete email instead of bracketed placeholders.
Billing migration at risk: decision needed by Thursday
Hi Dana,
We need a decision on weekend QA coverage by Thursday to keep the billing migration launching on March 15.
Staging came back online Monday, but the vendor still hasn't provisioned API access, so QA can't run the full payment suite. Approving weekend QA coverage holds March 15; without it, the launch moves to March 22.
Confidence: medium. It holds if the vendor provisions access by Wednesday and QA clears the payment suite by Friday.
Since the last update: staging is back, and the data-migration dry run passed with zero errors.
I can walk through the tradeoff today at 3:30 or tomorrow at 10.
Next update Thursday, or sooner if the vendor confirms access.
Best,
Tessa
Anchor confidence to dated conditions, not adjectives. 'Medium, holds if the vendor provisions access by Wednesday' tells Dana what to watch; 'medium, still some risk' tells her nothing.
Don't soften the two outcomes into 'working through some issues.' Dana is choosing between March 15 and March 22, so both dates and the cost of waiting stay in the email.
On-track project update
Send this when the project is moving and the reader mainly needs confidence and the next milestone.
[Project]: on track for [milestone] on [date]
Hi [Name],
[Project] is on track for [milestone] on [date].
Confidence: high. [Owner] is moving on [next work], and the dependencies for [milestone] are confirmed.
Since the last update we finished [completed work that moved the milestone].
Nothing needed from your side this week. Next update [date].
Best,
[Your Name]
Name the milestone the reader cares about instead of listing every task the team completed.
Avoid calling something on track when the next milestone depends on an owner or date you have not confirmed.
At-risk project update
Send this when the plan can still recover if the team decides or the dependency clears soon.
[Project]: decision needed by [date]
Hi [Name],
Need a decision by [date] to keep [milestone] on [original date].
[Recommended option] holds the date at the cost of [tradeoff]. The alternative, [other option], moves the milestone to [new date].
Cause: [one sentence]. Confidence holds at medium until [person/team] decides or [dependency] confirms. After [decision date], the date moves by [duration].
I can walk through it [today at 3:30] or [tomorrow at 10].
Next update [date], or sooner if [person/team] decides.
Best,
[Your Name]
Tie the risk to a real impact. At-risk without an impact sounds like process noise.
Avoid explaining the cause before naming the decision and decision date.
Blocked project update
Use this when the work can't continue until someone provides input, access, approval, or a decision.
[Project] blocked on [item]
Hi [Name],
[Project] is blocked on [missing input, access, approval, or decision].
The unblock is [specific ask], owned by [owner], needed by [date].
Until that clears, [specific work] can't move. Each day this stays blocked pushes [milestone] by [concrete cost: e.g., a day of QA, the launch by a week, the GA on the 30th].
Confidence: low until [specific input] arrives. The part already completed is [completed work], and the next step after the blocker clears is [next step].
Next update [date], or as soon as the blocker clears.
Thanks,
[Your Name]
Be precise about what's missing and what the wait costs. A blocked update should make the request impossible to miss.
Avoid long apologies when the reader needs the missing input, impact, and unblock.
Changed project update
Use this when the project is still moving but the original handoff, date, or scope no longer holds.
[Project]: [scope/date/owner] changed
Hi [Name],
One part of [Project] changed: [scope, owner, or date].
Original plan: [old plan]. Updated plan: [new plan]. Reason: [concrete reason].
Impact: [timeline, budget, scope, quality, or stakeholder impact]. The next owner is [owner], and the next handoff is due [date].
Confidence: [high/medium]. The new handoff holds if [dependency] stays in place.
Does this updated handoff work on your side?
Next update [date].
Best,
[Your Name]
Name the exact thing that moved. Changed updates work when the reader can compare old plan to new plan without searching the thread.
Do not hide the change inside a general progress update or make the reader infer whether the new owner or date is firm.
Missed-milestone recovery
Send this within a day of a missed milestone you previously committed to in writing. Lead with the miss, the cause, and the new date.
[Project]: missed [milestone], new date [date]
Hi [Name],
[Milestone] did not land on [original date].
What happened: [one or two sentences on the actual cause, not the symptom].
New date: [date]. Confidence: [medium/low] because [the specific thing that has to change between now and then].
What's different this time: [the change in plan, owner, scope, or constraint that makes the new date holdable].
Decision needed from you: [decision and date], or nothing from your side, the recovery is owned on my side.
Next update [date], or sooner if the recovery plan changes.
Best,
[Your Name]
Name the cause in operator terms. 'Vendor delivered the API two weeks late' is concrete; 'engineering underestimated complexity' reads like a performance review.
Avoid listing every task completed as evidence of effort. The reader is asking whether the new date is real.
Forwardable update for someone outside the project
A forwarded status update has to survive without the original thread. Put state, milestone, date, and decision above anything the reader would need project context to parse.
Use this when your reader has to forward the update to a senior leader who isn't close to the work. Write the email for the leader, not the forwarder.
[Project]: [state] for [milestone] on [date]
Hi [Name],
[Project] is [state] for [business milestone in plain language] on [date]. Where each piece stands:
[Workstream 1] is [on track], [one-line status].
[Workstream 2] is [at risk], [what would move it back on track].
[Workstream 3] is [blocked], [what it's waiting on and who owns it].
Decision needed: [decision, owner, date]. Or: no decision needed this week.
What changed: [one sentence on the delta since the last update].
Confidence: [high/medium/low]. The one thing that could move it is [risk or dependency], handled by [mitigation].
Happy to take a 15-minute call with [senior leader] if a deeper read is useful.
Thanks,
[Your Name]
Translate internal task names into the business milestone the leader tracks. Switch to Postgres is a task; cut hosting cost by 30 percent is what the leader reads for.
Avoid first names without role context. The forwarded reader may not know who owns each workstream.
Project update checklist
Before sending
- 1Same state three updates running. If on track for three sends with no completed milestone, the state is wrong or the project is drifting.
- 2Decision date already in the past. If the decision date on an at-risk update has slipped, this update is blocked, not at risk.
- 3No owner named for the next action. If you can't bind one name to the next step, the update isn't ready to send.
- 4Distribution list on To. The owner of the open decision goes on To. Watchers and distribution lists go on Cc.
- 5Activity log without a delta. If a bullet doesn't move confidence, change the milestone, or close a question, cut it.
- 6Routine update with nothing new. Empty updates train readers to skim the useful ones. Hold and combine.
- 7Confidence doesn't match the dependency picture. If any dependency is unowned or undated, the update isn't high confidence.
How dreamif.ai helps with project updates
dreamif.ai can draft a project update from user-supplied status notes, saved contact notes, and optional context from approved Drive folders or connected Gmail threads. You approve the wording before anything is sent.
For project threads, give it the state, reader action, confidence level, owner, milestone, risk, and next date. It can turn those notes into a skimmable update, then hold the draft for review.