A progress update memo has a simple job: tell people where things stand without making them read three pages to find out. When it works, your manager skims it in ninety seconds and knows what happened, what is at risk, and what you need. When it does not, the memo becomes a wall of activity with no signal — plenty of movement described, no decisions reached.
The difference is rarely the writing. It is the structure. The checklist below covers the five things every regular team update needs, plus a short pre-send check you can run in a couple of minutes.
Start with the status line, not the story
Before you explain anything, give the reader the headline. One or two sentences at the top: on track, at risk, or off track — and the single most important thing they should know.
Something like: “On track for the 14 March release. Two of the four test environments are ready; the remaining two depend on the infrastructure team.” That is a status line. It tells the reader whether to relax or lean forward.
Then use a consistent label — green, amber, red, or written equivalents — and apply the same definition every time. An amber meaning “mostly fine, but I want to flag something” becomes useless if next month's amber means “days away from failure”.
What a good status line avoids
- Vague reassurance: “progressing well” tells nobody anything.
- Activity instead of outcome: “held six meetings” is not a milestone.
- Buried bad news: if something has slipped, say so in the first line, not paragraph four.
Milestones: what moved since the last memo
Regular update memos are read in sequence, so the reader already knows the plan. What they need is the delta. List the milestones that were due since your previous update and mark each one done, part-done, or slipped.
Keep each line to a single sentence. A short bulleted list works better than prose, because the reader is scanning for one thing: what changed.
Where something slipped, add half a sentence of cause and the new date. “Integration testing slipped by four days — the vendor's API documentation arrived late. New date: 21 February.” That is enough. You do not need to relitigate the whole fortnight.
Two rules for milestone entries
- Use dates, not relative phrases. “Next week” means something different by the time the memo is read.
- Say who confirmed it. “Confirmed by the delivery lead after Tuesday's review” carries more weight than your own assumption.
Risks and blockers are not the same thing
These two get merged constantly, and merging them costs you. A blocker is stopping work now. A risk is something that may stop work later. The first needs a decision this week. The second needs a watch point and, sometimes, a contingency.
Put them in separate sections or separate columns, and label each one clearly. For every blocker, state three things:
- What is blocked, and who is affected.
- What you have already tried.
- The specific decision or action you need, and from whom.
That third point is where most memos fail. “Waiting on legal review” is a complaint. “Need legal to confirm whether clause 7 covers third-party data by Thursday, otherwise we delay the pilot by a week” is a request someone can act on.
Risks can be softer. Give each one a rough likelihood, its impact, and the trigger you are watching. If a risk is low and slow-burning, one line is plenty; do not pad the memo to look thorough.
Next steps need owners and dates
Close the substantive part of the memo with what happens next. Three to six items is usually right for a weekly or fortnightly update. Each item needs an owner and a date — and the owner should be a person, not a team.
“Marketing to finalise the launch email by 6 March” is a next step. “Marketing to look at the launch email” is a wish.
If an item has been carried over from a previous memo, say so. Repeating the same next step three weeks running without comment is a signal that something is stuck, and the reader deserves to know that.
Keeping the list honest
Review your carry-overs before sending. If an item has drifted twice, either break it into something smaller or move it into the blockers section. A next-steps list that never changes stops being read.
The two-minute check before you send
Run this before hitting send. It catches most of the problems that make managers skim straight past an update.
- Is the status in the first two lines? If your reader has to hunt for it, move it.
- Does every blocker come with an ask? If not, rewrite it as a question or a decision.
- Does every next step have a named owner and a date?
- Have you cut the travelogue? Remove any sentence that only describes effort.
- Is it under a page? Most regular updates can be. If yours runs long, put the detail in an appendix and lead with the summary.
- Would you be comfortable if this were forwarded? Assume it will be, and write the risk section accordingly.
One more habit is worth building: keep the memo the same shape every time. Same headings, same order, same labels. Regularity is what makes skimming possible, and skimming is what makes people read your updates at all.
Make it easy to act on
A progress update memo is not a report on your hard work. It is a short instrument for keeping a team aligned and unblocking the next decision. Lead with status, show the delta in milestones, separate risks from blockers, and finish with owners and dates.
Write to that shape consistently and you will notice something useful: replies start arriving with answers instead of questions. That is the sign the memo is doing its job.
Photo: RDNE Stock project / Pexels
