Project reporting and progress control in PM²: from data to decisions

Twenty-ninth article in the “Learning PM² Through a Project” series

A status report is not a chronicle of completed activities or a document to prove that the team is busy. It is a governance tool: it shows whether the project is still progressing toward approved objectives and makes required decisions visible before deviations become irreversible.

In PM², reporting is part of Monitor & Control. It gathers evidence from the Project Work Plan, logs, testing and stakeholders; compares it with baselines; and turns it into forecasts, actions, escalations and decisions.

The three levels: data, information, decision

A useful report does not jump directly from data to a traffic light. It explains what the deviation means and which action or decision is needed.

Control against a baseline

Control needs an approved reference: scope, schedule, cost/effort, quality and acceptance criteria. The PM compares actuals and forecast with these baselines.

flowchart LR
  A[Approved baseline] --> B[Actual data]
  B --> C[Deviation analysis]
  C --> D[Forecast]
  D --> E{Within tolerances?}
  E -- Yes --> F[Actions and monitoring]
  E -- No --> G[Escalation or change decision]
  G --> H[Communication and controlled update]

The baseline should not be rewritten to make a delay disappear. Forecast may worsen or improve with evidence; baseline changes only after an approved change.

What a Project Status Report should say

The format varies, but an effective report answers concisely the questions relevant to those governing the project.

Operational detail can remain in the Work Plan, boards or tickets. The report should make the picture readable for its recipient, not duplicate every tool.

Traffic lights: useful only when explained

A green/yellow/red system can provide a rapid reading, provided rules are clear.

Red is not failure and green is not a guarantee. They are attention indicators. Every colour should be accompanied by cause, impact, owner, action and forecast.

Actual progress: avoid optimistic percentages

Saying “we are 90% complete” can mislead if the remaining 10% contains integration, acceptance or a critical dependency. Progress should be linked to observable deliverables and completion criteria.

The question is not how many tasks show as complete, but whether value-producing deliverables are ready and acceptable within available time and cost.

Forecast and deviation analysis

Every useful deviation should be expressed completely:

Baseline: go-live on 30 June.
Actual / evidence: Android issue open and dashboard not started.
Forecast: most likely go-live is 7 July unless scope is reduced.
Impact: one-week delay or deferred deliverable.
Required action / decision: PO/BM decide by Friday between delay, reduced scope or added capacity.

This format separates facts, inferences and decisions. It avoids both the vague phrase “we are late” and unverified optimism such as “we will recover”.

The Annotatio case: a report that enables choice

For Smart Bookings, the weekly report might show:

The report does not ask generically for “attention”. It asks each competent role for a precise choice supported by evidence.

Control rhythm and reporting levels

Cadence should be proportionate to project rhythm and the speed at which risks change.

A monthly report may be sufficient for strategic governance but too slow for an issue blocking a milestone in the current week. Urgent information is communicated on its trigger; it does not wait for the next cycle.

Escalation: reporting should enable, not dump the problem

When decisions outside PM delegation are needed, the escalation section should contain:

• verified fact and impact;
• baseline and forecast;
• real options with pros and cons;
• PM recommendation and relevant opinions;
• decision-maker and decision deadline;
• consequence of no decision.

This turns escalation from “there is a problem” into “this is the decision needed to protect the project”.

Do not confuse these

Three questions to anchor it

1. Against which baseline are you declaring green, yellow or red status?
2. Which deliverable or milestone, not which task, determines the risk to the final result?
3. Which decision is needed, who must make it and by when?

Flashcards

Q: What is the Project Status Report for?
A: To compare progress, deviations, forecast, risks and issues with baselines, enabling timely actions and decisions.

Q: What makes a traffic light useful?
A: Clear rules and context: baseline, cause, impact, owner, action and forecast.

Q: What is the difference between baseline and forecast in reporting?
A: Baseline is the approved reference; forecast is the updated prediction based on actual data.

Exam-style question

Each week, the PM updates the official plan with newly forecast dates. In the following report, the project appears green because all milestones match the just-updated dates.

What is the error?

Answer: the PM has replaced the baseline with the forecast, removing visibility of deviation. New dates can be reported as forecast; baseline changes only after approved change. The report should show the difference, cause, impact and required action or decision.

Source

Project Reporting, Monitor Project Performance, Control Schedule, Control Cost and Information Distribution are covered in the European Commission’s PM² Methodology Guide 3.1.

Next: Project-End Report and Lessons Learned, closing the project with evidence, accountability and reusable knowledge.