The Weekly Status Report

The last template, the project charter, defined what a piece of work is for and what “done” means. This one keeps the people who care about that work informed while it happens — every week, in writing, without a meeting. Where the charter is written once at the start, the status report is written again and again, and its whole job is to let a busy reader know where things stand in the time it takes to drink half a coffee.

This is a reference page. It gives you a blank template you can copy into a doc today, a short guide to using it well, and a filled-in example a busy executive could read in thirty seconds. If you want the deeper reasoning behind why updates fail and how to write ones that inform, that lives in Status Updates That Actually Inform; this page is the portable form of it.

What it’s for

A weekly status report exists to do two things for the reader, and only two: reduce their uncertainty (they now know where things stand without asking you) and surface what needs their attention (a decision, a risk, or a thing you need from them). If a line in your report does neither, it is not informing anyone — it is spending their time.

That framing rules out the most common kind of report: a diary of activity. “Attended three meetings, updated the tracker, chased the vendor” is all true and all useless, because none of it tells the reader whether the work is fine or whether they need to do anything. The template below is shaped to make the useful version easy and the diary version hard.

The template

──────────────────────────────────────────────────────────
WEEKLY STATUS · <project or team name> · <date>

OVERALL: 🟢 Green  /  🟡 Amber  /  🔴 Red
Headline: <one sentence — the single most important thing
           the reader needs to know this week.>

PROGRESS SINCE LAST WEEK
  • <finished or newly-known thing — an outcome, not effort>
  • <finished or newly-known thing>

RISKS & BLOCKERS
  • <risk or blocker> — <impact> — <what we're doing about it>
  • <blocker> — <who/what it needs to move>

WHAT I NEED FROM YOU
  • <explicit ask> — from <whom> — by <when> — or <consequence>
  (If nothing: write "Nothing this week — no action needed.")

NEXT UPDATE: <date>
──────────────────────────────────────────────────────────

Five parts, each earning its place:

• Overall status color — a single traffic-light word so a reader scanning ten reports can triage yours in one second.
• Headline — the one sentence that carries the answer, so someone who reads nothing else still knows the most important thing.
• Progress since last week — what genuinely moved, measured in finished outcomes, not hours spent.
• Risks & blockers — what could push the work off plan, and what’s stopping it right now.
• What I need from you — the explicit asks, with owners and deadlines. This is often the whole reason to send the report.

How to use it

Set the color honestly — red/amber/green

The color is the most valuable single character in the report, and the easiest to corrupt. Its meanings are fixed:

🟢 Green   On track. Going to plan. You can stop reading and stop worrying.
🟡 Amber   At risk. Something could push us off plan. Keep half an eye here.
🔴 Red     Blocked or off plan. Needs a decision or help to recover.

There is a strong gravitational pull toward green — it feels good to report, avoids awkward questions, and buys another week. Resist it. The color is a signal, and a signal that is always green until the day the project explodes carries no information at all. An amber flagged three weeks early, honestly, is worth far more than a green that holds until the deadline arrives empty, because early amber lets people act while there is still time to act.

The honesty principle in one line: surface bad news early and specifically, rather than burying it. “Amber — the data migration may push the launch a week; here’s the fix in progress” is a gift to the reader. “Green” followed three weeks later by “actually, we’ve slipped a month” is a betrayal of the reader’s trust, and after it happens once they will discount every color you ever send.

The common trap — watermelon status

A report that shows green on the outside while the work is red on the inside is called a watermelon. It grows wherever reporting green is rewarded and reporting risk is punished, so people show the color that keeps them comfortable rather than the color that is true. Watermelon status always ends the same way: a long, reassuring run of green, then a sudden, shocking miss that surprises everyone. The fix has two halves. As the writer, tell the truth even when green is tempting. As a reader of other people’s reports, react to early bad news with help rather than blame — punish the first honest amber and you train everyone around you to hand you watermelons.

Write for someone who wasn’t in the room

Assume your reader missed every meeting, will not chase you for context, and will not ask a single follow-up question. Whatever the report doesn’t say, they simply won’t know. This changes how you write in three concrete ways:

• Spell out the acronyms and the context. “Blocked on the CAB” means nothing to a reader outside your team. “Blocked on the change-approval board, who meet Thursdays” tells them what’s happening and when it clears.
• Say the consequence, not just the fact. “Vendor is late” is a fact. “Vendor is two weeks late, which pushes our go-live to March unless we swap suppliers” is something a reader can act on.
• Make every ask self-contained. A request the reader has to decode — “we’re waiting on budget approval” — gets read and forgotten. A request they can answer without a meeting — “I need your sign-off on the £4k contractor by Thursday, or we slip a week” — gets action.

The test: hand your draft to someone with no context on the project. If they can tell you the state, the risks, and what’s being asked of the reader, it works. If they have questions, those questions are the holes the report needs to fill before you send it.

