Skip to content

Status Report

At a glance

  • Purpose: Give readers an accurate picture of where the project is — including when that picture is unwelcome — so they can make decisions.
  • Use it when: At the reporting cadence agreed in the communications plan, and immediately when a threshold is breached.
  • Owner: The project manager.
  • Related: Module 11 · Lab 22

A status report gives readers an accurate picture of where the project actually is — including when that picture is unwelcome. Its purpose is to enable decisions, not to reassure.

Copy the skeleton below and replace the bracketed text.

Report skeleton

# Status Report — [Project name]

| | |
| --- | --- |
| **Report date** | [YYYY-MM-DD] |
| **Reporting period** | [Start] – [End] |
| **Author** | [Name] |
| **Overall status** | [Green / Amber / Red] |

## 1. Summary

[Three or four sentences a busy reader can act on: what changed, what it means, what you need.
Write this last, but put it first.]

## 2. Overall status

| Dimension | Status | Trend | Comment |
| --- | --- | --- | --- |
| Scope | [G/A/R] | [↑ ↓ →] | [One line] |
| Schedule | [G/A/R] | | |
| Cost | [G/A/R] | | |
| Quality | [G/A/R] | | |
| Risk | [G/A/R] | | |

`Green` = on track · `Amber` = at risk, action underway · `Red` = off track, help needed

## 3. Progress this period

| Milestone / activity | Planned | Actual | Variance |
| --- | --- | --- | --- |
| [Name] | [Date] | [Date] | [± days] |

## 4. Schedule and cost performance

[If using earned value, report schedule and cost variance and the performance indices. If not,
report progress against the baseline and explain any variance in plain language.]

## 5. Risks and issues

| ID | Description | Exposure | Response | Owner |
| --- | --- | --- | --- | --- |
| [R1] | [Description] | [Score] | [Response] | [Who] |

## 6. Decisions needed

| Decision | Needed by | Options | Recommendation |
| --- | --- | --- | --- |
| [Decision] | [Date] | [A / B] | [Which and why] |

## 7. Next period

- [What will be done]

How to use this template

  1. Write the summary last and put it first. Most readers will read three sentences; those three must contain what changed, what it means, and what you need.
  2. Report variance with its cause and its consequence. "Three days late because the security review found two issues, which pushes testing into the week the tester is on leave" is actionable; "slightly behind" is not.
  3. Keep the status definitions explicit (Green / Amber / Red) and use the same ones every period. Changing what Amber means mid-project is how reports lose credibility.
  4. Always include decisions needed, with a date and a recommendation. A report's job is to unblock work; a report with no asks is a newsletter.
  5. Distinguish risks from issues in section 5, and keep the register IDs so a reader can trace them.
  6. Aim for one page. If it needs more, the extra belongs in an appendix that most readers will not open.

Field descriptions

Section What goes in it Watch out for
Summary What changed, what it means, what you need Repeating the whole report in miniature
Overall status Green / Amber / Red by dimension, with trend One colour for the whole project
Progress Planned against actual, with variance in days Percentages of unknown wholes
Schedule and cost Indices or plain-language variance, with basis Indices reported with no explanation of the measure
Risks and issues Register IDs, exposure, owner Items with no ID, so they cannot be tracked
Decisions needed Decision, date, options, recommendation A list of concerns instead of asks
Next period What will be done Promises beyond the team's control

Worked example

From Lab 22, invented for teaching. Two versions of the same summary paragraph:

Weak: "Progress continues well. The team completed most of the planned work and is slightly behind on testing. Some risks remain around the security review. No action needed at this time."

Workable: "Testing is 4 working days behind because two P2 defects were found in the document upload, one of which (D-014) only appears above 500 records. R-02 has occurred — the security review queue is 12 deep, so the integration review will not start before 20 April, which puts the 28 April milestone at risk. Decision needed by 24 April: accept a 5-day milestone slip, or fund an external assessor at the quoted fee."

The weak version is not dishonest — it is unusable. It contains no date, no measure, no cause, and no ask, so no reader can act on it. The workable one names the defects, links the risk, quantifies the slip, and asks a question with a deadline and two options. Note also that it reports a risk that has occurred, which is what moves it from the register to the issue log.

Common mistakes

  • Lead with the summary. Readers decide in seconds whether to read further.
  • Never hide bad news. A report that stays green until the last moment destroys trust and removes the option to react.
  • Report variance with its cause. "Three days late because the security review found two issues" is actionable; "slightly behind" is not.
  • Always include decisions needed. The report's job is to unblock work.
  • Keep it to one page wherever possible.
  • Green by convention. Teams under pressure drift toward Green because Amber invites questions; the honest reading is more valuable than the comfortable one.
  • Measures reported without their basis. "80% complete" is meaningless without saying 80% of what, and Lab 18 shows how a front-loaded baseline distorts the picture.
  • No trend. A level without direction hides whether the position is improving.
  • Consequences omitted. A reader who cannot see what a variance affects cannot weigh the decision.