Operations Project Status Report

Recurring project status reporting

Purpose

Status reports fail in one specific way: they report activity instead of position, and they rate confidence instead of measuring it. The result is a project that is green until the week it is not, because "green" meant "the team is working hard" rather than "the plan of record is still achievable". This skill fixes the RAG criteria, forces a diff against the previous report, and puts the decisions the reader must make — with dates — where they cannot be missed.

Prerequisites

• Inputs: the previous status report, the plan of record (baseline scope, dates, budget), and the current position from the systems of record — the tracker, the finance actuals, the risk log. A status written from memory or from a stand-up recollection reports mood.
• Access: read access to those systems. If the tracker is stale, that is itself the finding — report the staleness with its as-of date rather than presenting old data as current.

If there is no baseline to measure against, say so and stop rating: without a plan of record, RAG is opinion, and the first deliverable is agreeing the baseline.

RAG criteria

Rate against the plan of record, not against effort. Rate each dimension separately, then take the worst as the overall — averaging hides the thing that will hurt you.

Rate these dimensions each period: scope, schedule, cost, quality/acceptance, resourcing, dependencies, risk position.

A status that has been green for six consecutive periods is not a status. It means the criteria are not being tested, or the baseline is no longer the thing being delivered. When it happens, do one of three things and say which: re-test each dimension against the criteria above, re-baseline because the plan has drifted from reality, or close the reporting because the project no longer needs it.

Procedure

1. Pull the current position from systems of record and note the as-of timestamp of each. Report the timestamp; a status of unknown vintage cannot be acted on.
2. Rate each dimension against the criteria table, and write the one-line reason next to each rating. A rating with no stated reason is sentiment.
3. Write the diff against the last report before writing anything else. What changed: ratings that moved and why, milestones met or missed, scope added or removed, risks that opened, closed, or changed severity, decisions taken since last time. A rating that moved needs the reason it moved; a rating that did not move on a project that is behind needs the reason it did not. The diff is the section readers actually use, and it is the section most often omitted.
4. State schedule as a forecast against baseline, not as percentage complete. "Forecast 6 May against baseline 22 April, three weeks late, driven by X" is status. "70% complete" is not — it is unfalsifiable and it has been 70% before.
5. List the decisions needed FROM the reader. Each one: the decision, the options, the recommendation, the named owner, the date it is needed by, and the consequence of it not being made by that date. A decision request with no needed-by date will not be made. This section goes near the top, not at the end.
6. Separate risks from issues. A risk has not happened and carries a probability, an impact, an owner and a mitigation with a date. An issue has happened and carries an owner and a recovery action. Reporting an issue as a risk is the most common way a red project stays amber on paper.
7. Report cost as committed and forecast, not just spent. Spend to date says nothing about whether the budget holds.
8. State dependencies on other teams by name, with the date they are needed and whether that team has confirmed it. An unconfirmed dependency is amber at best, regardless of how the rest of the project is going.
9. Include what is NOT being reported where the position is unknown: a system not yet checked, a workstream with no update, an estimate not yet re-forecast. Silence reads as green.
10. Keep the format fixed period to period. Readers of a recurring report scan for change; a changed format destroys that and forces a full re-read.
11. Close the loop on last period's decisions and actions. Anything requested and not delivered stays on the report, ageing, until it is closed. Requests that silently disappear teach the steering group that the report is decorative.

Report structure

Content rules

• Never soften a rating because a decision is expected to go the right way. Rate the position as it stands; note the pending decision in the decisions section.
• Never report a mitigation as though it were complete. State whether it is proven, in progress, or planned.
• Do not invent a forecast date to fill the field. If it cannot be forecast, say that, say why, and give the date it will be forecastable.
• Bad news early is the entire value of the report. A red rating raised in time is a working control; the same red raised at the deadline is a failure of reporting, not of delivery.

Data handling

Classification: Internal by default; Confidential where the report exposes named individual performance, supplier commercial terms, security weaknesses, or regulatory exposure. Report resourcing problems by role and capacity, not as commentary on named individuals — individual performance belongs in hr-performance-review-coaching, not in a status report.

Boundaries

• Something has already failed and needs cause analysis — use engineering-incident-postmortem.
• Communicating direction and sequencing to a wide internal audience — use product-roadmap-communication.
• A governance pack whose substance is a decision with options and trade-offs — use executive-board-pack-preparation; this skill feeds it.
• The underlying process is unclear or the handoffs are the problem — use operations-process-mapping.
• A technical change needing approval — use it-change-management.

Hand-offs

• Receives from: operations-process-mapping and product-requirements-doc (the baseline being reported against), data-analytics-report-qa (any figure quoted in the report).
• Routes to: executive-board-pack-preparation when a decision needs a governance forum rather than the project's own steering group, engineering-incident-postmortem when an issue becomes a failure worth analysing, and cross-functional-deck-assembly when the status must be presented rather than circulated.