How do I write a project status update people can scan quickly?
Quick answer
Put the overall status and the main reason for it in the first line. Then use short, labeled sections for completed work, next steps, risks or blockers, and requests. Include owners and dates where they are known; mark unknowns instead of guessing. Keep each item focused on a meaningful change or action so readers can quickly see what is on track and what needs attention.
The question, the details, the next step.
I need to send a project update that people can skim. What should come first?
Start with the status, then explain the most important reason in the same sentence. Don’t make readers work through a list of activity before they find out whether the project is on track.
For example, using hypothetical details: “Status: At risk — the review is taking longer than planned, so the Friday handoff may move.” This tells readers the state and why it matters. Use “On track,” “At risk,” or “Blocked” only when those labels reflect your team’s agreed meaning. If your team has no shared definitions, say plainly what is happening instead of relying on a color or label.
How do I keep the rest of it short without leaving out useful information?
Group the update under four brief labels: Completed, Next, Risks or blockers, and Requests. Include work that changed the project’s position, not every task someone touched. Under “Next,” give the action, owner, and date when you know them. Under “Completed,” say what is now done or available. If an owner or date has not been decided, write “owner to confirm” or “date to confirm” rather than filling the gap with a guess.
A useful test for each line is: does this tell the reader what changed, what will happen, or what needs attention? If not, it may belong in a detailed project log rather than the scan-friendly update.
What belongs under risks, and how do I ask for help without making the update sound alarmist?
Name the uncertainty or obstacle, its practical effect on the work, and what would reduce it. Keep the wording specific and neutral. For instance: “Risk: The draft is still awaiting review. If approval is not received by [date], the planned handoff may shift. Request: [reviewer or team] to confirm timing.” This describes a possible consequence without presenting it as certain.
Make a request actionable: say who needs to do what, and by when if a deadline is known. If you do not yet know the impact or timing, say that too and give a next check-in, such as “Impact still being assessed; update expected [date].” That is more informative than either hiding the uncertainty or overstating it.
Could you show me the whole format with an example I can adapt?
Here’s a copyable template. Replace the bracketed text, remove sections that genuinely have no updates, and keep any unknowns explicit.
Project: [name] | Reporting period: [dates] Status: [On track / At risk / Blocked] — [brief reason or plain-language state]
Completed
- [Meaningful result; date if useful]
Next
- [Action] — [owner] — [date or “to confirm”]
Risks or blockers
- [Issue or uncertainty] — [possible effect] — [next step]
- None currently identified. [Use only if that is accurate.]
Request or decision needed
- [Person or team]: [specific action or decision] by [date, if known]
- None currently. [Use only if accurate.]
Hypothetical example: Project: Website content review | Reporting period: [date range] Status: At risk — one section is still awaiting review, which may affect the planned handoff.
Completed
- Drafted the remaining page copy.
Next
- Review revised copy — [reviewer] — [date to confirm]
- Prepare the handoff notes — [owner] — [date]
Risks or blockers
- Review timing is unconfirmed; handoff impact is not yet known.
Request or decision needed
- [Reviewer or team] to confirm the review date by [date].
The example uses placeholders, not a report of a real project. Before sending, check that the status matches the details below it and that every request has a clear next action.
A practical checklist
Put the status and its main reason in the opening line.
Include only meaningful completed work and upcoming actions.
Add owners and dates when known; label unknowns instead of guessing.
Describe each risk with its possible effect and next step.
Make requests specific, directed, and time-bound when appropriate.
Check that the opening status matches the details in the update.
A few more useful answers
Should I include work that is still in progress?
Include it when it affects the project’s status, next step, or timing. Describe what remains and what happens next, rather than presenting unfinished work as completed.
What if I have no risks or requests to report?
Say so briefly only if you have checked and it is accurate, such as “No blockers identified this period.” If something is unknown, label it as unknown rather than implying there is no risk.
How often should I send a status update?
Use the cadence your team or project has agreed on. If there is no set cadence, ask the readers how often they need an update and send one sooner when a material change requires their attention.