Many project teams now rarely, if ever, meet in one place. Design happens in one city, fabrication in another and installation on a remote site. Specialists join from other states or other countries. Partners, suppliers and clients each bring their own people, systems and habits. Even teams in the same organisation may be split across offices, home and site. Distance gives access to scarce skills, lower costs and longer working days, but it also magnifies every weakness in how a team communicates, decides and builds trust.
A virtual team is not a co-located team that happens to use video calls. In a shared office, a great deal of coordination happens informally: a quick question at a desk, a sketch on a whiteboard, a conversation over coffee that reveals a problem early. Remove those, and electronic channels must carry a load they were never designed for. Information becomes unevenly shared, small misunderstandings grow, sites form their own cliques, and trust erodes quietly until a crisis exposes it.
This article explains what makes a team virtual, the problems distance creates, how to set up a distributed project team, how to communicate and decide across time zones, how to work across cultures without stereotyping, and how to build and keep trust. It is general information for project managers, team leaders and business owners whose projects span sites, organisations or countries.
What makes a team virtual
A project team becomes virtual when its work crosses one or more boundaries:
- Time: members work different hours or in different time zones.
- Space: members are spread across buildings, cities, sites or countries.
- Organisation: members belong to different companies, such as joint venture partners, consultants, suppliers and the client.
- Culture: members bring different national, linguistic and professional norms.
The more boundaries a team crosses, the higher its coordination cost and the more deliberate its leadership needs to be. Virtual distance is a spectrum. Two groups on the same industrial site, with different managers, schedules and systems, can show the same symptoms as teams on different continents.
The problems distance creates
Research and practice on distributed teams point to recurring issues:
- Fragile trust: people trust those they know. Without informal contact, trust builds slowly and breaks quickly when something goes wrong.
- Weak shared identity: members identify with their site or company rather than the project.
- Unequal information: people near the project manager or the main office hear things first; others learn late or not at all.
- Cliques and “us and them” thinking between sites or organisations.
- Misread communication: brief messages lose tone and context; silence is misinterpreted as agreement or disengagement.
- Hidden conflict: disagreements surface late, often in formal correspondence rather than early conversation.
- Uneven workload and recognition: remote contributions are less visible.
None of these is inevitable. Each can be designed against.
Setting up a distributed team
A team charter
At the start, agree a short team charter covering:
- The project’s purpose, objectives and what success looks like.
- Roles and responsibilities, including who decides what. The decision rights before meetings article explains how to make these explicit.
- Working hours, overlap windows and expected response times for different channels.
- Which tools are used for what, and where the single source of truth for documents, schedules and decisions sits.
- Meeting rhythm and conventions.
- How conflict and escalation will be handled.
- Language and document conventions, such as units, date formats and naming.
Start face to face if possible
If the budget allows one in-person meeting, hold it at the start. A kick-off where people meet, work through the plan together and share meals builds relationships that sustain months of remote work. If travel is impossible, invest in a longer, well-facilitated virtual kick-off with time for introductions and informal conversation.
Plan for onboarding
People join distributed projects partway through. A structured onboarding pack, a named buddy and early introductions to key contacts at each site help new members contribute quickly and feel part of the team.
Communicating across time and distance
Overlap windows and fairness
Map each location’s working hours and find the overlap window for live meetings. Remember that daylight saving changes overlaps twice a year: within Australia, Sydney and Melbourne observe daylight saving while Brisbane and Perth do not, and other countries change on different dates. Where overlap is small, rotate inconvenient meeting times so the same people do not always join at dawn or late at night.
Synchronous and asynchronous work
Use live meetings for what they do best: building relationships, resolving complex or contentious issues, and making decisions that need discussion. Use asynchronous channels, such as shared documents, task systems and written updates, for status, information sharing and routine questions. Written updates should be complete enough to stand alone, with context, the decision or question, and the deadline.
Clear expectations matter: which channel is for urgent issues, how quickly people should respond on each and how to escalate when someone is unavailable.
Running good virtual meetings
- Send an agenda and papers in advance, so people in other time zones and languages can prepare.
- Use video where practical, especially for relationship-building and difficult discussions.
- Facilitate actively: invite quieter sites and individuals by name, check understanding and avoid side conversations in the main room.
- Make the meeting equal: if some participants are together in a room and others are remote, have everyone join individually or give remote members a strong voice.
- Record decisions and actions in writing and circulate them promptly.
The presenting on camera and online article covers practical skills for communicating well through a screen.
Information equity
Share the same information with all sites at the same time. Keep project documents, schedules, risks and decisions in one accessible place. Avoid making decisions in corridor conversations at the main office and announcing them later. When informal decisions do happen, write them up and share them quickly.
Follow-the-sun working
Teams spread across time zones can hand work from one region to the next, extending the working day. This works for well-defined tasks with clear hand-over notes, such as design checking, software testing or document production. It fails when hand-overs are vague, so define what a complete hand-over contains and who confirms receipt.
Working across cultures
National and organisational cultures shape how people communicate, make decisions, treat hierarchy, handle disagreement and view time. Frameworks such as Geert Hofstede’s cultural dimensions and the GLOBE study describe broad differences between national cultures, for example in attitudes to hierarchy, uncertainty and individual versus group achievement. They are useful prompts for awareness, but they describe averages, not individuals. Treat them as hypotheses to test, never as labels for people.
Practical points:
- Avoid parochialism, the assumption that one’s own way of working is the normal or correct one.
- Make assumptions explicit: what “done” means, how approvals work, what a deadline commits people to, how bad news should be raised.
- Check understanding rather than relying on “yes”, which in some contexts means “I heard you” rather than “I agree” or “I can do that”.
- Write clearly in plain language, avoiding idioms, sports metaphors and jokes that do not translate.
- Respect differences in public holidays, religious observances and working norms.
- Learn from colleagues about how they prefer to work, and share your own preferences openly.
Professional and organisational cultures matter as much as national ones. Engineers, contractors, clients and suppliers each have their own norms about risk, documentation and authority.
Building and keeping trust
Trust in distributed teams is built mainly through reliability: doing what you said, when you said, and being open early when you cannot. Leaders can strengthen it by:
- Keeping commitments visible, so people see each other’s reliability.
- Responding promptly and acknowledging messages even when a full answer will take longer.
- Recognising contributions from all sites publicly.
- Creating informal contact: short social time at the start of meetings, virtual coffee sessions and occasional visits.
- Rotating people between sites where possible, so relationships span locations.
- Addressing conflict early and directly, preferably by video or phone rather than email.
- Making it safe to raise problems, so issues surface while they are small.
Leading self-managing and distributed teams
Some distributed teams are given substantial autonomy to organise their own work. Self-managing teams can be highly effective when they have clear goals, the skills and information to decide, stable membership and support from leaders. Without those conditions, autonomy turns into confusion. In distributed settings, leaders shift from directing tasks to setting direction, removing obstacles, coaching and connecting people across sites.
Wellbeing and workload
Distributed work can blur boundaries between work and home and hide overload. People in time zones far from head office may routinely join early or late calls on top of a full day. Remote members may feel isolated, and their struggles are less visible. Leaders should watch for signs of fatigue, keep meeting loads reasonable, respect agreed working hours, and check in individually rather than relying on group calls. Work health and safety duties, including for psychosocial risks such as excessive workload and isolation, apply to remote and distributed work as they do in an office.
Teams that span organisations
Many project teams combine people from the client, consultants, contractors and suppliers. Each organisation has its own systems, approval rules, commercial interests and confidentiality limits. Agree early which information can be shared, through which systems, and how commercial matters are kept separate from technical collaboration. Align document numbering, revision rules and approval routes so that drawings and decisions mean the same thing to everyone. Where possible, form a single integrated project identity, with joint meetings and shared goals, while respecting each party’s contractual responsibilities.
Tools and records
Choose a small set of tools and use them consistently: a shared document repository with version control, a schedule and task system, a messaging tool for quick exchanges and a video platform. Keep a decision log and an action register that everyone can see. More tools are not better; fragmented tools create fragmented information. Check security and access arrangements, especially when several organisations share information.
A worked example
This is an illustrative example. An Australian engineering firm is delivering a materials handling upgrade with a project office in Brisbane, a site team in Western Australia, a design partner in India and a fabricator in Vietnam. Three months in, the project is behind schedule. The design partner says drawings were held up by unanswered questions; the fabricator says it received late, inconsistent revisions; the site team feels left out of decisions made in Brisbane.
Diagnosis. The project manager maps working hours. Brisbane is on UTC plus 10 hours with no daylight saving, Perth on UTC plus 8, India on UTC plus 5 hours 30 minutes and Vietnam on UTC plus 7. A window from 1 pm to 4 pm Brisbane time corresponds to 11 am to 2 pm in Perth, 8.30 to 11.30 am in India and 10 am to 1 pm in Vietnam, but meetings had been scheduled at 9 am Brisbane time, before the Indian and Perth teams started work. Questions were being sent by email to individuals, and decisions made in Brisbane meetings were not written up.
Changes.
- A two-day facilitated virtual workshop resets the team charter, roles, decision rights and communication rules.
- Coordination meetings move into the shared overlap window, with an agenda circulated a day ahead.
- All technical questions go into a shared register with owners and due dates, visible to every party.
- Drawing revisions are released only through the shared document system, with a weekly release note.
- Decisions are logged and circulated within 24 hours.
- The site lead joins the weekly leadership meeting, and the design partner’s lead engineer visits Brisbane and the site once the travel budget is approved.
Result. Within six weeks, the number of overdue technical questions falls sharply, the fabricator stops receiving conflicting revisions, and the schedule stabilises. The site team reports feeling part of decisions, and disputes between parties shift from email to early conversations.
Applying this in an Australian business
- Recognise virtuality, even between nearby sites and partner organisations.
- Agree a team charter covering roles, decisions, tools and response times.
- Meet in person at the start where possible.
- Map time zones and daylight saving, and share inconvenience fairly.
- Use live meetings for relationships and decisions, and written channels for the rest.
- Share information equally through one source of truth.
- Make cultural assumptions explicit without stereotyping.
- Build trust through visible reliability and early conflict resolution.
Where virtual teams go wrong
- Treating distributed work as normal work over video.
- Meetings at times that suit only head office.
- Decisions made informally and never shared.
- Tool sprawl and documents in personal inboxes.
- Silence read as agreement.
- Cultural labels applied to individuals.
- Conflict handled by email.
Questions to ask about a distributed project team
- Which boundaries of time, space, organisation and culture does this team cross?
- Has the team agreed how it will communicate, decide and escalate?
- When can everyone meet live, and who bears the inconvenience?
- Does every site get the same information at the same time?
- How are new members brought in?
- How would we know if trust between sites were declining?
Bringing it together
Virtual and global project teams give access to talent and capacity that no single location can provide, but distance magnifies weaknesses in communication, information sharing and trust. Lead them deliberately: agree a charter, meet early, map time zones fairly, use live and written channels for what each does best, keep one source of truth, make cultural assumptions explicit and build trust through visible reliability and early handling of conflict. The result is a team that works as one project rather than a collection of sites.
Source: KEVOS editorial notes, drawing on earlier KEVOS project leadership study material on global virtual project teams, implementing virtual teams, self-managed and virtual teams, and cultural fluency, together with established project leadership practice. The worked example is illustrative. This article is general information.
