One thing I have learned over the years is that every project meeting should not carry the same level of detail. The delivery team needs detail. Management needs visibility. Senior leadership needs decisions. I normally look at project reporting as a rhythm that changes as the project moves from start to delivery, escalation, go-live, and closure.

The Reporting Rhythm

Meeting / Update When Main Purpose Expected Outcome
Project Kick-off Once, at project start Align scope, roles, dates, and governance Everyone understands how the project will run
Daily Stand-up / Delivery Sync Daily, if needed Priorities, blockers, and dependencies Immediate actions and blockers are clear
Weekly Working-Level Meeting Weekly Detailed progress, RAID and dependencies Clear actions, owners and next-week plan
Weekly Management Status Weekly Overall project health and support needed Management knows where attention is required
Steering / Governance Review Monthly, fortnightly, or at key decision points Major risks, deviations and decisions Clear direction or executive decisions
Exception / Escalation Update As required Raise urgent matters early Right decision-maker is engaged quickly
Go-Live / Readiness Review Before launch Confirm readiness and remaining risks Clear go/no-go position
Project Closure Review At completion Confirm delivery, handover and closure Ownership and closure are agreed
The exact frequency can change depending on the project. What matters more is that every meeting has a clear purpose and does not simply repeat the previous one.

1. Project Kick-off: Remove Ambiguity Early

The kick-off is where I try to remove as much ambiguity as possible before delivery starts. It should answer how the project will actually operate, not just repeat what is already written in the charter or contract. I normally cover:
  • Scope and key deliverables
  • Important dates
  • Roles and responsibilities
  • Major dependencies
  • Governance and reporting cadence
  • Escalation and decision paths
Expected outcome: Everyone knows what we are delivering, who owns what, and how the project will be managed.

2. Daily Stand-up: Keep Delivery Moving

The daily discussion is an execution meeting. I use it to quickly understand whether the team can continue working or whether something needs immediate attention. Keep it around:
  • What changed?
  • What is being worked on?
  • What is blocked?
  • Who is waiting on whom?
  • What needs immediate follow-up?
If we spend half an hour explaining project history every morning, the stand-up has probably lost its purpose. Expected outcome: Blockers are visible and immediate actions are owned.

3. Weekly Working-Level Meeting: Control the Detail

This is normally the main delivery-control meeting. I use it to step back from daily activities and check whether the project is actually moving according to plan. I would review:
  • What did we commit to last week?
  • What was actually completed?
  • What are we planning next week?
  • Are key activities and dates still on track?
  • What actions remain open?
  • What risks or issues have changed?
  • What dependencies or decisions are blocking us?
Expected outcome: The team leaves with a realistic next-week plan, clear owners, and visible blockers.

4. Weekly Management Status: Give the Project Picture

Management usually does not need every task from the project plan. My job as PM is to convert all that detail into a short view of where the project stands and where management may need to help. I normally structure it around five questions:
  1. What did we achieve last week?
  2. What are we planning next week?
  3. Are we still on track?
  4. What risks or issues need attention?
  5. What decision or support do we need?
Expected outcome: Management understands project health and knows exactly where support is required.

5. Steering / Governance Review: Focus on Decisions

By the time information reaches senior governance, I reduce the detail further. This meeting should focus on matters that need direction, approval, or executive intervention. Typical topics are:
  • Major deviations from plan
  • Critical risks or issues
  • Scope, budget, or timeline concerns
  • Major dependencies
  • Decisions required
A governance meeting should not become a detailed task review. Expected outcome: Clear decisions, direction, or intervention from senior leadership.

6. Exception / Escalation Update: Do Not Wait

Scheduled meetings should never become a reason to delay escalation. If a critical dependency is blocked, an important decision is holding delivery, or a major risk is becoming an issue, I raise it with the right people rather than waiting for the next weekly or governance meeting. If leadership hears about a major problem for the first time in a steering meeting, we probably escalated it too late. Expected outcome: The right decision-maker is engaged early enough to prevent avoidable impact.

7. Go-Live / Readiness Review: Change the Conversation

As go-live gets closer, I stop looking only at whether development or project activities are complete. The question now becomes: are we genuinely ready to put this into production and support it afterwards? The readiness discussion should cover:
  • Critical defects and open issues
  • Business readiness
  • Technical readiness
  • Data or integration readiness
  • Cutover activities
  • Operational and support arrangements
  • Outstanding risks
  • Go / no-go recommendation
The important part is that readiness owners confirm their areas rather than the PM simply declaring the project ready. Expected outcome: There is a shared and evidence-based view of whether the project is ready to launch.

8. Project Closure Review: Close the Loop Properly

A project is not finished simply because the system went live. I use the closure review to make sure remaining work has a clear owner and the project can genuinely move out of delivery mode. Confirm:
  • What was delivered
  • What remains open
  • What has moved to operations or support
  • Lessons learned
  • Benefits ownership
  • Final documentation and handover
  • Formal sign-off or closure
A useful question is: Is the project really complete, or have we simply moved the remaining work somewhere else? Expected outcome: Delivery, handover, remaining actions, and ownership are formally clear.

Who Should Be in the Room?

Not everyone needs to attend every project meeting.
Meeting Typical Attendees Usually Led / Presented By
Project Kick-off Sponsor, PM, project team, stakeholders, vendors PM leads; Sponsor may open
Daily Stand-up Core delivery team PM / Scrum Master facilitates
Weekly Working Meeting PM, leads, vendors, business and technical representatives PM facilitates; leads contribute
Weekly Management Status PM, business owner, managers, key stakeholders PM presents
Steering / Governance Review Sponsor, senior management, PM, selected leads Sponsor chairs; PM presents
Exception / Escalation PM and relevant decision-makers PM or issue owner
Go-Live / Readiness Review PM, business, technology, operations, support, vendors PM coordinates; readiness owners contribute
Project Closure Review Sponsor, PM, business owner, PMO, key stakeholders PM presents; Sponsor confirms closure
A simple rule I use: if someone neither provides input, owns an action, nor makes a decision, they probably do not need to be in that meeting. Good reporting is not about producing more reports. It is about getting the right information to the right people early enough to act.