← All articles

Project Reporting: What Good Looks Like

By XNM Technologies · September 17, 2022 · 5 min read
Project Reporting: What Good Looks Like

Project status reporting is one of the most universally practised and least well-executed activities in project management. The most common failure is a report that contains too much — pages of accomplishments, detailed task lists, photographs of site visits — but omits the two or three things a sponsor actually needs to know: are we on track, what problems are developing, and what do we need from you? The second most common failure is a report that understates problems. A project manager who reports green status to avoid a difficult conversation is not serving the project; they are delaying the point at which the sponsor can intervene, and by the time the real status becomes undeniable, the window for effective intervention has often closed.

The core elements of a good status report

A well-designed status report answers six questions. First: where are we versus the baseline? The report should compare current schedule, cost, and scope against the approved baseline — not against last week's report, not against what we hoped would be true, but against the baseline that was formally approved. Schedule variance is expressed in days or weeks (are we ahead, on track, or behind, and by how much?). Cost variance is expressed in dollars and as a percentage of budget. Scope changes are listed explicitly, not absorbed into the narrative.

Second: where are we going — the forecast at completion? A status report that only reports the past is a history document. A useful report projects the current trajectory forward: given our current schedule performance, when do we now expect to complete? Given our current cost performance, what is the expected total cost at completion? These are expressed as point estimates with a stated confidence level, not false precision. "We currently forecast completion in late March, plus or minus three weeks depending on the outcome of the subcontractor negotiation" is more useful than a single date that implies certainty that does not exist.

Risks, issues, and decisions required

  1. Key risks. The status report should surface the two or three risks that pose the greatest current threat to the project objectives. Not the full risk register — that is a working document for the project team — but the risks that have escalated in likelihood or impact since the last report, and the risk responses being deployed. A steering committee that has never seen a risk go red is either working on an unusually safe project or receiving incomplete reporting.

  2. Issues. Issues are risks that have materialised. An issue entry should describe the problem, its impact on the project (schedule, cost, scope, or quality), the current response, and the expected resolution date. Issues that cannot be resolved within the project team are escalated; the status report is the primary vehicle for that escalation.

  3. Decisions required from the sponsor. This is the element most often missing from status reports. If the project team needs a decision from the sponsor — on a scope change, a budget increase, a procurement award, a revised completion date — the report should state the decision, the options, the recommendation, and the date by which a decision is needed. A sponsor who receives status reports but is never asked for a decision is not really governing the project.

The one-page rule and RAG status

The one-page rule is not absolute, but it is a useful discipline. If a status report cannot summarise the essential project information on one page, it is usually because the project manager is reporting activities rather than status. Activities — what the team did last week, what they plan to do next week — are not the same as status. Status is the answer to "are we on track to meet our objectives?" The former can fill pages without saying anything useful; the latter can be stated in a sentence for each objective.

RAG (Red-Amber-Green) status indicators are widely used and frequently misused. The most common misuse is treating RAG as a measure of team effort rather than project trajectory. A project can be green on effort and amber or red on outcomes. The team may be working hard; the project may still be heading toward a missed deadline. RAG status should be assigned against objective criteria defined in the project's reporting framework, not against the project manager's subjective sense of how things are going. Green means: on track to meet the approved baseline within accepted tolerances. Amber means: a risk or issue has been identified that threatens the baseline and a response is in place but has not yet been proven effective. Red means: the baseline target cannot be met without corrective action that is beyond the project manager's authority to direct.

Tailoring reports to the audience

Different audiences need different reports. A steering committee or board report should be brief, focused on the questions a decision-maker needs answered, and should assume the reader has not read the previous report. A working team report can go deeper on technical progress and is typically more useful in a meeting format than as a written document. An executive summary for a minister or a board chair might be two or three bullet points extracted from the steering committee report. The mistake is to produce one report and route it to all audiences, or — equally common — to produce separate reports for each audience that contain contradictory status assessments because they are not based on a single source of truth.

Frequency matters as much as format. A monthly report for a high-risk, fast-moving project leaves too long a gap between the point when a problem develops and the point when the sponsor is informed. A weekly report for a stable, low-risk project creates unnecessary overhead and dulls the sponsor's attention to the reporting cycle. As a default: fortnightly for active delivery phases of significant projects, monthly for planning phases and lower-complexity projects, and ad-hoc escalation whenever a red issue emerges between reporting cycles.

If your organisation's project reporting is generating effort without generating insight, XNM's program and project delivery advisory can help you design a reporting framework that gives sponsors the information they need to govern effectively — and frees project teams from reporting that no one acts on.