Status Report

A project can look busy while quietly missing its next deadline, so a weekly status report gives the sponsor a consistent view of progress and constraints, saying what changed since the previous update and what needs attention now. Start with the reporting period, project owner and date, because readers need to know whether the figures cover this week, the whole project or a forecast, and a stale green rating can be worse than no rating.

List completed milestones and work in progress against an agreed baseline, since 'Design done' is useful only if the team defines what done means, with evidence such as an approved design, a delivered file or an accepted test. Show the next milestones and their due dates, and if a dependency could move a date, identify the owner of that dependency, because a task without a responsible person rarely improves because it was mentioned in a report.

Separate risks from issues: a risk is something that may happen, while an issue is already affecting delivery, and each should note likelihood or impact if helpful, plus the action being taken and who owns it. Budget reporting should compare actual spending and committed costs with the approved plan, and since a low current spend may mean work has not started rather than that the project is saving money, material differences need explanation.

A simple spend-to-progress ratio divides the percentage of budget spent by the percentage of work complete, so if 60% of budget is spent and 50% of work is complete, the illustrative ratio is 1.2. It is not an established proof of overspending, because progress estimates and timing of invoices can distort the comparison.

Give context instead about the remaining work and forecast cost to finish, as a project with early equipment purchases may show high spend but still be on track, while a project with delayed invoices may look cheap until the bills arrive. Traffic-light ratings can help busy readers scan, provided green, amber and red are defined for the project before use, with amber perhaps meaning a milestone is threatened but recoverable and red meaning the current baseline cannot be met without a decision.

A single colour cannot replace a reason, so explain why a project is amber and what would return it to green. Teams should not be punished for identifying trouble early, or they will report green until the problem is unavoidable.

Keep the report concise enough to read, with links or appendices for detail, since sponsors usually need the status, change, implication and decision, not a daily diary. Highlight requested decisions explicitly by stating the choice, decision owner and date needed, because 'Supplier delay' is an observation while 'approve alternate supplier by Thursday to protect launch' is actionable, if the option has been checked.

Atlassian's project status template stresses a consistent format for progress, issues and stakeholder communication, and a familiar structure makes changes visible across reporting periods, though the fields should be tailored to the project rather than copying an oversized template. Use reliable sources by confirming numbers with finance, dates with the schedule and delivery claims with accountable owners, and challenge contradictions even if the project manager need not personally produce every data point.

A change log helps prevent shifting baselines from hiding slips, because if scope, budget or date changed, the report should show when and who approved it, comparing against the current approved plan while retaining a record of the original commitment. At the next meeting, review prior actions first, because a report that repeatedly lists the same risk without changing owner, mitigation or deadline is not enabling action, and a good status report answers where we are against plan, what has changed, and what is needed from the owner, candidly enough to let the team decide in time.