Running a project across time zones: how a remote team keeps clients informed and in control

Many projects today are delivered across borders and time zones. A client in one country works with a team in another, and the two sides share only a few hours of working day, if any. Done badly, this means delays, misunderstandings and a nagging feeling on the client’s side that they cannot see what is happening. Done well, it works smoothly, and sometimes better than a co-located project, because it forces habits that every team should have.

This article describes the working practices that help a distributed team keep clients informed and in control. They apply whether you are commissioning a GeoAI model, an assistant, a 3D capture or a website.

Principle 1: make the rhythm predictable

The most reassuring thing for a client is not constant contact, but a reliable pattern. They know when to expect news, and they know it will arrive.

• A short written update every week, on the same day and in the same format: what was done, what is next, what is blocked and what decisions are needed.
• A regular call, perhaps every one or two weeks, kept to a fixed length with an agenda.
• A demonstration of something real at least every two weeks.
• A monthly review with the sponsor of progress against the plan, budget and risks.

Principle 2: find and protect the overlap

Look at both teams’ working hours, and agree a window of one to three hours that overlaps. Protect it for the things that need real-time conversation: planning, difficult decisions and demonstrations. Everything else can be handled in writing, at each side’s own pace.

• Agree the overlap window and the time zone for all scheduling, and stick to one reference to avoid confusion.
• Keep calls short and focused. A good call has an agenda, notes and a list of decisions.
• Be careful with daylight saving changes, which shift the overlap twice a year in some places.
• Respect local holidays and festivals on both sides, and put them on a shared calendar.

Principle 3: write it down

In a distributed team, anything that is not written down does not exist. Notes from a call, a decision made in a chat or an assumption made by a developer are all invisible to people who were not there, and to the same people six weeks later.

• Decision log: a simple list of what was decided, by whom, when and why.
• Assumptions and risks list: what we are assuming about data, access and people, and what could go wrong.
• Meeting notes with actions, shared within a day.
• A single project space where documents, designs, data descriptions and the plan live.

Principle 4: write for someone who is asleep

Asynchronous messages should be understandable without a follow-up question, because the answer may take a day.

• State the question or request clearly, with the context needed to answer it.
• Offer options and a recommendation, rather than an open question.
• Say what is needed, from whom and by when.
• Attach the screenshot, file or link, not a description of it.
• Confirm decisions in writing after a call.

A client who can answer in two minutes, because the question was well framed, will answer often. A client who must work out what is being asked will leave it until later.

Principle 5: show, do not only tell

Reports can say that everything is on track. A working demonstration shows it. Plan for something visible each cycle.

• For GeoAI: a map of the latest results, with a note of what has improved and where the model is weak.
• For assistants: a live session answering real questions, including hard ones.
• For 3D and immersive work: a link to the current model, opened in the browser.
• For platforms: a staging site the client can click through.

Showing works in progress, flaws included, builds trust. Clients are usually more comfortable with honest roughness than with a polished surprise at the end.

Handling decisions and approvals

• Name a single decision-maker on each side, and a backup.
• Agree what can be decided by the team and what must be escalated.
• Set response times for approvals, and say what happens if they are missed.
• Batch questions into the weekly update when they are not urgent, and flag urgent ones separately.

Quality, handover and continuity

• Work in the open: shared code repositories, ticket lists and documents that the client can see.
• Review each other’s work, with written comments, before it is shown.
• Document as you go, so that handover is a matter of tidying, not remembering.
• Have a deputy for each key role, so that holidays and illness do not stop the project.
• Agree the handover early: what will be delivered, in what format, with what training.

Building the relationship

Trust is harder to build when people rarely meet. A few simple habits help.

• Begin with a proper kick-off call where everyone introduces themselves and their role.
• Share a team page with photos and short descriptions, so that names have faces.
• Be quick to raise bad news. Clients are far more forgiving of a problem reported early than of one discovered late.
• Check in on how the process feels, not just on the work, every month or two.
• Meet in person once if you can, for example at a milestone.

Tools that keep it simple

• A shared document or wiki for the plan, decisions and notes.
• A task board that both sides can see.
• A messaging channel for quick questions, with an agreement not to use it for decisions that must be recorded.
• A video call tool with recording or notes, where all participants agree.
• A shared folder or repository for deliverables, with clear naming.

A weekly update template

1. 01Done this week, in plain language, with links.
2. 02Planned for next week.
3. 03Blocked or at risk, and what we need from you.
4. 04Decisions needed, with our recommendation and a deadline.
5. 05A visible result: a link to a map, a model or a demonstration.
6. 06Budget and timeline status in one line.

Frequently asked questions

How many hours of overlap do we need?

Often one to three hours is enough if the rest of the work is documented well. More helps in the first weeks, when mutual understanding is being built.

How do we avoid endless meetings?

Replace status meetings with written updates, and use calls for decisions and demonstrations. Keep every call to an agenda.

Is a remote team slower?

Not necessarily. Without constant interruptions, work can be faster. Delays happen when questions wait for answers, which is why clear writing and fast decisions matter.

How do we handle language and cultural differences?

Use plain, direct wording and confirm key points in writing. Ask about local working patterns and holidays, and be patient with each other’s style.

Distance is not the enemy of a good project. Unclear communication is. A steady rhythm, clear writing, visible progress and quick, honest answers make a remote team feel close, and make the client feel, rightly, that the project is in good hands.