Remote Workforce Review

Home / Guides / Running a Project When Nobody Shares a Room

Running a Project When Nobody Shares a Room

Projects fail at distance in a particular way: not dramatically, but through a slow accumulation of small divergences that nobody notices until integration.

In an office those divergences got corrected constantly and invisibly — someone overheard a wrong assumption, someone glanced at a screen, someone asked a question in passing. Remove that and the corrections stop happening.

Write the shape down first

What done looks like, specifically enough that two people would agree whether it had been reached.

Who decides what. Not a RACI matrix nobody reads — a short list of the decisions this project will require and who makes each. Ambiguous ownership resolves itself by conversation in an office and by stalling remotely.

The assumptions. This is the one people skip and the one that causes the damage. Every project rests on beliefs about what other teams will deliver, what the constraints are, what the users want. Writing them down makes them checkable; leaving them implicit means two people work for three weeks against incompatible assumptions.

Shorten the feedback loop

The single most effective intervention. Divergence is cheap to fix at three days and expensive at three weeks.

Show work early and unfinished. A rough draft shared on day two is worth more than a polished one on day fifteen. This requires making it socially safe to share incomplete work, which is a cultural matter the project lead sets by doing it first.

Integrate continuously rather than at the end. Whatever "integrate" means for your work — merging, combining sections, assembling the deck — do it constantly.

Define checkpoints by output, not by date. "Wednesday standup" produces status. "Draft of section two circulated for comment" produces something to correct.

Status without meetings

A written update, on a fixed cadence, in a fixed place, containing four things: what moved, what did not, what is blocked and on whom, what is next.

The value is not the reading. It is that writing it forces the author to notice their own drift, which is why the discipline matters more than the format.

Blocked items need a name and a date. "Waiting on design" is not actionable. "Waiting on Priya for the flow diagram, needed by Thursday" is.

The dependency problem

Cross-team dependencies cost far more at distance: more scheduling, more waiting, more misunderstanding of what was actually asked for.

Ask early and in writing, with the specific thing, the reason and the date. Verbal requests across teams evaporate.

Assume slower. A dependency that took three days in an office takes a week distributed. Plan for it rather than discovering it.

Reduce dependencies at design time. Two teams that must coordinate weekly should probably be one team, or the work should be split differently.

Where to insist on synchronous

Not everything, but these:

Kickoff. Everyone in a call, working through the shape and the assumptions together. Worth the scheduling cost.

Disagreement. Three sharpening messages in a thread means a call.

Integration points. When separately built pieces first come together.

Post-mortem. Written first, discussed live.

The signal to watch

Two people describing the project differently.

Ask three participants what the project is for and what done looks like. If the answers diverge, they have been diverging for a while, and no amount of status reporting was going to reveal it. Ask early and repeat.