Weekly Project Status Report: Format and Filled Example

Use the same layout every week so readers know where to look:

1. Status: red, amber or green for the overall project, with one sentence on why.
2. Progress since last week: three to five bullets on what finished.
3. Plan for next week: three to five bullets on what's next.
4. Risks and blockers: each with an owner and a date it needs resolving by.
5. Decisions or help needed: each written as a question with a deadline.
6. Milestones: next two or three, with dates and any change since last report.

Add budget or hours only if the reader needs them each week. For some projects that's a line in the header, and for others it's a monthly item. Keep every section short; the goal is a scan, not a read.

Colors are only useful if they mean the same thing every week and across projects. Write the definitions down and put them at the bottom of the template:

• Green: on track for the committed date, scope and budget, with no unresolved blockers.
• Amber: a risk could move the date, scope or budget, and you have a plan to handle it, but it needs watching.
• Red: the committed date, scope or budget will be missed unless someone outside the project team acts.

The red definition matters most: red means you need help. When teams treat red as a failure, they stay amber until the last week, and the report loses its value as an early warning. Say clearly that amber and red are normal, and that a project always green for six months is probably not reporting honestly.

Here's a compact example for an imaginary website migration:

Status: Amber. The content review is two days behind because legal hasn't returned the privacy page.

Done this week: Migrated the blog and resources sections. Finished redirect map for the top pages. Completed accessibility check on templates.

Next week: Migrate product pages. Run the full redirect test. Start staff training.

Risks: Legal review of the privacy page is late. Owner: Legal lead. Needed by: Wednesday, or the launch slips one week.

Decision needed: Approve moving launch to the following Tuesday if legal misses Wednesday. Needed by: Thursday.

Milestone: Launch, scheduled for the 24th, unchanged unless the risk above triggers.

The reader can see the situation, the cause, the deadline and the choice in about thirty seconds.

Don't write from memory. Pull the report from the project's task list: completed tasks become progress, and tasks scheduled for next week become the plan. Then add the three items only a human can supply: the status color and reason, the risks, and the decisions needed.

Set a fixed day and time to send it, such as Thursday at noon, so readers can expect it. Send it to the same people every time, with a link to the full plan for anyone who wants detail. Tools like Asana and Monday.com can generate a status view from tasks and milestones, which cuts the assembly time, but the judgment about color and risk stays with you. Send the project intake form link to anyone asking for new work through the report instead.

The weekly report serves the project team and immediate stakeholders. Leadership doesn't need every project's report, only the exceptions. Roll up red and amber projects into the leadership team scorecard and the monthly review described in the operating cadence template. Track measures that span projects, such as on-time delivery, on the operations KPI dashboard.

If a report goes unread for a month, ask a reader what they'd change. Often the fix is cutting sections, not adding them.