One weekly meeting is enough — if it is the right one

Outsourced projects tend to drift towards one of two failure modes. Either the client is pulled into daily standups, design debates and bug triage, and slowly becomes an unpaid project manager. Or the client steps back entirely, hears nothing for six weeks, and then sees something that does not match what they expected.

A single, well-run weekly meeting avoids both. It works when the meeting is short, when it is prepared in writing, and when everything that does not need the client’s decision happens somewhere else.

Start with a written update the day before

The meeting should not be where information is delivered. It should be where decisions are made. That only works if the information arrives first.

A day before the call, the delivery lead sends a one-page update:

• Milestone status. Where the current milestone stands against plan, in one or two sentences, with a clear on track / at risk / late.
• Done since last week. What was finished, with links to anything that can be seen or tried.
• Next week. What will be worked on.
• Decisions needed. Each one stated as a question, with options and a recommendation.
• Risks and changes. Anything that could affect scope, budget or date.

If the update is written well, a busy stakeholder can read it in five minutes and arrive at the meeting already knowing what matters.

The 30-minute agenda

1. Status against the milestone — 5 minutes. Confirm the written status and answer questions about it. No slide decks, no retelling of the update.

2. Demo of working software — 10 minutes. Show what was built, running, not screenshots or a progress percentage. This is the most important part of the meeting. It surfaces misunderstandings while they are still cheap, and it keeps everyone honest about real progress.

3. Decisions — 10 minutes. Go through the decisions listed in the update. Each should end with an answer, an owner, or a date by which the answer will come. Decisions made here are written down and sent round the same day.

4. Risks and scope changes — 5 minutes. Review anything that could move the date or the budget. Proposed changes are noted and then estimated separately — they are not approved in the meeting on the strength of a conversation.

Thirty minutes, the same time every week, with the same core people.

What belongs outside the call

• Daily standups. They are for the delivery team to coordinate its own work. The client does not need to attend.
• Bug triage. Handled in the issue tracker, asynchronously, against agreed priorities. Only disagreements about severity come to the weekly call.
• Design reviews. Scheduled as separate sessions when there is enough to review, with the right people present.
• Technical deep-dives. Architecture choices are discussed with those who need to understand them, and the outcome is summarised in the update.
• Commercial and contract matters. Budget changes, invoices and contract terms go to a separate conversation with the people who own them.

Keeping these out protects the weekly call from turning into a two-hour catch-all that nobody prepares for.

Signs the meeting is not working

• The written update arrives late, or not at all.
• The demo is replaced by a description of what was done.
• The same decision appears on the agenda two weeks in a row.
• Surprises about scope or dates come up outside the meeting first.
• The client is regularly asked technical questions they cannot answer.

Any one of these is a signal to fix the process before it becomes a problem with the project.

How we run it

At ANASBRENT the delivery manager runs this rhythm on every engagement: written update, one weekly review, decisions recorded, everything else handled between the partner and us. Clients get one meeting a week and one person to talk to. If that is how you would like your next build to run, start with a brief.