The evidence — front-loading the answer

Organizations that read a lot of written updates tend to converge on the same discipline: lead with the conclusion, then support it. Amazon’s well-known narrative-memo culture, adopted in the early 2000s, is one version — documents open with the key points and are read in silence before discussion. The lesson for a status report is the same in miniature: a busy reader skims, and many read only the first line or two. So the color and the headline must carry the answer on their own. If the reader saw only your first two lines, they should already know whether to worry and whether to act.

Report outcomes, not activity

Under “Progress since last week,” write things that are finished and verifiable, not things you worked on. “Checkout now ships and passes testing” is an outcome. “Worked on checkout” is activity — it could mean nearly done or barely started, so it tells the reader nothing. A team can log a heroic, exhausting week and be no closer to done; another can coast quietly and land early. Effort is not status. Before you send, cut every progress line that logs work but names no result.

A filled-in example

Here is the template completed for a realistic situation — a website replatform for a mid-sized retailer, reported by the project lead to the sponsor. A busy executive can read it in about thirty seconds and know exactly where things stand and the one decision they owe:

──────────────────────────────────────────────────────────
WEEKLY STATUS · Website Replatform · Mon 6 Jul

OVERALL: 🟡 Amber
Headline: On budget and mostly on track, but the payment
          migration is at risk of slipping the 1 Aug launch
          by ~1 week. I need one decision from you by Thu.

PROGRESS SINCE LAST WEEK
  • New product pages live in staging and signed off by
    the merchandising team.
  • Search rebuilt; now returns results in under a second
    (was ~4s on the old site).
  • Payment provider contract signed — integration started.

RISKS & BLOCKERS
  • Payment migration — the old system stores card records
    in a format the new provider rejects. Cleaning them is
    slower than planned; this is what puts 1 Aug at risk.
    We've added a second engineer and are testing a fix.
  • Content freeze — marketing are still editing pages we
    need frozen to test. Blocking full end-to-end testing.
    Needs the marketing lead to lock content by Wed.

WHAT I NEED FROM YOU
  • A decision by Thu on the payment risk:
      Option A — hold the 1 Aug date, launch without saved
                 cards, add them in a fast follow-up.
      Option B — move launch to ~8 Aug, launch complete.
    I recommend A; saved cards affect <5% of checkouts.
  • A nudge to the marketing lead to hit the Wed content
    freeze (I've asked; a word from you would land harder).

NEXT UPDATE: Mon 13 Jul (or sooner if the payment fix fails)
──────────────────────────────────────────────────────────

Notice what it does. The color and headline carry the whole answer in the first three lines. Progress is written as finished outcomes with evidence (“under a second, was ~4s”), not “worked on search.” The risk names its impact and the mitigation already underway. The ask is a genuine decision with framed options, a recommendation, and a deadline — not a vague “please advise.” And it contains no list of meetings attended and no “the team worked really hard.” Every line lowers the reader’s uncertainty or asks for something.

The common trap — the report that only ever says green

Two report styles quietly destroy trust, and they often live in the same document. The first is the activity diary — a list of what the team touched this week, which reads as busy but tells the reader nothing about state. The second is the permanent green — a status that never wavers because the writer treats amber and red as admissions of failure rather than as the early-warning system they are. Both fail the same test: they leave the reader unable to tell whether the project is actually fine. If your last several reports were all green and all full of activity, that is not a sign things are going well; it is a sign the report has stopped carrying information. Write the amber the week you first smell the risk.

When not to use it

Skip the full weekly report when there is genuinely nothing to inform or ask — sending an empty ceremony every Friday just trains people to stop reading, so your real signals drown when they finally come. And when something is blocked right now and needs a decision today, don’t wait for the weekly slot: a red that can’t wait belongs in a fast channel — a message or a quick call — not buried in an email nobody opens until the weekend. The weekly report is for the steady drumbeat; urgent bad news travels on its own.

How it connects

This template is the recurring companion to the project charter: the charter defines “done,” and the status report tracks the journey toward it. When a report’s red is something your reader can’t resolve alone, it becomes the trigger for a decision document to capture the choice and its reasoning. And the “what I need from you” section only works if it’s clear who can actually say yes — which is exactly what a RACI matrix makes explicit. The full reasoning behind honest signals and reader-first writing lives back in Status Updates That Actually Inform.

Try this

Take the next status update you’d normally send and rebuild it to this template before sending. Put an honest color and a one-sentence headline at the very top. Split the body into progress (finished outcomes only — delete every line that just logs effort), risks and blockers, and what I need from you (with owners and deadlines). Then run the two tests: hand it to someone with no context and see if they can state where things stand; and check that if the reader saw only your first two lines, they’d know whether to worry and whether to act. If your honest color this week is amber or red, that is a good sign — it means the report is doing its job.