How to give a project update: script and email template
A project update does one job well when it gives stakeholders enough to make a decision without wading through a list of finished tasks. Learning how to give a project update that people actually use, rather than skim and forget, comes down to a practical five-part structure: status, proof of progress, risk, next milestone, and a specific ask. The same structure works whether it's spoken in 60 seconds during a stand-up or written out in a weekly project status update email.
A project status report exists to give stakeholders a high-level view of what's on track, what's blocked, and what's coming next, not a replay of every task completed that week (Asana, about two years ago). A standardized format helps here, because it keeps the same key elements showing up in the same order instead of forcing a rebuild from scratch every cycle (Atlassian, nearly a year ago).
This guide covers adaptable wording for both a spoken update and a written one, why each part earns its place, and what to adjust depending on audience and project stage. It applies to project managers, team leads, and individual contributors who report progress to a manager, sponsor, or client. Whether the format is a live meeting or an email, the mechanics of how to write a project status update are the same five sentences, just delivered differently.
What to include in a project progress update for stakeholders
Every update, spoken or written, should hit five beats in order: status, proof of progress, risk or blocker, next milestone, and a specific ask. Draft one plain sentence for each before worrying about phrasing. That rough skeleton becomes both the script and the email template later in this guide.
Here's what each part is actually doing:
- Status. Answers whether the project is currently on track, at risk, or off track (Asana, about two years ago). Include only the label, nothing more; explanations belong in the risk sentence, not here. Sentence stem: "[Project] is [on track / at risk / off track] for [date or goal]."
- Proof of progress. This is where a completed milestone goes, not a list of tasks worked on. Leave out hours logged or activity completed, since weekly updates should emphasize results (Atlassian, nearly a year ago). Sentence stem: "[Milestone] was completed or signed off this week."
- Risk or blocker. Names the specific obstacle rather than a vague "mostly fine." Include what's stuck and what it's waiting on; leave out blame or backstory. Sentence stem: "[Blocker] is waiting on [person, team, or decision]."
- Next milestone. Answers what's coming and when. Include a date; leave out the full task list behind it. Sentence stem: "Next up is [milestone], targeted for [date]."
- Ask. Tells the stakeholder exactly what to do, approve, decide, or unblock. Include a deadline for the response; leave out open-ended requests like "let me know your thoughts." Sentence stem: "I need [decision or resource] by [date]."
This is the backbone whether you're updating a team in a stand-up or sending an email: the same five parts, just compressed differently depending on the format.
Color coding (green for on track, yellow for at risk, red for off track) is a useful shorthand for signaling status at a glance (Asana, about two years ago). But a label by itself can hide more than it reveals. An analysis of more than 2.3 million status updates across over 4,000 projects found that the brevity of status labels creates room for unintentional miscommunication, and sometimes intentional manipulation, which could undermine how much stakeholders can rely on them (IEEE Software, about 16 months ago). A label gives a quick signal, but it doesn't explain the evidence behind the status. That's the gap the proof-of-progress sentence is built to close.
How to give a 60-second project update: script example
The 60-second format compresses the five sentences above into a spoken script that fits inside a stand-up. Treat it as a practical project status update script, not a tested industry standard; no source here prescribes an exact sentence count, this is simply a workable shape built from the five-part structure.
A common weak version runs entirely off an activity log instead: "This week I finished the homepage mockups, updated three tickets in the tracker, had two calls with the design vendor, reviewed the staging environment, and started outlining the FAQ page copy." None of that is wrong, exactly. It just doesn't tell a stakeholder whether the project is healthy.
The fix is reporting milestones instead of tasks. A milestone is a zero-duration checkpoint marking something significant, like the completion of a phase or the approval of a key deliverable. Milestones work well for stakeholder reporting specifically because they skip task-level noise: stakeholders can see what's been achieved and judge priorities at a glance, without a rundown of every ticket worked on (Asana, about seven months ago). That's the sentence a stakeholder actually remembers after the meeting ends.
Here's an illustrative example, a fictional website relaunch, spoken the right way:
- Status: "The website relaunch is on track for the November 14 launch date."
- Proof: "We closed out the design phase this week, with homepage and product-page reviews both signed off."
- Risk: "The one open risk is the payment-gateway integration, which is waiting on a response from the vendor."
- Next milestone: "Next up is the staging environment freeze, targeted for next Friday."
- Ask: "I need a decision from marketing by Wednesday on whether the launch banner uses the new logo or the current one, since that affects what goes into staging."
Read that aloud once before the meeting and time it. If it runs well past a minute, the extra detail probably belongs in a follow-up email rather than the live update. Sixty to seventy-five seconds is a reasonable personal benchmark, not a figure backed by research, just a practical ceiling that keeps a verbal update from turning into a monologue.
Project update email template you can copy and adjust
The written version follows the same five-part order so the spoken and written updates reinforce each other instead of competing for attention. A standardized template also reduces repetitive preparation: it keeps the same elements showing up every cycle instead of making anyone rebuild the format each week (Atlassian, nearly a year ago).
Keep it short. Asana recommends a status summary of roughly two to three sentences, while Atlassian suggests an executive summary of no more than six sentences before any supporting detail (Asana, about two years ago; Atlassian, nearly a year ago). Keeping information centralized in one place, rather than scattered across spreadsheets and email threads, also lets stakeholders check status on their own time instead of requiring a meeting to get an answer (Asana, about two years ago).
Here's a fill-in-the-blank version to copy:
- Subject: Website relaunch status, week of [date]
- Project health: On track / At risk / Off track
- Summary: [2-3 sentences on what's done and what's coming]
- Milestone or result: [The specific checkpoint completed this period]
- Blocker: [Name the specific risk, or "None this week"]
- Next milestone: [What's next] by [date]
- Ask: [One sentence: the decision, resource, or approval needed, and by when]
Save it in a notes doc or a reusable email draft and send it on a cadence that matches the project and stakeholder needs, weekly, biweekly, or monthly, without tipping into information fatigue on either side (Atlassian, nearly a year ago).
What varies: audience, timing, and delivering bad news
There's no single correct cadence for reporting. How often and how deep an update goes should reflect the project's complexity and what stakeholders actually need to stay informed (Atlassian, nearly a year ago).
The ask itself should shift with the audience. A manager typically needs a decision tied to a resource or a timeline, while a client more often needs to understand the impact on scope, cost, or deliverables. The five-part order stays the same either way; only the wording of the ask changes.
Stakeholder perception also isn't fixed once and left alone. What read as "on track" during the kickoff meeting might not land the same way three months later, once priorities or budget pressures have shifted. When a milestone is missed, or a project moves from on track to at risk, naming the specific variance instead of softening the label matters precisely because compact status language is where miscommunication creeps in (IEEE Software, about 16 months ago).
Here's the same website relaunch, gone yellow:
- Status: "The website relaunch has moved from on track to at risk."
- Proof: "Homepage and product-page design are still complete and signed off."
- Risk: "The payment vendor pushed their delivery date back two weeks, which means the November 14 launch date cannot be met without a scope change."
- Next milestone: "Revised staging freeze, pending the decision below."
- Ask: "I need a decision by Friday on whether we delay launch by two weeks or cut the payment integration from the initial release."
The ask here comes with a real decision attached, not a vague "let me know your thoughts." Before sending any update carrying a yellow or red label, draft that ask first: what decision, resource, or approval is actually needed. A specific ask gives stakeholders a clear action instead of leaving them with information only.
This structure doesn't cover disputes over blame, performance consequences, or contractual deadline obligations tied to a missed milestone. Those situations call for an organization's escalation process and a conversation with the appropriate project sponsor or contract owner, not a general reporting format.
Next step
The five-part structure holds together because each sentence does a specific job: status for the headline, proof for evidence, risk for honesty, the next milestone for direction, and the ask for action. Skip any one of them and the update still sounds informative, it just doesn't move anyone to do anything.
Draft the next update using the script and email template above. Time the spoken version once, then hold it up against whatever's been sent lately and check which part tends to go missing, status, proof, risk, next step, or ask. That's usually the gap worth fixing first.
