Project status report

You tell the owner, in the first three lines, whether the project will deliver what was promised, when and for how much, and what you need from them. Every status colour follows a written rule, every claim of progress points to evidence, dates are dates, and bad news arrives early with a recovery option attached.

When to use

• "Where are we on the rollout?"
• "Write this week's status update."
• "I need a one-paragraph update for the board."
• "Is the move still on track for the 18th?"
• Set up with cronjob for the same day and time every week, so the report is ready before the owner's review.

What you need

• The baseline plan: milestones, dates, budget (see project-plan-and-timeline).
• Current task status from wherever the team tracks work: a project tool connected on the Connections page (Asana, Jira, Linear, Trello, ClickUp, Notion), your own browser signed in by the owner, or the plan workbook.
• Updates from task owners: collect with ask_teammate or brief_team using the questions in references/status-templates.md. Ask for facts (done, not done, new date, blocker), not feelings.
• Spend to date and committed costs, if the project has a budget (from the accounting software or the owner).
• The risk register and issue log.
• The previous report, so you can show what changed (session_search or the shared folder).

Method

1. Collect evidence before writing. For each milestone and critical-path task: done (with evidence: a signed-off deliverable, a merged change, a confirmation email), in progress (percent complete only if measurable), or not started; forecast finish date from the owner of the task.
2. Compare with baseline. Milestone table: baseline date, last week's forecast, this week's forecast, slip in working days. Recompute the critical path if any critical task moved (see project-plan-and-timeline).
3. Set RAG by rule, not mood (agree the rules with the owner at the start and keep them on the report):
   • Green: forecast meets baseline date, budget and scope within agreed tolerance (for example 5 working days, 5% of budget); no decision needed.
   • Amber: forecast outside tolerance but a recovery plan exists within the team's authority; or a high risk is open without mitigation.
   • Red: forecast misses a committed date, budget or scope beyond tolerance and recovery needs a decision from the owner; or the project is blocked. Give separate RAG for schedule, budget, scope and quality, and an overall status that is the worst of them unless you explain otherwise.
4. Earned value, when cost and progress data exist. Planned value (PV) = budgeted cost of work scheduled to date; earned value (EV) = budgeted cost of work actually completed; actual cost (AC) = spend to date. Schedule performance index SPI = EV / PV; cost performance index CPI = EV / AC. Below 0.9 on either needs a line of explanation. Estimate at completion = budget / CPI (a simple forecast that assumes the current efficiency continues). Do not use EV if "percent complete" is guessed; say so.
5. Risks and issues. Top 3 risks by score with owner and next action; open issues (things already happening) with owner and date. A risk that becomes real moves to the issue list.
6. Decisions needed. Each with: the decision, options, your recommendation, the cost of delay, and the date by which it is needed. If none, say "No decisions needed this week."
7. Write it bottom line first. Headline sentence with status and the most important fact. Then decisions, then milestones, then detail. Two versions from the same facts: an executive version (5 to 8 lines) and a team version (full tables). Templates in references/status-templates.md.
8. Check for watermelon status (green outside, red inside): green overall with slipping critical tasks, rising spend or a growing issue list is not green. Fix the colour or explain.
9. Send or post only where the owner has said: post to the team's channel or document if they asked you to, and give the executive version to the owner directly. Save the report and the forecast dates so next week can show the trend.

Worked example: the executive version

Order system rollout: RED. Go-live forecast 25 Nov, 5 working days later than the 18 Nov baseline.
- Done: supplier contracted (28 Oct, on baseline); workflow design signed off.
- Problem: configuration is 4 days behind because the supplier's test environment arrived
  on 2 Nov instead of 28 Oct.
- Next: configuration completes 11 Nov; training 12 to 13 Nov.
Decision needed by Fri 6 Nov: accept the 25 Nov go-live, or pay the supplier's expedite fee
of 1,800 to recover 3 of the 5 days. Recommendation: accept the new date; no customer
commitment depends on 18 Nov.

Why RED rather than AMBER: the slip (5 days) exceeds the agreed tolerance (3), and recovery needs money the team cannot authorise. The team version adds the milestone table, risks, issues and earned value; both templates are in references/status-templates.md.

Earned value in numbers

• Budget 42,000. By week 4 the plan said 19,000 of work would be done (PV).
• The deliverables actually finished were budgeted at 17,900 (EV). Spend is 18,400 (AC).
• SPI = 17,900 / 19,000 = 0.94: behind schedule. CPI = 17,900 / 18,400 = 0.97: slightly over cost.
• Estimate at completion = 42,000 / 0.97 = about 43,200.
• Anything below 1.0 gets a line of explanation; below 0.9 is a flag on that dimension.
• If percent complete was guessed rather than measured from finished deliverables, say so and leave the earned value block out.

Collecting updates without the noise

Ask each task owner four things, by a fixed time:

• What did you finish this week? (a link or evidence)
• What is in progress, and what is your finish date for it now?
• What is blocking you, or likely to in the next two weeks?
• Any change to scope, cost or quality you have seen or been asked for? Facts, not feelings: a finish date, not "nearly there". The prompt is in the reference.

Output

• Executive version: headline, overall RAG, 3 bullets (progress, problem, next), decisions needed with dates.
• Team version: RAG by dimension with reasons, milestone table (baseline, forecast, slip), completed since last report, planned next period, risks and issues, decisions, budget (PV, EV, AC, SPI, CPI) where available.
• A show_card with the milestone table and overall status.

Checks before you finish

• Every "done" has evidence; every forecast date came from the task owner.
• Each RAG colour follows the written rules; the overall colour is justified.
• Slip is measured against the baseline, not against last week's forecast only.
• Every risk, issue and decision has an owner and a date.
• The headline is understandable on its own.
• Nothing in the report contradicts the plan or the previous report without explanation.

Pitfalls

• "On track" without evidence. Ask what is finished, not how people feel.
• Rebaselining quietly. Slips against the original baseline must stay visible until the owner approves a new baseline.
• Percent complete on effort spent. 90% done for three weeks means the estimate was wrong. Use deliverables done.
• Burying bad news in the middle. Lead with it and attach the options.
• Reports that ask nothing. If you need a decision, say what, from whom and by when.
• Long reports nobody reads. The executive version is five to eight lines.

See also

• project-plan-and-timeline, project-risk-register, project-retrospective.