Email Template For Project Update

A useful project update email answers four questions quickly: What changed since the last update? What is the current status? What might affect the plan? What happens next, and who owns it? Keep the message tied to a specific project and reporting period, separate completed work from planned work, and state blockers plainly. A concise update helps teammates and stakeholders act without having to reconstruct the project from scattered messages.

There is no single format for every team. A small internal project may need a short weekly note, while a client update may need a milestone summary, decisions, and a date for the next check-in. Follow the team’s agreed reporting cadence and use the same headings from update to update so readers can scan for changes.

Gather the facts before you write

Check the task board, project plan, notes, and owners before drafting. Confirm which work is complete, which work is underway, and which items have not started. If a date or percentage is uncertain, label it as an estimate or leave it out. Do not report activity as an outcome: “We held two planning meetings” describes work, while “The team approved the launch requirements” tells readers what changed.

Decide what the audience needs. A project team may need task owners and immediate blockers. An executive may need milestones, material risks, and decisions. A client may need progress against scope, dependencies, and a clear next step. If one email serves several audiences, put a short summary first and details below it.

A simple structure for a project update

1. Subject: identify the project and the reporting date or week.
2. Opening summary: give the overall status in one or two sentences and mention any important change.
3. Completed: list the meaningful work finished since the last update.
4. Next: name upcoming tasks, owners, and dates where they are confirmed.
5. Risks or blockers: explain the issue, its impact, and what is being done.
6. Decisions needed: state who needs to decide, by when, and what happens if the date slips.

Use status labels only if the organization defines them. If your team uses green, yellow, and red, explain what the labels mean and apply them consistently. If no shared system exists, write a plain-language status such as “On schedule for the planned review” or “At risk because approval is still pending.” Avoid a green label that hides a serious unresolved dependency.

Template: routine team update

Template: client or stakeholder update

Template: project delay or blocker

How to report risks and changes

Describe a risk in terms of cause, likelihood if known, impact, owner, and next action. Do not dramatize it or bury it in a long narrative. For example: “Vendor approval is pending. If it is not received by May 8, configuration may move from May 10. Jordan will contact the vendor today and confirm the schedule on May 7.” This gives readers something to monitor and a person to contact.

If the plan has changed, show the previous date and proposed date, and say whether the change is confirmed. If you do not yet know the effect, say that you are assessing it and provide a time for the next update. Avoid inventing a new deadline simply to make the email sound decisive.

Make the update readable and actionable

• Use short headings and bullets for multiple workstreams.
• Put requests and decisions near the top, with the owner and due date.
• Link to the canonical project document or board rather than attaching duplicate files.
• Keep detail proportional to the audience; move task-level lists to the project tool.
• Use absolute dates when a phrase like “next Friday” could be misunderstood.
• Close the loop when a blocker clears or a decision changes the plan.

Do not use an email update to replace the agreed system of record. If project status lives in a shared board, update that record and use the email to summarize meaningful changes. For a wider range of work situations, see these business email examples. When you have received a project request and need to confirm receipt or a next step, the acknowledgement email samples cover that separate task. If you are waiting on information, use a clear gentle reminder email.

Common mistakes

• Sending a long activity log without stating the project’s current position.
• Listing risks without naming the impact, owner, or next check.
• Calling work “complete” when review or acceptance is still outstanding.
• Copying people who do not need the update or action.
• Using inconsistent labels or dates that make progress hard to compare.
• Promising a delivery date that has not been approved.

FAQ

How often should I send project updates?

Use the cadence agreed by the team or stakeholders. Weekly is common for active work, but a milestone-based schedule may fit shorter or slower projects better. Send an unscheduled update when a material change needs attention.

Should I include a status color?

Only if the organization has a shared definition for each color. Include a short explanation of the risk or status so the color never has to carry the message by itself.

What if there is no progress to report?

Say what was expected, what prevented progress if known, and what will happen next. “No update” alone does not help the team plan.

Should a project update be an email or a meeting?

Email works well for a concise, documented status. Use a meeting when the team needs discussion, trade-offs, or a live decision. You can send a short written summary afterward to record owners and next steps.

Final checklist

• The subject identifies the project and update period.
• The opening states current status and material changes.
• Completed work is distinct from future work.
• Each blocker has an impact and next action.
• Requests name an owner and a confirmed date.
• Links point to the current source of truth.