How long should the report be?

Top half-page should be readable in 90 seconds (status, timeline, asks). Full report 1-2 pages typically. Reports over 3 pages often lose senior-stakeholder attention; structure for skimmability with clear headers and short paragraphs. Detailed appendices (technical, financial) can run longer but should be optional reading for engaged stakeholders.

Should I report Green when things are mostly fine?

Reserve Green for genuinely on-track-with-no-concerns. Yellow is your most useful status — minor risks, on track but watch — and signals you're paying attention. Routine all-Green reports lose credibility (no one believes everything is always fine) and stop getting read. Red should be reserved for material risks needing intervention; over-using Red is "crying wolf." Honest Yellow is the sweet spot.

What if my project is genuinely off-track?

Go Red and propose a specific recovery plan. Sponsors prefer "Red, here's what I need to recover" over "Green, all good" followed three weeks later by "we missed the deadline." The earlier Red is called, the more options the sponsor has to help. Late-Red reporting damages PM credibility more than the project being off-track does.

How do I track risks vs issues?

A risk is something that MIGHT happen. An issue is something that HAS happened and is impacting the project now. Track both, but separately: risks have probability + impact + mitigation; issues have actions + owner + due date. When a risk materialises, it becomes an issue. Some teams use a unified "risks and issues log" with a status field; others keep them separate.

Who should receive the status report?

Sponsor (mandatory), project team (mandatory), key stakeholders by role (steering committee, customer-facing teams, dependent teams). Avoid mass distribution — reports broadcast to everyone often go unread by anyone. Build a focused distribution list and adjust as the project progresses. Some teams maintain a public-by-default report (e.g. shared doc) plus an active distribution list for the email cadence.

Project Status Report Template

Structured project status report — status, progress, risks, asks, financials.

Customise

Project name

Project code / ID

Project manager

Sponsor / executive owner

Report date

Report period

Overall status

Project start date

Target completion date

Estimated % complete

Milestones completed (one per line)

Milestones upcoming (next 2-4 weeks)

Progress this period

Risks (one per line: risk | mitigation | owner | severity H/M/L)

Decisions / asks (escalations to sponsor)

Budget — total / spent / remaining (USD)

Team / staffing update

Live preview

PROJECT STATUS REPORT

═══════════════════════════════════════════════════════════════════════

Project:                 Customer Portal v3 Re-platform
Project code:            PROJ-2026-007
PM:                      Priya Patel
Sponsor:                 Maya Chen, VP Engineering
Report date:             May 4, 2026
Period covered:          Week of April 27 – May 3, 2026

   ► OVERALL STATUS:      YELLOW — minor risks, on track but watch

═══════════════════════════════════════════════════════════════════════

TIMELINE

  Start date:                                      February 15, 2026
  Target end date:                                 August 30, 2026
  % complete:                                      35%

═══════════════════════════════════════════════════════════════════════

MILESTONES — COMPLETED

M1 — Discovery + architecture sign-off — DONE 2026-03-10.
M2 — Auth migration to OIDC — DONE 2026-04-15.
M3 — Core data-layer rebuild — DONE 2026-04-28.

MILESTONES — UPCOMING (next 2-4 weeks)

M4 — Account settings + billing UI — target 2026-05-22.
M5 — Customer-facing dashboard rebuild — target 2026-06-10.
M6 — End-to-end load testing + bug bash — target 2026-06-24.

═══════════════════════════════════════════════════════════════════════

PROGRESS THIS PERIOD

Completed M3 (data-layer rebuild) on schedule.
Completed user-acceptance testing on auth migration; no regressions.
Kicked off M4 (account settings UI) — design approved, dev started.
Resolved blocker on legacy-billing-service decoupling: working solution agreed with billing team.

═══════════════════════════════════════════════════════════════════════

RISKS AND ISSUES

