Write a weekly update that surfaces decisions

Agree what the reader needs to do with the update

Identify the primary reader and the decisions they own. An owner may need to choose between competing priorities, while a delivery lead may need to coordinate dependencies. If the same report tries to serve every audience, it can become a long activity log. Start with the questions the intended reader should be able to answer.

Set a reporting period, a preparation owner and a source cutoff. A statement such as “position checked on Friday morning” makes the report easier to interpret when work changes later that day. Agree how urgent issues are raised between updates; a weekly document should not hold back a time-sensitive decision simply to preserve the reporting rhythm.

• What changed since the previous update?
• Which agreed outcomes are at risk or waiting?
• What decisions or inputs are needed, from whom and by when?
• What are the next commitments that the reader should expect to see?

Use a short template with the decisions near the top

A consistent order lets the reader find the same kind of information each week. Put a brief overall position first, followed by decisions required. Then explain meaningful progress, blockers and next commitments. If there are no decisions required, say so; do not fill the space with routine tasks to make the report look busy.

Use references to the live project or task records where the reader needs detail. In your working document these can be appropriate internal links. The summary should still stand on its own: the reader should understand the issue and requested action without opening five background files.

Report outcomes and changes rather than busyness

“Worked on the client pack” says little about the position. “Draft client pack is ready for owner review; two source documents remain outstanding” gives the reader something they can use. Distinguish work completed from work prepared, sent, approved or accepted. Each of those may be a different milestone.

If you use status colours, define them in plain language and include the reason. A green label without an explanation can conceal an unresolved dependency. For example, a task may be progressing normally while its required approval date has not been confirmed. The update should make that condition visible rather than treating an optimistic expectation as a fact.

Check any figures against the agreed source and period. If the information is incomplete, label the gap and name the next check. Do not convert a rough estimate into an apparently precise total just because the template has a numbers box.

Turn a blocker into a decision someone can make

A blocker needs more than “waiting for approval”. State what is awaiting approval, who can decide, the relevant options and when the answer is needed. Explain the affected commitment. Where you recommend an option, distinguish the recommendation from an authorised decision and include any important uncertainty.

Here is a fictional example: “Workshop invitations are ready. The venue has offered two room layouts; the owner needs to choose the layout before invitations include arrival instructions. Please confirm the preferred layout by Tuesday, or confirm that circulation should wait. The room-capacity information is in the venue summary.” This is specific enough to answer without searching for the underlying question.

End with a few checkable commitments

Choose the next outputs that matter to the reader rather than copying the entire task list. Each should have an owner and a date or explicit review point. If a commitment depends on information not yet available, show the dependency. “Complete once the supplier replies” needs a follow-up action as well as the eventual output.

Carry unresolved decisions forward with their history intact. Avoid resetting an old issue as though it appeared this week. Show what changed, what has been tried and whether the needed-by date has moved with agreement. This helps the owner see a persistent problem and decide whether the approach needs to change.

Check the update against the records, then use the answers

Before sending, verify dates, names, approvals and the current status with the relevant owners. Remove duplicate detail and make sure every requested decision has a clear question. Keep distribution appropriate to the content; a summary for a wider group may need less detail than the owner’s version.

After review, put decisions back into the working tracker with the person responsible and next action. Otherwise the report becomes a separate conversation that the people delivering the work never see. Occasionally ask the reader which parts they use and which they skip. Improve the format around real decisions rather than adding sections by habit.