Most project reviews end the same way: everyone updated, nobody committed. The meeting showed data and produced no decision. The fix is not a better agenda. It is five questions — and the rule that a report is ready for review only when it answers them.
1. Where are we?
Measured status, not reported status. The difference: measured status compares progress against plan with a source (a sheet, a system, a measurement). Reported status is what the team believes — usually a month late and ten percent optimistic.
The answer is one of three judgments: on track (the date holds with the planned resources), at risk (the date holds only if something changes), off track (the date no longer holds and a decision is needed on date, scope or resources).
2. Where are we heading?
A forecast, not a hope. If the current pace continues, what date do we actually reach — and with what confidence? A project that is 80% complete can still be at risk when the remaining 20% contains the critical path.
3. What changed since the last review?
Deviations with a cause. The size of a deviation says how much; the cause says what to do. Three families of cause: wrong estimate (replan), execution problem (correct the work), external dependency (manage the dependency). A deviation without a cause is noise and gets ignored — correctly.
4. What can derail us?
The two or three risks that can really change the outcome, each with a planned response. A review that discusses fifteen risks decides nothing; the full register lives in a tracker, the meeting discusses only what matters.
5. What do we need from you?
The decision required — the explicit question to the people in the room. Not "evaluate the progress" but "approve a two-sprint scope extension, or freeze feature X by Friday". A good required decision has three elements: the options, the recommendation of the proposer, and the deadline.
The rule that follows
If the report does not answer the five questions, the meeting is not a review: it is an update, and updates are sent by email. This single rule eliminates most unproductive meetings.
A worked structure for the five questions is available as a free generator: the project status report tool builds the report from five fields. The complete operating kit — six templates including the steering committee agenda, the risk and decision tracker, the RACI matrix and the quarterly review model, plus the full method guide in Italian and English — is in the Project Review Kit.
A constructed example (not client data)
Synthetic scenario for illustration. A platform migration review opens with a 40-slide deck and no forecast. Applied to the five questions, the same project produces: status at risk (one critical dependency three days late); forecast: go-live slips two weeks unless the integration window moves; deviation with cause: external vendor, not planned as a dependency; risks: vendor further delay, mitigated by plan B already activated; decision required: shift the integration window or descope one module, by Friday.
The review takes twenty minutes instead of ninety, and ends with a decision.
FAQ
What is the difference between a project review and a status update?
A review ends with decisions: it answers the five questions and produces an explicit decision required, with owner and deadline. A status update only shares information — it belongs in an email.
How long should a project review last?
Sixty minutes are enough when the report answers the five questions before the meeting. The meeting then decides; it does not read.
Who should attend a project review?
The people who can make the required decision, the project owner, and whoever brings measured data. Anyone who attends only to be informed can read the report.
What if there is nothing to decide?
Do not hold the review. Send the report and spend the hour on the project.