Risk                                     | Mitigation                              | Owner   | Sev
──────────────────────────────────────  ──────────────────────────────────────  ───────  ────
Vendor-API rate limits could throttle migration | Negotiated higher tier with vendor; backup plan to stage migration | Sam | M
Key engineer (Riley) on PTO 2 weeks in May | Deferred Riley-owned milestones; Sam covering critical path | Priya | M
Customer-side communication plan for cutover | Drafting comms with Marketing; sign-off needed by 2026-06-15 | Casey | L

═══════════════════════════════════════════════════════════════════════

DECISIONS NEEDED / ASKS

ASK: Approve $25K additional spend for vendor higher-tier API access. Originally $0; vendor offered 2-month trial we accepted; permanent tier needed by June 1.
ASK: Confirm cutover weekend (June 28-29 vs July 5-6). Customer-success prefers June 28 (post-quarter); engineering slightly prefers July 5 (more buffer post-Q2 deploy freeze). Need decision by 2026-05-15 to lock customer comms.

═══════════════════════════════════════════════════════════════════════

BUDGET

Total approved: $480,000
Spent to date: $168,000 (35%)
Forecast at completion: $498,000 (3.75% over original; within 5% contingency)
Variance drivers: $25,000 vendor API tier (pending approval), partially offset by lower-than-budgeted contractor hours.

═══════════════════════════════════════════════════════════════════════

TEAM / STAFFING

Team of 6 engineers + 1 PM + 1 designer. No changes this period.
Riley out for 2 weeks of PTO starting May 12 — coverage plan in place.

═══════════════════════════════════════════════════════════════════════

NEXT REPORT

  Next report date:                                ____________________
  Distribution:                                    Maya Chen, VP Engineering, project team, stakeholders

  Reply to this report by email with questions or escalations.

About this template

A weekly or bi-weekly project status report serves three audiences with different needs in the same document. The sponsor and senior stakeholders need the top-line status (Green/Yellow/Red), the timeline view, and the asks. The project team needs the detailed progress and risk view. Anyone reading the archive needs context to understand what happened. The most-effective format puts the highest-information-density content at the top: status colour, % complete, schedule view; risks and asks immediately below; detailed progress narrative further down. Sponsors who only have 90 seconds get what they need; team members who want detail can scroll. The Green/Yellow/Red status is the most-watched element by leadership — Yellow is the most useful (signals concern early enough to help; less alarming than Red); Green-everywhere reports become wallpaper and trigger no engagement. Don't game the colour: Green for an at-risk project loses credibility once the risk materialises. Red for a fixable issue mobilises help. Risks should be specific (named risk, named mitigation, named owner, severity) rather than handwavy ("scope is a risk"). Asks should be explicit ("$25K additional spend for vendor X by date Y" rather than "we need more money"). The audience response to status reports is the test of whether the report works: silence usually means the report was unread (or worse, unread routinely); questions and decisions in response mean the report was useful. Adjust format and depth based on what the sponsor and team actually engage with.

When to use it

Weekly or bi-weekly recurring project updates.
Monthly portfolio review across multiple projects.
Stage-gate or milestone-completion reviews.
Steering-committee or sponsor escalations.
Year-end retrospective preparation.

What to include

Project identification (name, code, PM, sponsor, dates).
Overall status (Green/Yellow/Red) and % complete.
Recent and upcoming milestones.
Progress narrative for the period.
Risks with mitigations, owners, severity.
Decisions needed / asks.
Budget vs forecast.
Team / staffing update.

Frequently asked

Weekly is the most common cadence for active projects with sponsor attention. Bi-weekly works for slower-moving projects. Monthly is too infrequent for any active project (risks materialise faster than monthly reports catch them). Daily is too frequent except in crisis or final-cutover weeks. Fix the cadence at project kickoff and stick to it.

⚠ Legal disclaimer. Project status reporting is operational best practice rather than regulated. Public-company project reports may have additional disclosure obligations (Sarbanes-Oxley around material projects affecting financial reporting; SEC disclosure for projects material to operations). Government contracting projects may follow EVM (Earned Value Management) requirements specified by the contract. For most internal corporate projects, the format above suffices.