Project Reporting

General technique · See it on the map

Guide only — Deciding what belongs in a status report for a given audience is a judgment call.

Collecting and distributing project status and progress in the format each audience actually needs.

When to use it

Whenever work performance information has to reach an audience as a report: a status update, a dashboard, a forecast summary — anything that turns collected performance data into something a reader can act on without reassembling it themselves.

When to avoid it

As a substitute for a conversation a report can't carry — a report can state that a decision is needed, but the decision itself usually still needs a discussion. Don't bury the one figure or flag a reader needs inside a report so dense they have to hunt for it.

Steps

1. Pull current status and progress from the project's own recorded data rather than a manually reassembled copy.
2. Match the report's format and depth to the audience identified in the communications management plan.
3. State clearly what, if anything, needs a decision or action from the reader, rather than leaving them to infer it.

What it produces

• A distributed status or progress report matched to its audience's needs.

Common pitfalls

• Manually reassembling a report from scattered sources instead of generating it from the project's own record.
• One report format for every audience, so executives wade through field-level detail and the field team gets none.

Worked example

The PM generates the retrofit's weekly report straight from the recorded schedule and cost data, trims it to the three lines the steering committee cares about, and flags the conduit delay as needing a go/no-go decision this week.

Source

• PMBOK-6 §10.2.2.5

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.