operations-project-status-reportlisted

# 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 know