Send a Project Status Update When There Is No Decision to Request

Make the purpose clear before the details

Use a subject line that identifies the project and the reporting period. For example, “Project Cedar — status update for [date range]” tells recipients what the message covers without suggesting that they must respond.

Then state the purpose in the opening sentence. If useful, say directly that no decision or approval is requested. This is especially helpful when a risk or delay appears later in the email: readers can distinguish information they should know from a question they need to answer.

Keep status in three distinct parts

Describe completed work as finished only when it is actually complete. Name the deliverable or milestone and, where relevant, say what completion means. “Draft delivered to the review folder” is more precise than “draft done” if review remains outstanding.

For current progress, describe what is underway and what remains. Avoid language such as “on track” unless you can connect it to a known milestone or date. If timing is uncertain, say so rather than making a confident-sounding promise.

For a risk, explain the potential effect and the next monitoring step. A risk is not automatically a request. If you need help, a decision, or a change in priority, name that explicitly; otherwise, make clear that you are reporting it for awareness.

Editable update

Replace every bracketed field and remove any line that does not apply. Keep the no-decision sentence only if it accurately describes the message.

• Use a real recipient address in place of the fictional example address.
• Delete claims about dates, owners, or mitigations that you have not confirmed.

To: [recipient name] <[recipient]@example.com>
Subject: [project name] — status update for [date range]

Hi [name/team],

This is a status update for [date range]. No decision or approval is requested at this time.

Completed
- [deliverable or milestone] — completed on [date]; completion means [brief definition or handoff].

In progress
- [work item] — [current state]. [Owner name] is handling the next step, [specific action], by [date, if confirmed].

Known risk
- [risk] may affect [deliverable, timing, or scope]. We are [monitoring or mitigation step], owned by [owner]. I will share an update by [date or milestone, if known].

This update is for visibility. I’ll raise a separate request if a decision or support is needed.

Best,
[sender name]

Describe risks without implying a hidden ask

A risk statement should help readers understand what could happen, not force them to guess what you want. For example, “The supplier’s revised delivery date is not confirmed; [owner] is checking it, and the schedule impact is not yet known” reports a concern without implying that the recipient must intervene.

Avoid ending a no-decision update with a vague question such as “Thoughts?” It can sound like a request for review. If you want feedback, specify what kind and by when. If you do not, close with a neutral note about when the next status update is expected, provided that timing is known.

Check dates and ownership before sending

Dates are easy to misstate when notes come from different people or time zones. Check the reporting period, completion date, upcoming milestone, and any promised follow-up against the current project record. Use a clear date format and include a year when the context could be ambiguous. If a date is only an estimate, label it as estimated rather than presenting it as settled.

Confirm that each named owner has responsibility for the work described. Do not assign another person a commitment they have not agreed to, and distinguish the person doing the work from someone who is merely being informed. If ownership is unresolved, say that it is unassigned or being confirmed.

• Does the subject line match the period covered?
• Are completed items truly finished, with any handoff or review status explained?
• Are progress and risk owners correct, and are their dates confirmed or clearly qualified?
• Does the message say whether a decision is requested—and is that statement accurate?
• Do recipients know when or under what condition they should expect another update?

Confirm the message does what you intended

Before sending, read the email from the recipient’s perspective. Look for accidental asks: a question mark, an unassigned action, or wording such as “please review” may create work even if the opening says no decision is needed. Remove or clarify those lines.

After sending, confirm that the message appears in your sent mail and that the intended recipients are listed. If a recipient replies as though approval is pending, clarify whether you need a response and correct the wording in the next update. A status email is useful when its purpose, facts, and ownership are clear—not merely because it has been sent.