How honest should I be about problems?

Very. A report that is always Green quickly loses credibility, and the entire reason to report weekly is to surface risks early enough to act. Mark Amber/Red when warranted, state the risk plainly, and pair it with what you need (a decision, resources, a date change). Honest status builds the trust that makes the report useful.

Why include a "decisions needed" section?

Because it converts a passive update into action. Naming the specific decisions you need — and ideally who should make them and by when — is how a status report actually unblocks work. It is the highest-value section and the one most often left out.

How do I keep it from being ignored?

Keep it short and consistent: same structure, same day, scannable in under a minute. Focus on outcomes rather than activity, anchor progress to the next milestone, tailor depth to the audience (executives want RAG + asks), and link to detail instead of pasting it. If a line does not change what the reader knows or must decide, cut it.

How honest should I be about problems?

Very. A report that is always Green quickly loses credibility, and the entire reason to report weekly is to surface risks early enough to act. Mark Amber/Red when warranted, state the risk plainly, and pair it with what you need (a decision, resources, a date change). Honest status builds the trust that makes the report useful.

Why include a "decisions needed" section?

Because it converts a passive update into action. Naming the specific decisions you need — and ideally who should make them and by when — is how a status report actually unblocks work. It is the highest-value section and the one most often left out.

How do I keep it from being ignored?

Keep it short and consistent: same structure, same day, scannable in under a minute. Focus on outcomes rather than activity, anchor progress to the next milestone, tailor depth to the audience (executives want RAG + asks), and link to detail instead of pasting it. If a line does not change what the reader knows or must decide, cut it.

Weekly Project Status Report

A weekly project status report — overall RAG status, a one-line summary, accomplishments this week, plans for next week, blockers/risks, and decisions needed, so stakeholders get a fast, scannable update.

Live preview

WEEKLY PROJECT STATUS REPORT

Project:     Customer Portal v2
Week of:     June 1, 2026        Prepared by: Sample PM
Overall status:  AMBER (at risk)
Next milestone:  Beta launch — June 22, 2026

SUMMARY
On scope; timeline at risk due to a late third-party API dependency.

ACCOMPLISHMENTS THIS WEEK
   - Shipped account settings page to staging
   - Completed security review (no high-severity findings)
   - Onboarded second front-end engineer

PLANNED FOR NEXT WEEK
   - Integrate payments API once vendor sandbox is available
   - Begin usability testing with 5 customers
   - Finalize launch checklist

BLOCKERS / RISKS
   - Vendor payments sandbox delayed ~1 week (impacts launch date)
   - QA capacity tight during testing window

DECISIONS NEEDED
   - Approve a 1-week launch slip, or cut payments from v2 launch?
   - Sign-off on final scope by Friday

About this template

A weekly project status report keeps stakeholders aligned without a meeting — and the best ones are **short, scannable, and honest**. Lead with an **overall status** (the familiar Green / Amber / Red "RAG" signal) and a **one-line summary**, because most readers want the headline first and the detail only if the headline worries them. Then four sections do the work: **accomplishments this week** (what actually got done — outcomes, not activity), **plans for next week** (so people can flag conflicts early), **blockers and risks**, and **decisions needed**. That last section is the most valuable and the most often omitted: explicitly asking "we need X decided by Friday" turns a passive update into something that moves the project forward. A few principles make these reports trusted rather than ignored. Be **honest about Amber and Red** — a status report that is always Green stops being believed, and surfacing a risk early is the whole point of reporting weekly. Keep it **outcome-focused** ("shipped settings page to staging," not "worked on settings"). Tie progress to the **next milestone and target date** so status is anchored to commitments, not vibes. And keep it **consistent** — same structure, same day each week — so readers can skim it in under a minute and spot what changed. Send it to the people who actually need it, keep the detail proportional to the audience (executives want the RAG and the asks; the team wants specifics), and put longer artifacts behind links rather than bloating the report. A status report is a communication tool, not a record of effort: if it does not change what a reader knows or needs to decide, trim it.

When to use it

Sending a recurring weekly update to project stakeholders.
Summarizing progress, plans, risks, and decisions in one place.
Flagging blockers and escalations early.
Keeping status anchored to milestones and target dates.

What to include

Project, week, owner, and an overall RAG status.
A one-line summary and the next milestone/date.
Accomplishments this week (outcomes, not activity).
Plans for next week and blockers/risks.
Decisions needed, with who/when where possible.

Frequently asked

Red / Amber / Green — a quick signal of project health. Green means on track, Amber means at risk or needing attention, Red means off track or needing escalation. Leading with RAG lets busy readers grasp the situation instantly and decide whether to read further.

⚠ Legal disclaimer. This weekly project status report is a general communication template, not project-management or contractual guidance. Adapt the sections, status definitions, and cadence to your organization's standards and any reporting obligations in your project agreements.

Jurisdiction: General — a weekly project status / stakeholder update report.

Last reviewed: 2026-05

Reviewed by ScoutMyTool — consult a licensed attorney for binding use.