What should a weekly project update include?

The five questions a useful update answers

Every part of our update maps to a question someone actually needs answered on Monday. If a line does not answer one of these five, it does not go in. Here is each one and why it stays.

Progress since last week comes first, because it is the reason to open the update at all. We keep it to what changed and what finished, not a diary of activity. "Onboarding emails are live" is progress. "Worked on onboarding" is not, and that gap is the difference between a line worth reading and noise. We list the handful of things that genuinely moved and leave the rest off.

Blockers come second on purpose, because a good update surfaces trouble early instead of burying it near the end. Anything waiting on a decision, a person, or another team gets named here, along with what it is waiting on. This is the part that makes the whole update worth sending. A blocker written down on Monday is one someone can clear by Tuesday, while a blocker mentioned in passing usually just sits there for another week.

Next steps say what the week is pointed at, in a few concrete lines rather than a full plan. It is not the place to relitigate priorities, only to show the direction so nobody is surprised later by where the effort went. When we plan the coming week properly, this section almost writes itself, because the update is really just reporting against a plan we already agreed on.

Decisions needed is the part most updates leave out, and it is the one that keeps things moving. If work is stuck on a call somebody has to make, the update names the decision, the options, and who we need it from. Pulling these into one place lets the reader clear two or three choices in the time it takes to read, instead of scheduling a separate meeting for each. It is worth asking a few questions first about whether a decision truly needs a live conversation or just a written yes.

Tasks due soon is the short forward look: what is landing this week and early next, so deadlines do not sneak up on anyone. We keep it to things with real dates, not everything that is open, because a list of forty tasks is not a heads-up, it is wallpaper. Three or four dates people should have on their radar is the right size.

Why each part earns its place

Here is the whole update in one view: what each part is for, and the trap we try to avoid in each one. The "what to skip" column is doing as much work as the rest, because most bad updates fail by adding, not by leaving out.

What we stopped putting in

The update got useful when we started removing things, not adding them. Three habits went first, and none of them are missed.

The long narrative went first. Early on ours read like a weekly essay, a paragraph of context before any actual news, written more to look thorough than to be read. Nobody finished it. The fix was blunt: lead with what changed and cut the throat-clearing. If a line is there to show effort rather than to inform a decision, it is padding.

Per-person activity logs went next. We used to list what each person had been doing, which quietly turned the update into a status report on people instead of on the work. It made everyone feel a little watched and told the reader nothing they could act on. Now the update is organized by the work and its state, not by who was busy. Who did what lives on the tasks themselves.

We also dropped the vanity numbers, the counts of tasks closed or messages sent that climb every week and mean almost nothing. They made the update look productive without saying whether the project was actually on track. A single honest line about whether we are ahead or behind beats a row of metrics that only ever trends up.

Where weekly updates quietly go wrong

A few failure modes show up again and again, and all of them are easy to slide into without noticing. Watching for these is most of the work of keeping an update honest.

Status theatre is the big one: an update written to look good rather than to be true. Everything is green, every task is "on track", and the tone stays upbeat right up until a deadline is missed. An update that never carries bad news is not an update, it is marketing, and people learn to skim it. We would rather read that something is behind while there is still time to do something about it.

Close behind is the update nobody reads, usually because it is too long, too frequent, or lands somewhere it drowns. If we sent ours as one more email thread it would be skimmed and lost, which is part of why we keep updates off email and put them where the work already lives. Length matters just as much: an update that takes ten minutes to read will not get read, and the discipline of keeping it short is what keeps it alive.

The last one is the update that hides the ask. It reports plenty but never says what it needs from the reader, so nothing actually happens as a result of sending it. Every update should make at least one thing clear: a decision to make, a blocker to clear, or a heads-up to note. If it cannot double as a short agenda for whatever conversation comes next, it is probably not pulling its weight.

A short template you can copy

This is close to what we send, stripped to the bones. Fill it in, delete any heading with nothing under it, and keep the whole thing to something you could read in a minute or two.

• Progress since last week - two to four things that actually finished, not things that were worked on.
• Blockers - what is stuck, and exactly what or who it is waiting on.
• Next steps - where this week is pointed, in a few plain lines.
• Decisions needed - the call to make, the options, and who we need it from.
• Due soon - the few dated items landing this week and early next.

That is the entire format. It works as a standalone weekly note, and on the weeks we do meet it doubles as the running order, so the meeting opens on the decisions instead of a recap of what everyone already read. The point is not the exact headings, it is that every line is there to inform a decision or prompt a nudge. Anything that does not do one of those two things can come out.

The format only works if someone acts on it

Here is the honest limit: none of this matters if the update becomes a ritual nobody responds to. We have had stretches where the weekly update went out on time, cleanly formatted, and changed nothing, because no one read it as a prompt to actually do something. A perfectly structured update that drives no decision and no nudge is just homework, and a tidier template does not fix that.

So the test we hold ours to is simple: did sending it make something happen that week? A decision got made, a blocker got cleared, someone adjusted what they were working on. If the answer is yes, the format is earning its keep. If it is no for a few weeks running, the real fix is not a better layout, it is to ask whether anyone needs the update at all, and to cut it or the meeting it feeds rather than keep performing it.

Keep it to five parts, and keep it honest

A good weekly project update is short, honest, and built around five questions: what moved, what is blocked, what is next, what needs a decision, and what is due soon. Everything else we tried, the long narratives, the per-person logs, the numbers that only go up, made it longer and less useful. A written update like this is what lets a small team cut back on status meetings and still know where everything stands, as long as people act on what it says.

If your current update has drifted, start by deleting rather than adding. Copy the five-part template, send it once this week, and watch whether anything happens because of it. If something does, you have a keeper. If nothing does, that is worth knowing too.