Running Projects With a Distributed Team

Most advice about remote project management is really advice about remote culture — trust your team, over-communicate, have fewer meetings. All fine, and none of it tells you how to build a schedule that survives a nine-hour time-zone gap. This piece is about the mechanics: what specifically breaks in a distributed project plan, and what to do about each failure.

The real problem is hand-off latency, not hours worked

A co-located team has an implicit property that nobody notices until it disappears: any two people can resolve a blocking question in under a minute. When a designer needs a decision from a product manager sitting six feet away, the cost is a tap on the shoulder. That cost is so close to zero that no plan ever accounts for it.

Move those two people eight time zones apart and the same question costs most of a day. Not because anyone is slower, but because the question is asked at 17:00 in London and read at 09:00 the next morning in San Francisco. The work did not get harder. The latency between dependent steps got dramatically worse, and that is a scheduling problem, not a communication one.

This is why distributed projects so often finish late despite everyone being busy. Utilisation looks fine. Throughput does not. The gap between them is hand-off latency, and it is invisible on a task board — a ticket sitting in "In Progress" looks identical whether it is being actively worked on or waiting on an answer from someone who is asleep.

Model the wait, don't hope it away

The fix is unglamorous: put the waiting in the plan. If a task requires a review from someone in a non-overlapping time zone, that review is not a zero-duration event appended to the task. It is a one-day task in its own right, with its own bar on the timeline.

Teams resist this because it makes the schedule look worse. It does not make the schedule worse — it makes the schedule honest. The delay was always there. Modelling it explicitly is what lets you see that a five-day feature is actually an eight-day feature once it passes through two cross-region reviews, and that restructuring who reviews what would save three days.

Once the waits are visible, the optimisations become obvious. You can co-locate a review with the work, batch approvals into a single daily window rather than scattering them, or give someone in the working time zone the authority to approve without escalation. All three are cheap. None of them occur to you while the delay is hidden.

Design the schedule around one overlap window

Every distributed team has a window when most people are awake simultaneously. It is usually two to four hours. Treat it as the scarcest resource in the project, because it is.

The instinct is to fill that window with standups and status meetings. This is exactly backwards: status is the one thing that transmits perfectly well asynchronously. Spend the overlap on the things that genuinely need synchronous bandwidth — resolving disagreements, working through an ambiguous design, making decisions with real trade-offs. Everything else belongs in writing.

A practical test: if a meeting could have been a document with no loss of quality, it should not be consuming overlap time. Apply that test honestly for a fortnight and most teams find they recover half their overlap window.

Write hand-offs as if the reader has no context, because they don't

A colleague picking up your work eight hours later has no memory of the conversation you had in your head while doing it. The single highest-return habit in distributed work is ending each piece of work with a written hand-off that answers three questions: what state is this in, what did I decide and why, and what is the next person's first action.

Three sentences is usually enough. The value is not the length, it is that the next person starts working instead of starting an investigation. The alternative — reconstructing intent from a diff and a ticket title — routinely costs an hour and sometimes produces a wrong conclusion that only surfaces days later.

This is where a visual board earns its place over a chat thread. A chat thread is chronological and infinite; nobody scrolls back far enough. A board holds the current state of each item where the next person will actually look for it.

Report on the plan, not on activity

Distributed teams over-report, because writing an update is the most legible way to demonstrate you were working. The result is a large volume of activity descriptions and very little signal about whether the project is on track.

The useful unit of reporting is movement against the plan: which tasks completed, which slipped, and what the slip does to the end date. That third part is the one almost everyone omits, and it is the only part a stakeholder actually needs. "The API integration slipped two days, which moves launch from the 14th to the 16th because it is on the critical path" is worth more than a page of accomplishments.

If your plan encodes dependencies, this becomes mechanical rather than a matter of judgement — the timeline tells you what a slip costs. If it does not, you are guessing, and the guess is usually optimistic.

The handful of habits that matter

• Put reviews on the timeline as real tasks with real durations, including the wait for a non-overlapping reviewer.
• Protect the overlap window for decisions and disagreements only. Status goes in writing.
• End every work session with a three-sentence hand-off: state, decisions, next action.
• Report slips in terms of the end date, not in terms of effort expended.
• Give the working time zone decision authority where you can. An approval that has to cross a time-zone boundary costs a day every time it happens.
• Keep one canonical plan. Two out-of-date plans are worse than one imperfect one, because now people disagree about what is true.

Where tooling helps, and where it doesn't

No tool fixes an unclear plan or an unwillingness to write things down. What tooling does well is remove the maintenance cost that makes people abandon a plan in the first place. If updating the schedule after a two-day slip means manually dragging fourteen dependent bars, the schedule stops being updated by about week three — and a stale plan is actively harmful, because it looks authoritative while being wrong.

Automatic recalculation is what keeps a distributed plan honest. Change one date, and every downstream task, milestone and critical-path warning updates with it. That turns replanning from an afternoon's work into a ten-second operation, which is the difference between a plan that reflects reality and one that reflects the day it was written.

If you want to see the shape of this, our complete guide to Gantt charts covers dependency modelling and critical path in depth, and Gantt vs Kanban is worth reading if you are still deciding which view your team should live in day to day.