Project status update examples for clear weekly reports

---

title: 'Project status update examples for clear weekly reports' date: '2026-10-20T16:02:51-07:00' description: 'Make your next project status update easier to act on. Use a complete weekly report example, a reusable template, and clear wording for progress, risks, delays, and decisions.' tags: [ 'project status update', 'project status update examples', 'weekly project report', 'project status report template', 'how to write a project update', 'weekly update email', 'client project update', 'project progress report', 'status report writing', 'reporting project delays', 'project risk communication', 'project decision requests', 'team communication', 'client communication', 'freelance project management', 'small business writing', 'business writing', 'clear writing', 'professional email writing', 'better writing', ] image: '' status: 'published'

"We made good progress this week" sounds reassuring until someone asks whether the launch is still on time. A list of meetings and completed tasks may show that people worked hard, but it can leave the reader unsure what has changed or whether they need to help.

A useful project status update gives the reader enough information to judge the current plan. It says what is finished, what remains uncertain, and which action comes next. For a freelancer, a small business owner, or a team lead, that can mean a short weekly email rather than a long formal report.

The examples below follow a fictional website project so you can see how the wording works across a normal week, a risk, and a confirmed delay. Use the structure with your own facts, dates, and agreed way of reporting. The aim is to make the next decision easier, even when the news is uncomfortable.

Decide what the reader needs to know this week

Before drafting, look at the last update and the current plan. Identify the changes that affect the next milestone, the agreed work, the cost, or a decision someone must make. These changes deserve space before the smaller tasks that filled your day.

For example, a client may need to know that the first four pages are ready for review and that one missing photo could delay the fifth. They probably do not need a full account of how you moved files or arranged your work. Keep those details in your task notes unless they explain a problem the reader needs to understand.

Write a rough answer to four questions:

• Can we still meet the next agreed milestone?
• What changed since the previous report?
• What could stop the next stage, and what are we doing about it?
• Who needs to decide or do something, and by when?

Those answers form the core of a weekly report. Atlassian's weekly project update guidance also recommends recording completed work, needs, next steps, and relevant decisions or risks. Your report can stay simple while making those details visible.

Put the current position in the opening

The first sentence should tell the reader where the project stands against an agreed target. Give the report a date or reporting period so the reader can tell how current it is. A subject such as "Website update: October 20, photo choice needed" is more useful than "Weekly catch-up."

Compare these two openings:

Work is moving forward, and we have been making good progress on the website. There are a few things to work through, but we are keeping an eye on them.

The October 30 website launch is at risk because the homepage photo is still undecided. We can keep that date if the client approves an available image by October 22.

The second version gives the reader a target, a problem, and a condition for keeping the plan. It does not claim the date is safe just because most tasks are finished. If the launch is secure but one optional page is late, describe that narrower issue instead of making the whole project sound uncertain.

Some teams use green, amber, and red labels. If you use colors, add words such as "On track," "At risk," or "Delayed," and agree on what those labels mean. A color alone cannot explain whether you need a small choice today or a new project plan.

Describe finished work with a clear end point

Progress becomes easier to judge when you explain what is ready and what it allows the team to do next. "Worked on page copy" could mean a first draft, a complete review, or ten minutes of notes. "The client approved the service page copy, so the designer can place it in the page layout" has a clear end point.

Choose a few meaningful changes instead of copying every checked task from your task list. If an item has not reached the agreed finish, use a precise label such as "Draft ready for review" or "Testing in progress." Avoid calling something complete when a required review still stands between it and use.

Counts can help when their meaning is clear. "Four of five page drafts are approved" tells the reader more than "The project is 80 percent complete." The remaining page may take longer than the other four, and drafting may be only one stage of the wider project. Do not turn a task count into a promise about time remaining.

If nothing reached completion during the period, say what changed in the work that is underway. You might explain that a test ruled out one cause of an error and that another check is due tomorrow. That gives an honest account without dressing activity up as a finished result.

Separate a possible problem from work already blocked

A risk is something that might affect the plan. A blocker is already preventing a particular task from moving forward. Keeping that difference clear helps the reader judge how soon to act and what kind of help would be useful.

In the website example, a missing homepage photo may be a risk while the team works on other pages. It becomes a blocker when the designer reaches the final homepage layout and cannot finish it without the image. Name the affected task rather than saying the entire project is blocked when useful work can continue elsewhere.

For each important problem, include its effect, the next action, and the person handling that action. A useful note might read:

The final homepage layout is waiting for an approved photo. Priya will send two available image options on October 21. We need the client to choose one by October 22 to keep the October 30 launch plan.

This wording reports the gap without guessing why it happened. "The client is being slow" adds judgment while leaving the solution unclear. If your own team missed a task, name that just as directly and explain the repair plan.

Be careful with "No risks." It can sound like a guarantee about the future. When accurate, "No new risks identified in this review" describes what you checked. If an older risk remains open, keep it in the report and say whether its position has changed.

A complete weekly project status update example

Here is a fictional email sent on October 20. The team has approved copy for four pages of a five-page website, and the homepage photo is still open. All dates and names are examples, not a record of a real client project.

