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
Related templates
More tools you might like
Hand-picked tools that pair well with this one — same audience, same intent.
A project charter for kickoff — purpose/objectives, in-scope and out-of-scope, stakeholders, milestones/timeline, budget, and success criteria — to authorize the project and align everyone before work starts.
A project post-mortem / lessons-learned document — what went well, what did not, root causes, and recommended action items with owners, captured after a project or incident so the team improves next time.
A Start / Stop / Continue sprint retrospective worksheet with an action-items section (owner + due date) and team/date header.
Structured project status report — status, progress, risks, asks, financials.
A QA bug report — title, severity/priority, environment, numbered steps to reproduce, expected vs. actual result, and attachments — structured so a developer can reproduce and fix the issue fast.
A travel expense report with mileage — trip details, categorized line items (lodging, meals, transport), an IRS-rate mileage reimbursement, a receipts checklist, and an automatic total.
A daycare daily report for parents — meals and how much was eaten, naps, diaper/bathroom log, activities, mood, supplies needed, and notes from the caregiver.
Enter weekly readings (weight, body-fat, waist, etc.) — get a printable trend report PDF with totals and per-metric change.