6.3 Reporting Progress: Reports People Read

6.3 Reporting Progress: Reports People Read
Chapter 6.3 Part of 6.0 Progress Tracking

Reporting Progress

Most status reports are written for the writer — to demonstrate diligence, or to have something to point at later. A report worth the time it costs is written backwards from what the reader has to decide.

New to this? This is the last step of the tracking loop in 6.0 Progress Tracking. Who receives what, and how often, was decided in 4.3 Communication Planning — this page is about the content. Terms are defined at the bottom and in the glossary.

In short

  • Lead with a verdict: will we make it, and should you worry. Everything else is supporting detail.
  • Report what changed, not everything that exists. A tool already lists what exists.
  • Every report should ask for exactly one thing, or it is a broadcast.
  • Bad news goes first and goes early. Credibility is built on the reports where something was wrong.

What reporting is for

Three jobs, and they need separating because a report trying to do all three at once does none of them:

  • To let someone decide. The sponsor needs enough to approve, redirect or leave alone. This is the primary job and it usually needs under a hundred words.
  • To coordinate. Neighbouring teams need to know what changed that affects them. Better served by a notification when it happens than by a weekly summary.
  • To create a record. A trail of what was known when. Valuable, and mostly a by-product of doing the first two consistently rather than a reason to write anything extra.

Notice that none of them is “to show that we’ve been busy”. That instinct is understandable and it produces the reports nobody reads, because effort is the least useful thing you can report.

The shape that works

An annotated weekly status report of about ninety words A weekly report for a customer portal project in week seven of twelve, marked on track. The headline says the launch date holds at 3 June and three of eight buffer days were spent on the vendor security review. What changed this week: order history accepted by Support, invoice export moved into test, vendor review returned five days late. What is at risk: data migration has not started, owner Priya, decision point 20 May, after which the launch date moves. What I need from you: confirm by Friday that multi-language can drop out of phase one. Annotations note that the status is a verdict rather than a colour, the headline answers "should I worry" first, the changes list only what moved, the risk has a named owner and a date, and every report asks for one specific thing. Customer portal — week 7 of 12 ON TRACK THE HEADLINE Launch date holds at 3 June. We spent 3 of our 8 buffer days on the vendor security review. WHAT CHANGED THIS WEEK •  Order history accepted by Support •  Invoice export moved into test •  Vendor review returned, five days late WHAT IS AT RISK Data migration hasn’t started. Owner: Priya. Decision point is 20 May — after that, the launch date moves. WHAT I NEED FROM YOU Confirm by Friday that multi-language can drop out of phase 1. A verdict, not a colour Answers “should I worry?” before anything else Only what moved — not the whole task list A named owner and the date it becomes real Every report asks for one specific thing Roughly 90 words. It can be read on a phone between meetings, and a sponsor who reads only the first two lines still knows what they need to know. A report nobody replies to is filing, not communication.
The order is deliberate. Anyone who stops reading after two lines has still received the most important information — which is the only realistic assumption about a busy reader.

Status labels that mean something

Green, amber and red are near-universal and nearly useless, because nobody agrees on what they mean. Two rules fix most of it:

  • Define them once, in terms of the date. Green: will hit the date with the plan as it stands. Amber: will hit it only if something specific happens — and say what. Red: will not hit it without a decision from someone other than the team.
  • Amber requires a named action. An amber with no ask is a green with anxiety attached. If nothing is required of anyone, it’s green; if something is, say what and by when.

The failure to watch for is the watermelon report — green on the outside for months, then red without ever passing through amber. That pattern doesn’t mean people are lying; it usually means the definitions were never agreed, so “green” drifted into meaning “nobody has escalated”.

Numbers and words together

Quantitative data says what; qualitative says why it happened and what it means. Neither works alone. “62% complete” tells a sponsor nothing actionable. “It’s going well” tells them less.

Two habits keep numbers honest in a report:

  • Pair every number with a comparison. “3 of 8 buffer days used” beats “3 buffer days used”, because the reader shouldn’t have to remember the denominator.
  • Prefer countable things. Deliverables accepted, days of buffer left, items blocked. These can’t be adjusted by optimism the way a percentage can — see 6.1.

Adjusting for the reader

ReaderWhat they actually wantWhat to send
SponsorWill we make it, and is anything needed from me?The card above. Weekly, same day.
Steering groupDecisions taken, decisions needed, moneyMonthly. Exceptions and choices, not activity.
The teamWhat changed that affects my next taskContinuous, on the task itself.
Neighbouring teamsAnything touching their datesAn event when it happens, not a weekly digest.
End usersWhen it arrives and what changes for themAt milestones. Silence in between is fine.

Two of those five rows are events rather than reports. That’s the useful realisation: a lot of what gets bundled into a weekly report is really a notification that should have gone out on Tuesday when the thing actually happened.

Delivering bad news

This is the part that decides whether anyone trusts the other reports, and the mechanics are simple enough to write down:

  • Same day, not next Friday. A slip that a sponsor learns about a week late is two problems: the slip, and the week.
  • The sponsor hears it from you first. Hearing it from someone else converts a manageable problem into a relationship one.
  • Lead with it. Burying it in paragraph four teaches people to read your reports sceptically for the rest of the project.
  • Bring the options. Problem, impact, two or three courses of action with their costs, and your recommendation. That turns a five-day email exchange into a five-minute decision.
  • Say what you already did. Not defensiveness — information. It tells the reader which options are already exhausted.

The general principle: a report that only ever says things are fine carries no information, because it would say the same thing either way. The value of your green weeks comes entirely from having reported the amber ones honestly.

How this looks in AB

In AB Projects, status, progress and the project dashboard make the actual state visible without anyone writing a weekly report. Adaptive Cards in the linked Teams or Slack channel deliver “what changed this week” automatically, and when someone asks “when did this slip?”, the change-history tab is the audit trail with the answer.

That changes what a written report is for. When anyone can see the raw state at any time, the report stops being a data transfer and becomes the two things a dashboard genuinely cannot do:

  • Interpretation — what the changes mean for the date, which a list of task movements does not say.
  • The ask — the one decision you need from the reader this week. No dashboard has ever requested anything.

Which is why the card in the diagram is short. Almost all of it is the part a tool can’t generate.

Terms used on this page

Status report
A periodic summary of progress, risks and decisions needed. Valuable when it interprets and asks; wasted when it lists what a tool already shows. More →
RAG status
Red, amber, green labelling of project health. Only meaningful if the three are defined in terms of the date and agreed in advance. More →
Watermelon report
A status that stays green on the outside while the project goes red underneath, then flips without warning. A symptom of undefined labels rather than dishonesty. More →
Exception report
A report sent only when something crosses a threshold, rather than on a schedule. Efficient, and dependent on the thresholds being agreed. More →
Dashboard
A live view of project state that people pull from. Replaces the data-transfer part of reporting and none of the interpretation. More →
Variance
The gap between plan and actual, in time, cost or scope. What a report exists to explain rather than merely display. More →

Related reading

4.3 Communication Planning

Who gets what and how often — the decisions this page assumes have been made.

6.1 Monitoring Deliverables

Where the countable numbers in a good report come from.

4.2 Stakeholder Management

Why regular, boring, honest reporting is the thing that actually builds trust.


Published on: 2025-07-30 Last updated on: 2026-07-27

Questions & answers

Have a question about this topic? Ask below — no sign-up needed. The team reviews and answers questions here.

No questions yet — be the first to ask.

Ask a question

We’ll send a one-time email to confirm your address. Questions appear after a quick review.