Draft Your Project Status Update With AI

Turn a week of Slack threads, mixed signals, and one slipping milestone into a single status update leadership reads in 60 seconds and engineers do not hate.

The task

It is Thursday afternoon. You own a cross-functional project — design, eng, data, one external vendor — and the weekly update is due before EOD Friday. Leadership wants a 60-second read with the right RAG color. The team wants to see that you noticed the spec changed twice this week and that nobody is pretending the API slip didn’t happen. Your Slack scrollback is 200 messages deep and your Notion has half a dozen half-written drafts. You need a single document that lands the truth for both audiences without inviting a panic ping at 11 PM.

Where AI helps — and where it does not

AI is good at compressing scattered notes into the RAG (Red / Amber / Green) structure, surfacing risks you mentioned in passing but didn’t flag, and rewriting “things are mostly fine” hedges into a sentence leadership can act on. It is also good at separating “what changed” from “what is still true” — the most common reason updates get ignored is that they re-state last week’s state instead of highlighting the delta.

What AI cannot do: choose the status color. That call needs context the model does not have — what leadership tolerated last quarter, whether the VP is already nervous about the launch, whether your skip-level expects you to over-call risk or under-call it. AI also cannot tell you which decision is actually blocked vs. just slow. Those are judgment calls.

A specific failure mode: AI defaults to symmetric three-bullet sections (3 wins, 3 risks, 3 decisions) even when the real shape is 1 win, 1 big risk, 0 decisions needed. Tell it explicitly: “do not pad to fill sections; if there are no decisions needed this week, write ‘None — next pull on Monday.’”

What to feed the AI

  • Last week’s update (verbatim, so the model knows what counts as “changed”)
  • Raw notes from the week — decisions made, slips, wins, risks, scope changes, vendor delays
  • Your gut RAG call (Green / Amber / Red) — and one sentence on why
  • The single milestone date that matters most this week (the model anchors everything to it)
  • Names + roles of the people who own each workstream (so risks can be assigned, not orphaned)
  • Leadership’s current sensitivity — are they nervous about the launch, or is this a low-attention quarter?
  • The one thing you most want leadership to know that they probably do not (the “buried lead” sentence)
  • Any scope or budget changes since last update (these belong above the fold)

Copy-ready prompt

Write a project status update for {project name}.
Audience: {leadership read + team read}.
Last week's update (verbatim): {paste}
This week notes: {paste}
My RAG call: {Green / Amber / Red} because {one sentence}.
Anchor milestone: {date + what ships}.
The buried lead leadership probably does not know: {one sentence}.

Structure:
1) Headline — one line, includes RAG color and the anchor milestone date.
2) What changed since last week — only deltas; do not re-state stable items.
3) Risks — each with concrete mitigation, owner, and a "by when." If no owner, demote to "watch-item."
4) Decisions needed — name the decision, the options, the decider, and the cost of delay. If none, write "None — next pull on {day}."
5) Next 2 weeks — 3-5 bullets, each with the workstream and the human responsible.

Total under 250 words. Do not pad sections to be symmetric. The buried lead must appear in the first 3 lines.

Shorter variant — leadership-only 80-word headline

Write the 80-word leadership-only paragraph for {project}.
RAG: {color}. Anchor milestone: {date}.
The single most important thing they need to know: {sentence}.
Format: 1 sentence RAG + anchor. 1 sentence what changed. 1 sentence biggest risk + owner. 1 sentence what we need from them (or "nothing this week").
No bullets. No filler.

Sample output

A headline that works: “Amber through Nov 14 — design is on track, eng is one sprint behind on the payments API; recovery plan in place, no scope change yet. Buried lead: vendor SLA for the fraud check expires Nov 8 and renewal needs Legal sign-off this week.”

A useful risk bullet: “Payments API one sprint behind (Maya, eng). Mitigation: cut analytics from v1 and re-baseline ship to Nov 14. Decision needed by Nov 1 if we also want to keep referral codes in v1; otherwise default is to defer.”

A useful “decisions needed” line: “None — next pull on Monday. Two items are pending vendor reply and will surface next week or escalate.”

How to refine

  • Force every risk to have an owner and a date: “Each risk must have a named owner and a ‘by when.’ If neither exists, demote it to ‘watch-item’ under the risks block, not above.”
  • Strip restated context: “Delete any sentence that was also in last week’s update. The update is only the delta; readers can scroll for the rest.”
  • Make the buried lead the first 3 lines: “Re-order so the thing leadership most needs to know is in the first sentence, not paragraph 3.”
  • Pre-empt the obvious question: “After every risk, add one sentence answering the question leadership will ask: ‘what would make this Red?’ or ‘why is this not Red yet?’”
  • Trim to 250: “Cut to 250 words. Whatever survives is the actual update. If a section disappears, that is fine — symmetry is not the goal.”

Common mistakes

  • Always-Green updates that hide slippage — the moment leadership notices the gap between the update and reality, every future update gets discounted
  • Listing every Jira ticket and PR merged — leadership wants signal, the team can read the board for detail
  • No date on the ship target — “soon,” “imminent,” and “this quarter” are not statuses; pick a week, even if you have to revise it
  • Restating last week’s risks unchanged — if a risk hasn’t moved, say “unchanged from last week, still Amber” rather than re-explaining
  • Risks without owners — orphan risks read as decoration; nobody acts on them and the report becomes theater
  • Burying the buried lead — the one sentence leadership most needs to know cannot be in paragraph 4
  • Using “we” everywhere — be specific about who owns what; “we” is where accountability goes to die
  • Letting AI invent risks that weren’t in your notes — only ship risks you actually believe; phantom risks erode credibility fast

FAQ

  • Same template for leadership and engineering?: Body yes, headline no. Engineering wants the “what changed” first; leadership wants the RAG color and anchor date first. Generate both headlines from the same body.
  • When does Amber become Red?: When mitigation requires resources or scope changes only leadership can approve. If the team can recover on its own — even painfully — it is Amber. Red is a call for help, not a description of how bad it feels.
  • The model keeps softening risks — how do I push back?: Add to the prompt: “If a risk could be deleted without changing leadership’s actions, make it louder, not softer. Vague risks get ignored, and ignored risks become Red.” Then re-run.
  • What if there genuinely is nothing to update?: Write a 60-word “steady state” update: anchor milestone, RAG, one sentence on next checkpoint. Skipping a week looks worse than a short one.
  • Should I share the update before or after the all-hands?: Before. The update is the artifact leadership reads when they cannot attend; the all-hands is where the team asks questions about it.

Tags: #AI writing #Office #Workflow #Project