A project review becomes expensive when every person reads their task list aloud and the important decisions are left until the last minute. The team leaves informed about activity but uncertain about what needs to change.
Use written updates for routine progress and reserve the conversation for exceptions. This guide describes a lightweight review for client projects: prepare the facts, identify the decision, involve the right people and record what changed.
The useful idea
Read routine status before the meeting. Spend the conversation on decisions, changed commitments and work that needs somebody’s help.
Prepare a short update for each active project
Ask the project owner to report progress against the next client commitment, not every task completed. Include the next milestone, any risk to it, the decision needed and the person who can help. Link the work record for detail.
Keep the format stable so the team can scan it before the review. Atlassian’s weekly project update playbook also uses written updates to make progress and challenges visible asynchronously. The template below is our own adaptation for client-facing delivery.
- What changed since the last update?
- What is the next client commitment?
- Is anything blocking or threatening it?
- Which decision or help is needed, and by when?
Choose which projects need discussion
A project with a clear plan and no unresolved decision may not need meeting time. Prioritise changed dates, missing inputs, new scope requests, unclear ownership and decisions affecting another team’s work.
Make the agenda visible beforehand. Invite a person because they can supply context or make a decision, rather than because their title normally appears in the meeting. Give owners a way to raise a new exception when circumstances change.
Review commitments and dependencies together
Start with what the client is expecting next. Ask whether the work, inputs and review process still support that commitment. A task can be on track while its dependency is missing; a milestone can be technically complete while waiting for an approval nobody requested.
If a date is at risk, describe the evidence and the next action. Avoid using a status colour as the whole update. ‘At risk because copy is not approved; account lead will confirm the review date today’ gives the team a route forward.
| Review question | Useful evidence |
|---|---|
| What did we promise? | Current milestone and client conversation |
| What is blocking it? | Missing input or unresolved decision |
| Who can move it? | Named owner with the right access |
| What changes now? | Decision, action and communication needed |
Turn discussion into a recorded decision
Name the question before debating it. For example, ‘Do we move the presentation or reduce the content covered in this round?’ is a decision. ‘The schedule is difficult’ is a situation that still needs a question.
Record the outcome, the reason, the owner and any affected commitments. If the decision cannot be made yet, record what evidence is missing and when it will be revisited. ‘We discussed it’ should not be the final state of an important issue.
Close the loop with the client and the team
Update the work record and notify the people who need to act. A change to an internal plan may also require a client message, a revised review date or an update to the scope reference. Assign these follow-ups explicitly.
The person communicating with the client should know what was decided and what remains uncertain. Do not ask them to infer the new commitment from a task due date. Keep the source of the decision beside the action it created.
Check whether the review changed anything useful
After a few cycles, look at repeated blockers and decisions that return without progress. You may need clearer briefs, better client input deadlines or a different decision maker in the conversation. Adding more meeting time is only one possible response.
Retire fields and agenda items that do not affect action. The review is doing its job when people know which commitment changed, what they need to do and where the current plan lives. It does not need to cover every project every week to be useful.
Weekly client project update
Share this before the review; add decisions afterwards.
WEEKLY PROJECT UPDATE Project and owner: [names] Week ending: [date] Progress against outcome: [brief summary] Next client commitment: [deliverable / date] Current assessment: [on track / at risk / blocked, with evidence] Inputs or decisions needed: [item / owner / needed by] Change since last review: [scope / date / responsibility] Decision requested: [specific question] Decision recorded: [outcome / reason / owner / date] Client follow-up: [action / owner / date] Current plan: [link]
Sources and further reading
Further reading on asynchronous project updates. No research metrics from this source are claimed here.
Bring the context into your workspace.
Explore how Tamaam connects the relationship and the work around it. Tamaam is in development; product pages show previews and illustrative workflows. Joining early access does not start a subscription.
Found something we should clarify? Send a correction or question.
