Match reporting to the governance level
Reporting for the operational team differs from reporting for a steering committee. The former can be detailed, technical, updated frequently. The latter should be concise, decision-oriented, with enough detail to arbitrate but not enough to bury the audience in operational specifics that don't belong at its decision level.
Using the same document for both audiences is a common mistake: either the steering committee gets bored with a level of detail irrelevant at its level, or the operational team lacks concrete information because the document was calibrated for a more strategic audience.
Choose actionable indicators, not just descriptive ones
A descriptive indicator informs ('60% of tasks are complete'). An actionable indicator helps decide ('the completion rate of critical tasks is 15 points below overall progress, which threatens the delivery date'). The second type of indicator prompts action, the first just documents a state.
- Progress on critical tasks vs. overall progress
- Trend in the number of open high-impact risks
- Cumulative budget variance vs. planned budget to date
- Number of decisions pending arbitration
An objective RAG status, not an optimistic one
The RAG status (Red, Amber, Green) summarizes the state of a project or workstream at a glance. Its value depends entirely on its objectivity: a project manager who keeps a green status out of optimism or fear of bad news deprives the steering committee of the ability to react in time.
Defining explicit criteria for each color — rather than leaving the assessment purely subjective — limits this bias. For example: red if the delivery date is at risk without immediate corrective action, amber if a risk needs heightened vigilance, green if the project is tracking to plan without significant variance.
A project that jumps straight from green to red between two committees, with no intermediate amber phase, almost always reveals reporting that failed to surface warning signs in time — not a problem that appeared suddenly.
Fewer indicators, better chosen
The temptation to keep adding indicators to a report, hoping to cover everything, often backfires: useful information drowns in volume, and the audience stops really reading the document. Reporting tightened around 5 to 8 key indicators, genuinely tracked and discussed, delivers more value than an exhaustive but shallow dashboard.
A simple test for evaluating existing reporting: ask each recipient which indicators they actually check, and which they systematically ignore. Indicators nobody ever looks at are good candidates for removal, regardless of the effort that went into producing them.
Choosing the right format, not just the right frequency
Format matters as much as content: visual reporting (trend charts, color coding) reads and sticks better than a dense table of numbers. For a steering committee that needs to make quick calls across several projects in a row, immediate readability of the format often matters more than exhaustive content.
Keeping a history of previous reports, rather than only showing the current state, also lets you visualize a trend — an indicator that degrades gradually across several consecutive committees is often more revealing than a single snapshot at one point in time.
Go further
Frequently asked questions
How often should reporting be produced?
It depends on the level: weekly for operational tracking, monthly for a steering committee in most projects. Too high a frequency at a strategic level overloads the audience without adding meaningful new information.
How do you keep reporting from becoming a mere formality?
By making sure it systematically triggers a discussion or a decision in committee, not just passive reading. Reporting that never leads to exchange or action quickly loses its purpose for those producing it.
Should project reporting be automated?
As much as possible for quantitative indicators (progress, budget), which reduces manual workload and the risk of error. Qualitative analysis (risks, points of attention) generally remains the project manager's job, bringing judgment that automation can't replace.
Does agile reporting differ from traditional reporting?
The principle stays the same (inform and help decisions get made), but indicators often differ: velocity, burndown charts and sprint completion rate replace or complement more classic percentage-progress indicators.
How do you respond to a project manager who keeps an overly optimistic status?
Defining objective, shared RAG criteria upfront, rather than leaving the assessment to the project manager's sole judgment, reduces this risk. A climate of trust where flagging a difficulty isn't seen as a personal failure also helps get more honest reporting.
Should reporting look the same across every project in a portfolio?
The core structure and indicators should stay consistent so the steering committee can compare projects at a glance, but the underlying detail can vary — a small project doesn't need the same depth of risk breakdown as a large, high-stakes one.
What's a common early sign that a reporting format needs to change?
When comments and clarifications during a steering committee consistently repeat information that should already be in the document, that's usually a sign the report isn't answering the questions the audience actually has — a good trigger to revisit its structure.