Monthly project report checklist
A useful monthly project report tells a reader what period it covers, when it was published, what changed, what is forecast and where a decision is needed. Build it from agreed source records, state uncertainty plainly and complete a named review before issue. The checklist below keeps that routine practical without pretending one format suits every contract or governance model.
1. Close the reporting period
State the period start and end dates, the data cut-off and the planned publication date. Tell contributors exactly which updates are needed and when they are due. Keep late information visible: if a workstream has not confirmed its position, label the gap rather than carrying last month’s wording forward as if it were current. Save the source submissions in the agreed working location so the report can be checked.
2. Reconcile progress and milestones
Compare the narrative with the current plan, milestone tracker and previous report. Describe completed work as a result, not activity alone, and separate actual progress from next-period intentions. For each changed milestone, show the prior date, current forecast and reason where the project’s controls require them. Avoid optimistic labels that conflict with the underlying schedule or an unresolved dependency.
3. Check risks, issues and decisions
Reconcile the report with the live risk, issue, action and decision records. A risk is an uncertain event; an issue is already happening. Do not close either one merely to make the summary look cleaner. Highlight material changes, named owners, planned responses and decisions required from the report’s audience. Check that confidential or commercially sensitive detail is handled at the right access level.
4. Explain status and forecast
Use status definitions the organisation has already agreed. If a dashboard uses colour, repeat the meaning in words so colour is not the only signal. Explain what drives the status, what recovery action is under way and whether the forecast has changed. A realistic report can say that evidence is incomplete or that a date remains under review; false precision helps nobody.
5. Review, approve and issue
Run a factual check against the source records, then a reader check for contradictions, unexplained abbreviations and missing decisions. Record the reviewer, approver, revision, status and publication date. Issue the approved version through the project’s normal route, make its provenance clear and retain working material according to the organisation’s policy. Do not quietly edit an issued report; create the next controlled revision if correction is needed.
Fictional worked example
A fictional North Quay report covers 1–31 August and is due on 4 September. The schedule shows a workshop moved from 28 August to 12 September because access information arrived late. The report records no August completion, explains the dependency, names the recovery action and shows the revised forecast. It also asks the sponsor to decide whether the September review should move. Mina checks those statements against the milestone, issue and decision logs before Zoë approves revision 01 for issue.
In this example, the summary, source records and requested decision tell the same story, while the report period and publication date make clear when that story was true.
6. Improve the next cycle
After issue, note questions that readers asked and fields contributors repeatedly misunderstood. Fix instructions, ownership or cut-off timing before adding another dashboard. A short report with traceable facts and explicit decisions is usually more useful than a polished pack that hides uncertainty. Keep local contractual, regulatory and governance requirements in charge of the final format.
Source note
Clause 7.5 of the government-specific GovS 002 standard is a useful reference for factual reporting. This is our practical checklist; adapt it to your project’s requirements. APM also describes reporting and dashboards as PMO services.