Write a weekly status report people can act on

Separate the reporting period from the publication date

State the ISO week-year, week number and exact date range. If the report covers working days only, identify that narrower period explicitly. A report sent on Monday may describe the previous week, so the sending date and reporting period are different pieces of information.

Also state when the data was captured. A metric might describe Sunday even though the report was updated on Tuesday. Without a clear cutoff, later information can appear contradictory. Apply the same cutoff rule to recurring reports.

Report outcomes and changes, not just activity

Explain what now exists, has been decided or can be used. “Held three meetings” says little about project progress. “Agreed the review criteria; draft still awaiting approval” identifies both the result and the remaining step. Link to the authoritative version where necessary instead of attaching several competing copies.

Label schedule changes as changes. Moving a delivery into next week does not complete it. Briefly describe why the date changed and how the next commitment is affected.

Compare metrics only on a consistent basis

For an important metric, state its period, unit and counting rule. Completed tickets can be compared meaningfully with last week only if factors such as ticket definitions and the team being measured remain comparable. Put any change of basis beside the number, not in an unrelated footnote.

Consider a simple example: 8 completed tasks out of 10 planned tasks is 80 per cent. If 5 tasks are added later, 8 out of 15 is about 53 per cent. Those percentages answer different questions. Decide in advance whether you are reporting against the original plan or the revised scope.

Turn a risk into an actionable question

Describe a constraint so that someone else can respond. “Resource issue” is vague. “The review cannot start without the response needed by Wednesday” identifies a trigger and consequence. Add who must provide a decision or assistance, and by when.

Distinguish a problem that has happened from a possible future risk. A current problem needs a next action; a risk needs an observable warning and a possible response. Do not promise a replacement date while the critical dependency is still unresolved.

Use a short template in a stable order

Write the summary last and focus on what the recipients need to know or decide now. Use the agreed distribution channel and keep detailed material in an authoritative location rather than copying everything into the message.

For a small piece of work, the entire report may be only a few paragraphs. If no decision is needed, say so. Do not invent risks or metrics simply to make every heading look substantial.

Reporting period / ISO week / data cutoff:
Summary: most important change
Outcomes: complete, accepted or still outstanding
Variances and consequences:
Risks / issues / next action:
Decision required from … by …:
Next week: outcome and owner