A project status report should explain progress against the agreed plan, the current forecast and decisions needed from the reader. It is a dated account of the work, not a collection of activities designed to make the project look busy.
Start with the approved scope and reporting period. If the plan or baseline is unclear, identify that gap rather than presenting an arbitrary percentage as reliable progress.
Report against a defined reference
State which plan, version or milestone arrangement the report uses. Distinguish work completed during the period from total progress and the forecast for the next stage.
The Queensland Transport and Main Roads reporting guidance identifies areas such as progress, risks, issues, next activities, resources and project controls. It describes a departmental framework; use the reporting requirements approved for the actual project.
Do not imply that this general guide reports on a Brisbane 2032 project. The example below is entirely fictional.
A practical short-report structure
Include:
- Reference: project, reporting date and plan version.
- Summary: the current position in plain language.
- Progress: completed outputs and their evidence.
- Forecast: expected next results and assumptions.
- Exceptions: changes, risks or issues needing attention.
- Decisions: the specific approval or direction requested, with timing.
- Next period: priority actions and accountable owners.
If the organisation uses traffic-light ratings, apply defined criteria. A green cell should not conceal an unresolved decision that could affect a milestone.
A fictional report with meaningful detail
An invented office project is updating eight standard booking instructions. The approved plan expected six reviewed instructions by Friday. Five have been reviewed; one is awaiting a decision about cancellation handling.
A useful report says: “Five of the six instructions planned for review this period are complete. The cancellation instruction remains open pending the office manager’s decision. The project coordinator will submit the two options today. A decision by Tuesday is needed to retain the current distribution date.”
These counts are fictional. Five out of eight documents should not automatically be described as 62.5% of the whole project if the remaining work also includes testing, approval and rollout. Counting documents measures document completion, not every component of delivery.
Make a decision request actionable
Identify the question, available options, recommendation where authorised and effect of waiting. Link the supporting record instead of pasting a long history into the summary.
Separate a requested change from an approved one. If the team proposes a later milestone, show the current approved date and proposed revision until the appropriate person decides.
Where a forecast is uncertain, explain the dependency and information needed to improve it. A confident date without a basis is less useful than a clear account of what remains unresolved.
Check consistency before circulation
Compare the report with the action, issue, risk and decision records. Check dates, owners and whether outputs labelled complete have actually met the agreed conditions.
Circulate to the appropriate audience, keeping sensitive detail in approved restricted records. Retain the dated version through the project’s records process. A reader should be able to understand the current position, what has changed and the decision or action needed next without reconstructing the whole project from email.
For career context, explore administration roles in Brisbane and compare how employers describe reporting and coordination responsibilities.
