Project status report: a short example that supports decisions
The build is complete, but seven days of work remain in a five-day window. Report accepted outputs, current forecasts and the decision needed before the deadline slips quietly.
“The portal build is complete. Training is being arranged.” That update tells the sponsor something happened. It does not tell them whether the project can finish on time.
A project status report describes where the project stands at a stated date, against its agreed plan, with the current forecast and any action needed. APM's glossary includes accomplishments and variances to spending and schedule plans in that purpose.
For a useful short report, start with the result the sponsor must understand. Put the supporting evidence and decision beside it.
Project status report example: five days left, seven needed
Our fictional order-status portal has an approved twenty-working-day plan and a €20,000 budget. The report is prepared at the end of working day 15. The dates below all use the same project calendar.
The build is complete. Integrated validation still needs four days, followed by two days of training and one day of acceptance. Assume those activities must be sequential and the required people are available.
Seven remaining days give a day-22 finish, two working days later than the approved plan. “Build complete” has not removed that gap.
A short report with the fields filled in
The following is a possible report, not a universal template.
| Field | Current report |
|---|---|
| Status date and scope | End of working day 15. Agreed order-status portal, including integration, training, acceptance and handover |
| Headline | Delivery decision needed: forecast finish is two working days after the approved plan |
| Baseline and forecast | Approved finish day 20; current forecast day 22; no approved change to the commitment |
| Accepted work | Build review complete. Six of ten agreed requirements have acceptance evidence; four remain open |
| Remaining delivery | Validation 4 days, training 2, acceptance 1, sequential under the current plan |
| Cost | €12,000 actual cost to date plus €11,000 remaining forecast = €23,000 forecast total, €3,000 above budget |
| Current issue | Validation has not started; its environment is now ready, but the work no longer fits the original window |
| Decision requested | Sponsor to decide by day 16 whether to accept the revised cost/date forecast or require a credible alternative for review |
| Owners and next update | Test lead confirms validation evidence; service lead owns acceptance; project manager updates the forecast after the day-16 decision |
The €11,000 is remaining cost only. It does not include costs already counted in the €12,000 actual figure. Neither number establishes cash paid or the value of the benefit delivered.
Keep the commitment and forecast separate. Updating the forecast to day 22 informs the decision; it does not automatically approve a new baseline.
Show what is accepted, not just what was busy
Six accepted requirements out of ten is a useful evidence count. It is not necessarily 60% of the effort, value or delivery time. The four remaining requirements might contain most of the integration work.
Link the count to the requirements and acceptance record. Give the sponsor a way to inspect an important claimed result without reading a long list of meetings.
The project-failure Note explains why a green build report can hide unfinished delivery. This report should expose that situation early enough to change it.
If your organisation uses red, amber and green, define the thresholds. One team's green can mean on schedule; another team's green can mean no new problem this week. A shared colour with different meanings adds confusion.
Separate a current issue from a possible future problem
Validation not having started is a current issue. A possible defect discovered during that validation is a future risk. Both can affect the finish date, but their records and responses differ.
For this example, day 22 assumes validation takes four days and produces no additional rework beyond the stated plan. Record that assumption rather than presenting day 22 as a certainty.
The risk vs issue example follows that distinction. When a possible problem occurs, update the issue, remaining work and forecast together.
Turn the update into a decision
“Please advise” is difficult to act on. The sponsor needs the choice, its consequences and a decision date.
The current request is explicit: decide by day 16 whether to accept the revised forecast or ask for an alternative with a checked delivery method. Extra staff or parallel testing may be candidates, but they have not been shown to recover the two days.
The delayed-project example examines that recovery work. Don't put an unverified improvement into the status report as though it has already saved time.
After the sponsor decides, record the decision, any authorised changes and who must act. The next report should show what changed because of it.
Status report vs progress report
A progress report often emphasises what happened during a period. A status report often emphasises where the project now stands and where it is heading. Organisations use the names differently; the reports can overlap.
This project needs both views. The completed build explains recent progress. The remaining seven-day sequence explains current status. Keep enough of each to support the next decision, and remove activity detail that changes none of it.
Source and example notes
- APM: Project management glossary, entries for project status report, status report and actual progress.
The project, day numbers, costs and acceptance counts are fictional. The forecast assumes sequential remaining work and available resources. It excludes additional defect rework; no recovery option or revised commitment is approved by the example report.