Sooner or later someone asks you to send "a quick weekly update" on a project. Often it's the first management-shaped task you're given, before you have the title. So you write a list of everything the team did, send it on Friday afternoon, and nobody replies. A month later your manager is surprised by a delay you mentioned in bullet nine of three separate emails. The update went out, but nobody took in what it said.
A status update has one job: the people reading it should know whether they need to do anything, without having to ask. This post gives you a template that does that job, a worked example, and a few rules for the hardest part, which is reporting bad news.
Who reads it, and what they want
Before you write anything, list the readers. For a typical project update there are three kinds:
| Reader | What they want from the update | What they don't need |
|---|---|---|
| Your manager | Are we on track, is anything going to surprise them, do you need their help | Ticket-level detail |
| Stakeholders (product, other teams, sales) | When can they rely on the thing, does anything change their plans | How the work is being done |
| Your own team | Is the picture they see the same one leadership sees | A recap of work they did themselves |
Most of these people will read the first two or three lines and stop. That isn't rudeness; they get a dozen of these a week. So the update has to work when it's read the way it will actually be read: the top of it, quickly, on a phone.
This is the same idea Barbara Minto teaches in The Pyramid Principle: put the conclusion first, then the reasons that support it. Military writers call the same habit "bottom line up front". A status update is the most ordinary place to practice it.
The five-part template
Use the same structure every week, in the same order. Consistency matters more than elegance: readers learn where to look, and a change in the structure becomes a signal in itself.
- Status in one line. A color and a sentence. "Green: on track for the March 14 beta."
- What changed since last week. Only what changed: a date, the scope, a risk, a decision. If nothing changed, say "No changes to scope or dates."
- What we need from you. A specific request, with a name and a date. "Priya: we need a decision on the EU data region by Wednesday, or the migration slips a week." If you need nothing, leave the section out rather than writing "nothing".
- Risks we're watching. Two or three at most, each with what you're doing about it.
- Progress, briefly. What finished this week and what's next, in three to five bullets. Link to the board for anyone who wants the detail.
Notice the order. The list of what got done, which is what most first updates consist of entirely, is last. It's the part readers need least, and it's there mainly so the team's work is visible.
A plain-text skeleton you can copy:
Project: [name] — week of [date]
Status: [Green / Amber / Red] — [one sentence: on track for what, or what's at risk]
Changed since last week: [dates, scope, decisions, new risks; or "No changes"]
Need from you: [name: request, by date]
Risks: [risk — what we're doing about it]
Done / next: [3–5 bullets] — full board: [link]
Before and after
Here is a hypothetical update for a team building a new checkout flow, written the way first updates usually are:
Hi all, here's this week's update. We finished the address form and the card validation. Sam worked on the payment provider integration, which is taking a bit longer than expected because their sandbox has been unreliable. We also fixed four bugs from the last release and had a good session on the design for saved cards. Next week we'll keep going on the integration and start on the confirmation page. We're still waiting on legal for the terms text. Let me know if you have questions.
Everything important is in there. Two problems that could move the date are buried in the middle and the end, phrased so gently that a skimming reader would conclude all is well.
The same facts, using the template:
Status: Amber — the April 2 launch is at risk by up to a week.
Changed since last week: Payment provider integration is about four days behind plan because their test environment has been down intermittently. Saved cards design is agreed.
Need from you: Jordan (legal): final terms text by March 20. Without it we can't finish the confirmation page.
Risks: Provider sandbox — we've raised a support ticket and are building against recorded responses in the meantime. If the sandbox isn't stable by Friday, we'll ask the provider for a dedicated test account.
Done / next: Address form and card validation done. Four bugs from the last release fixed. Next: finish integration, start confirmation page.
It's no longer, and the reader who stops after the first line still gets what matters.
Make the colors mean something
A green-amber-red status is only useful if everyone agrees what the colors mean. Without definitions, each person who writes an update picks a color based on mood, and projects stay green until the week they turn red. People sometimes call these watermelon projects: green on the outside, red inside.
Write the definitions down once and put them at the bottom of every update, or link to them:
- Green: We expect to hit the committed date and scope. No help needed.
- Amber: The date or scope is at risk, we have a plan to recover it, and we'll know by [date] whether it worked.
- Red: We will miss the date or scope unless something changes that the team can't change alone. A decision or help is needed.
Two rules make this work. First, amber needs a date by which it turns green or red; a project that's amber for six weeks is red. Second, the color reflects your honest expectation, not your effort. A team working very hard on a project that will miss its date is still red.
Bad news goes first, and early
The temptation, especially when you're new, is to hold bad news until you have a fix, or to wait one more week in case the team catches up. The study guide's advice on timelines applies directly: when a date will slip, say so promptly, with the reason and a revised plan.
The reasoning is practical, not moral. A slip reported three weeks before the date gives your manager and stakeholders options: move the launch, cut scope, add help, warn a customer. The same slip reported two days before gives them none. And people forgive late projects far more readily than they forgive being surprised.
When the news is bad, a short structure helps:
Status: Red — the April 2 launch will slip to around April 9.
Why: The payment provider's test environment has been unavailable for most of two weeks, and the integration can't be finished without it.
Options: (a) Launch April 9 with full scope. (b) Launch April 2 without saved cards, add them April 16.
Need from you: Alex, a decision between (a) and (b) by Thursday.
Give options when you have them, recommend one if you can, and ask for the decision by name. That turns "we're late" into a decision someone can make in a minute.
If the news is serious, don't let the written update be the first time your manager hears it. Tell them in person or on a call, then send the update. Nobody should learn about a red project from their inbox.
Small habits that keep it read
- Send it at the same time every week. Readers start expecting it, and a missing update gets noticed.
- Keep it to one screen. If it scrolls, cut progress detail first.
- Write the subject line as the status. "Checkout: Amber, launch at risk by a week" gets opened. "Weekly update #12" doesn't.
- Name people in requests. "We need a decision from legal" goes to nobody. "Jordan, by Thursday" goes to Jordan.
- Show it to the team before it goes out. Ask one person on the team to read it first. If they'd describe the project differently, fix the update or have the conversation.
- Don't use it to deliver feedback or surprises to individuals. "Sam's integration is late" in a broadcast email is a conversation you should have had privately.
Your first step
Take the last update you sent, or the one you're about to send, and rewrite it in the five-part template. Then ask yourself one question: if a reader stopped after the first line, would they know whether they needed to act? If not, rewrite that line until they would.
Writing for busy readers, status reporting and running the meetings that go with them are part of the communication fundamentals in the PTMF study guide. When the "when will it be done?" question gets harder, forecasting delivery dates as a range is the next skill to build.