Subject: Website update: October 20, photo choice needed

Hi Lena,

The October 30 website launch is at risk because we still need to choose the homepage photo. The date remains possible if you approve an available image by Thursday, October 22.

Finished since the last update

Copy for the About, Services, FAQ, and Contact pages is approved. The designer can now complete those four layouts. The homepage text is also ready for your review.

Decision needed

Please choose an image from the two options Priya will send on Wednesday, October 21. We recommend using an existing image for launch because a new photo session would need a separate schedule. Please confirm your choice by 3 p.m. Vancouver time on Thursday, October 22.

Next work

Priya will finish the four approved page layouts by October 23. Once the homepage text and photo are approved, she will finish that layout by October 26. Alex will then check the pages and contact form before the final client review on October 28.

Other open items

Please review the homepage text by October 22 as planned. No change to the agreed five-page scope or fee is proposed in this update.

I will confirm the launch outlook after the photo decision on October 22. If the image is still open then, I will send a revised schedule for us to agree.

Thanks, Alex

The opening puts the risk before the good news. The report also separates completed work from planned work, names who will act, and explains when the next update will arrive. It gives the client a decision without presenting an unapproved change as settled.

In a real message, link to the current copy and image options where you mention them. Check that the client can open those files and that the names make sense outside your team. A report that says "review the latest version" loses value if three files all look current.

Change the wording when the project changes

The example above describes a launch that is still possible. If the photo choice misses its latest workable date and the current plan can no longer meet October 30, change the status. Repeating "at risk" after a delay is confirmed makes the report less useful.

A clear delay note might say:

The October 30 launch will be delayed. The photo was not approved by October 22, so we could not complete the homepage layout in its scheduled slot. We propose November 4 as the new launch date, subject to photo approval by October 27 and your agreement to the revised review dates.

This names the original date, the missed condition, and the proposed next plan. The new date is clearly a proposal with conditions. Do not describe it as confirmed until the people responsible for the work and approval have agreed to it.

If your team caused the delay, use the same level of detail:

We need to move the launch because our contact form test found an error we have not yet fixed. Alex is checking the cause and will confirm the repair and testing schedule on October 23. Until that check is complete, we cannot give a reliable replacement launch date.

An update can be useful without a firm new date. Say what remains unknown, who is investigating, and when the reader will hear more. A guessed date may feel reassuring now but creates another problem if people begin planning around it.

Replace soft phrases with facts the reader can use

Vague wording often enters a report when the writer wants to sound calm. You can keep a respectful tone while using clear facts. The following examples show how to make the information more useful without making the message harsh.

Replace a soft phrase only with information you can support. If you do not know when a task will finish, report the next check rather than inventing a deadline. Clear writing includes uncertainty when that uncertainty affects the plan.

A project status update template you can reuse

Keep the labels that help your reader and remove sections that do not fit the work. A small internal project may need one paragraph and three bullets. A client project with several open decisions may need a longer note with links to the current plan.

Project and report date: Name the work and the period covered.

Current position: State whether the next agreed milestone is on track, at risk, delayed, or paused. Give the main reason and name the milestone date.

Changes since the last update: Describe the most useful completed work, approved changes, or new findings. Say what is ready for use or review.

Risks or blockers: Explain the affected task, the likely or confirmed effect, and the action being taken. Name who owns that action.

Decision needed: Ask a named person for a specific choice or approval. Include the relevant file, a real deadline, and the effect of waiting.

Next work: Name the next tasks, their owners, and their expected dates. Distinguish confirmed plans from proposals.

Next update: Say when you will report again, especially if you are checking an urgent problem before the normal weekly report.

If there is no decision for the reader, say "No action needed from you this week" when that is true. This lets someone read an information update without wondering whether they missed a hidden request. Keep a real request near the top when a deadline is close.

For teams, it helps to assign one person to send the final report. Other people can supply facts, but a single owner can check that the dates and status agree across sections. Avoid combining several unreviewed task notes into a message that contradicts itself.

Check the report against the plan before sending

Read the finished update once as someone who has not watched the work all week. Can you identify the next milestone, understand its current position, and find any action assigned to you? Then check the dates against the actual plan rather than relying on memory.

Use this final review:

• Does the opening describe the same status as the detail below it?
• Are completed, planned, and proposed items clearly different?
• Does each important open problem have an owner and a next action?
• Can the person named in a request actually make that decision?
• Do deadlines include a time zone when readers work in different places?
• Are linked files current and available to the people receiving the update?
• Have you carried forward unresolved issues from the previous report?
• Is the next update date clear if more facts are still being checked?

A weekly report should not hold urgent news until the end of the week. If a confirmed problem changes a decision someone needs to make today, send a short update through the agreed project channel. Add the result to the next regular report so the record stays complete.

If a decision request later needs a reminder, write a separate follow-up email after no response that points to that request. Keep the weekly update focused on the state of the whole project so it remains useful to everyone following the work.

Start your next report by comparing this week with the last agreed plan. Choose the change that most affects the reader, put it in the opening, and support it with finished work, open problems, and clear next actions. Before you send, picture what the reader can now decide. If that answer is still unclear, revise the request or add the missing fact.