How to write a project status update stakeholders actually read

Most updates are written from the team’s point of view: what we worked on, in the order we worked on it. The sponsor reads them from the other side, looking for three things. Is it still landing when you said? Do they need to do anything? Is there a problem they should know about? If the answers sit in paragraph five, or aren’t there at all, the update gets skimmed and archived, and the sponsor asks the same questions on the next call.

Length is part of it. An executive sponsor who backs several projects gives each update about a minute. Anything that needs longer goes in a pile for later, and later is usually the next meeting.

Write the sections in this order, and leave out any section that is empty this week rather than writing “nothing to report.”

1. 1Lead with the callOne line: on track, at risk, or slipping, against the date the sponsor cares about, with the reason in a few words. “On track for the Nov 7 launch.” “At risk for Nov 7: training is waiting on system access.” Use the word, not only a color, so it reads the same in every inbox.
2. 2Put their asks above your newsIf the sponsor needs to decide, review, or do something, it goes second, with the date you need it. This is the part that moves the project, so it shouldn’t compete with updates about work they don’t need to act on.
3. 3List what finished, with proofName finished deliverables or meaningful pieces of them, each with a link to the thing itself: the document, the demo, the release note. A link lets the sponsor check for themselves, which builds more trust than an adjective.
4. 4Say what’s moving nextTwo to five items the team is working on now, so the next update has no surprises. Stop at five. A long list here reads as activity rather than progress.
5. 5Name what’s in the way, without blameFor each blocker: what it is, who is clearing it, and by when. If it is waiting on the sponsor, it belongs in the asks section instead. Keep the tone factual, so the update reports the problem without assigning fault.

Here is the structure filled in for a fictional rollout. It takes under a minute to read and leaves the sponsor with nothing to ask.

“We closed 23 tickets this week” tells the sponsor the team was busy. It doesn’t tell them whether the thing they’re backing is closer. Report progress on the deliverables they agreed to, such as the knowledge base, the training plan, or the launch, and keep task counts for the team’s own board. A sponsor who can see each deliverable move, with its proof one click away, stops asking for the detail behind it.

Pick a day and keep it. Weekly suits most internal and client projects; daily makes sense only during a launch week or an incident, and only if each one is shorter. A predictable update trains the sponsor to wait for it instead of emailing for news, which saves both sides time. If a week is genuinely quiet, send the one-line call anyway. Skipping it reads as a problem.

• Opening with background they already know.
• Burying a request for a decision in the middle of a paragraph.
• Writing “in progress” for the same item four weeks running without saying what changed.
• Showing a green status while a blocker sits further down.
• Attaching a deck when a link to the work would do.
• Changing the format every week, so the sponsor has to relearn where things are.

Unblockd drafts this update from the project each weekday on the Team plan: what’s waiting on the sponsor, what was accepted, what finished with its proof, what’s moving next, and what the team is clearing. You add an opening line if you want and approve it in one tap, and it links to a page that answers “are we on track” whenever the sponsor looks. See stakeholder and executive updates.