A project status report should help a reader act. It needs the current position, the change since the last update and the decisions or support needed next. A long list of completed tasks can hide the one dependency that threatens delivery.

A practical workflow

  1. State the reporting date and the milestone being measured. Separate completed work, work in progress and work that is blocked.
  2. Describe each material risk or issue with its impact, owner and next step. Use a consistent status definition, such as on track, at risk or blocked, and explain the reason.
  3. End with the next milestone and any decision required from the reader. Give the decision a deadline and say what happens if it remains unresolved.

Worked example

'At risk: the launch remains planned for 18 June, but final artwork is needed by 10 June. Maya owns the request. Please approve option B by Tuesday; otherwise the print booking will need to move.' This gives stakeholders more useful information than 'Artwork pending'.

What to check before sharing

Do not mark a project green merely because people are busy. Compare actual progress with the agreed scope, date and dependencies, and make changes visible.

How often should I send an update?

Match the cadence to the project and stakeholders. A weekly update works for many active projects, while a critical dependency may need an immediate decision request between reports.