# Operations Project Status Report > Produces a recurring project or programme status that survives a steering group: a RAG rating with stated criteria rather than sentiment, an explicit diff against the last report, decisions needed FROM the reader each with an owner and a date, and the rule that a status green for six consecutive weeks is not a status. Use when assembling a weekly or monthly update from systems of record, when a status is written but reads as reassurance, or when a project went from green to red with nothing in between. Trigger on 'write the status report', 'weekly project update', 'steerco update', 'what do I tell the steering group', 'RAG status', 'update on the programme'. Not for the post-hoc analysis of something that already failed (use engineering-incident-postmortem), not for communicating a roadmap to a broad audience (use product-roadmap-communication), and not for a board pack where decision rights and options analysis are the substance (use executive-board-pack-preparation). - Skill: `alihusains/operations-project-status-report` (Agent Skill) - Install (CLI): `npx skillmds@latest add alihusains/operations-project-status-report` - Raw SKILL.md: https://api.skillmd.com/api/skills/alihusains/operations-project-status-report/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: alihusains (https://skillmd.com/u/alihusains) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/alihusains/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. | Rating | Criterion | | --- | --- | | Green | Scope, date and budget are all forecast within the agreed baseline and tolerance, using current known facts. No decision is outstanding beyond its needed-by date. | | Amber | A baseline commitment is forecast to breach tolerance, or is protected only by a mitigation that is not yet proven, or a decision is outstanding whose needed-by date is inside the next reporting period. Recoverable by the team, without escalation. | | Red | A baseline commitment will breach tolerance and recovery needs a decision or resource outside the team's control, or an issue is live with no owned mitigation, or a decision has passed its needed-by date. | 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 | Section | Contents | | --- | --- | | Header | Project, reporting period, author, as-of timestamps, overall RAG | | Decisions needed | Decision, options, recommendation, owner, needed-by date, consequence of delay | | Change since last report | Rating moves with reasons, milestones met/missed, scope changes, decisions closed | | Position by dimension | Scope, schedule, cost, quality, resourcing, dependencies — rating and one-line reason each | | Schedule | Forecast vs baseline per milestone, with the driver of any variance | | Risks and issues | Separated; each with owner, action and date | | Ageing items | Anything requested previously and still open, with age | | Not reported | Where the position is unknown and when it will be known | ## 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.