ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
A project status report exists to let somebody who is not in the detail make a
decision. That is the whole test, and most reports fail it — they describe activity at length,
bury the one thing that needs attention on page three, and arrive too late to change anything.
Not to prove you have been busy. A status report has three jobs: tell the reader whether the
project will land, tell them what is threatening that, and tell them what you need from them. If a
report does not contain an ask, it is a newsletter.
The corollary is that the audience determines the document. A board wants exceptions and decisions
in one page. A programme office wants milestone and financial data in a comparable format. The
delivery team wants detail. Trying to serve all three with one artefact produces something nobody
reads properly — which is how a red project can sit unnoticed in a weekly distribution for a
month.
| Section | What it has to answer |
|---|---|
| 1. Overall status | Will this land as agreed — with a reason for the colour, not just the colour |
| 2. Progress against baseline | Milestones hit, missed and forecast; spend against budget |
| 3. Exceptions | The top risks, issues and dependencies that could move the outcome |
| 4. Decisions needed | What you need from the reader, by when, with the options |
| 5. Next period | What will be true by the next report, so it can be checked |
Section four is the one that gets left out and the one that justifies the meeting. A report that
asks for nothing is telling the reader they have no role, and they will read it accordingly.
Red, amber and green mean nothing without definitions, and without them every project manager
calibrates differently. One reports amber at the first sign of trouble; another stays green until the
week before a missed date. A portfolio built from both is not comparable.
Define the thresholds once, in the PMO
charter or the reporting standard, in terms anyone can apply: green means forecast within
tolerance; amber means forecast outside tolerance with a recovery plan; red means outside tolerance
without one, or a decision is needed now. Tie them to the tolerances already agreed in the
project initiation document and
the judgement disappears.
Green on the outside, red in the middle. It happens because reporting bad news is unrewarded and
the incentives favour optimism until the situation becomes undeniable.
Three things reduce it. Require a reason for the colour, in a sentence —
manufacturing a plausible green sentence is harder than clicking a green cell. Report
forecast, not just actuals, because a project on plan today with a known problem next
month is not green. And make the trend visible: last period’s status next to this
one, so three consecutive ambers become a conversation rather than three unrelated updates.
Cultural fixes matter more than any of these. If the last person who reported red got a difficult
meeting and the person who reported green until the end did not, the template is irrelevant.
Sixty-three tracking and reporting templates.
The Project Management Toolkit ships 390+ editable MS Office templates. The execution and reporting set covers detailed and weekly status reports, daily updates, executive and portfolio dashboards, action item and decision logs, a deliverables acceptance log and multi-project trackers — plus timeline decks for reporting upwards.
Weekly for delivery, monthly for governance is the pattern that works for most projects. The weekly
report is operational — short, factual, action-oriented, aimed at the team and the immediate
stakeholders. The monthly is the governance product: baseline variance, financials, exceptions and
decisions, aimed at the board.
Derive the second from the first rather than writing both from scratch. Where organisations
maintain two independent reporting streams, they eventually disagree, and the resulting conversation
is about which number is right rather than about the project.
Cutting is harder than adding, so it helps to have a list of things that reliably do not belong.
If producing the project status report takes a day, something upstream is broken. The milestone
data should come from the schedule, the exceptions from the RAID log, the financials from the finance
system, and the decisions from the last governance meeting’s actions. Assembling it should be
collation, not investigation.
Where reporting genuinely takes a day, the usual cause is that the underlying registers are not
being maintained, and the report is where the maintenance actually happens. That is worth fixing at
the source: a project status report built by chasing people once a month is always slightly out of
date and always slightly optimistic, because the chasing surfaces what people volunteer rather than
what is true.
Where a PMO aggregates many projects, the individual project status report becomes an input to a
portfolio view, and two things matter more than the format. Dates and status must use the same
definitions across every project, or the aggregate is arithmetic on incomparable numbers. And the
reporting cycle has to be staggered so project reports land before the portfolio pack is compiled
— otherwise the board reads a portfolio assembled from last month’s project data and wonders why
it does not match what the project manager said in the room.
How long should a project status report be?
One page for a governance audience, with detail in an annexe. If the top-line status, its reason and
the decisions needed are not visible without scrolling, it is too long.
How often should status be reported?
Weekly for active delivery and monthly to the board is the common pattern. What matters more than
frequency is that it is fixed and predictable.
Who defines what red, amber and green mean?
The PMO or the reporting standard, once, for everyone. Thresholds set per project make a portfolio
view meaningless.
Should bad news wait for the report?
No. Anything that needs a decision before the next report should be escalated immediately. The report
records it; it is not the delivery mechanism.
What is the most common mistake?
Describing activity instead of status. A list of what the team did last week does not tell the reader
whether the project will land, which is the only question they have.
The test of a project status report is whether a reader who is not in the detail can make a
decision from it. Lead with the status, the reason for it and the ask. Report forecast against a
baseline rather than activity against memory. Define the RAG thresholds once for everybody, tie them
to the tolerances already agreed at authorisation, and show the trend so a run of ambers becomes a
conversation. And keep the report a by-product of registers that are already being maintained —
if writing it takes a day, the problem is upstream, and the report is only telling you so.
All of these are covered by the Project Management Toolkit, or start with the free ISO templates.
August 31, 2026
August 31, 2026
August 31, 2026
August 31, 2026
August 31, 2026