Distributed Team Coordination in IS Projects

When I started working on IS research coordination problems, I kept running into the same pattern in project failure accounts. The technical work was roughly on track. The integration tests passed. The code review process was functioning. But the project was running three weeks behind on deliverables, and nobody could point to a single specific thing that was causing the delay. The lag was everywhere and nowhere. It was in the half-day gaps between questions asked and answers received. It was in the misunderstandings about scope that took a week of asynchronous email to untangle. It was in the decision that should have taken thirty minutes in a room together and instead took eleven days of back-and-forth across time zones.

This is the coordination overhead of distributed IS projects. It is real, it is well-documented in the research literature, and it is almost never adequately reflected in the project plan.

The coordination challenges in distributed IS teams have been studied under several labels in IS research, most commonly globally distributed software development and virtual teams. The core findings are consistent. Time zone differences create communication latency that does not affect the technical work in isolation but compounds across collaborative dependencies. A question asked at the end of the day in Austin may not be answered until the following morning, which means if the answer determines the next step, the effective workday for that dependency is a few hours, not eight. When multiple such dependencies stack across a sprint, the cumulative effect can look like team underperformance, when it is actually a structural coordination problem.

Jarvenpaa and Leidner's (1999) work on trust in global virtual teams is widely cited in IS research as an early empirical examination of how trust forms and operates in distributed teams. Their finding was that swift trust, a form of trust based on initial signals of professional competence and communication responsiveness rather than long-term relationship history, matters enormously in virtual team performance. I want to be careful here because I have not verified this paper's full text against a local study-hub file, so I am hedging: this is widely cited in the virtual team literature and I am working from my reading of the field rather than a verified local source. The core observation, that virtual teams rely on different trust mechanisms than collocated ones, is defensible from the broader research stream.

The sociotechnical perspective adds something that purely technical accounts of coordination miss. Distributed teams rely much more heavily on digital artifacts, documents, tickets, code comments, pull requests, chat logs, to coordinate than collocated teams who can use conversation, whiteboard, hallway conversation, and ambient observation of what teammates are working on. In a collocated team, a lot of coordination happens passively, just by being in the same space and picking up on what people are doing. Distributed teams have to make that coordination explicit, which means it has to be written down, organized, and maintained. The quality and completeness of those artifacts becomes critical, and it is also highly variable across teams and projects.

This has a practical consequence that IS project managers often underestimate. In a distributed project, documentation is not a bureaucratic overhead. It is the coordination infrastructure. A ticket that is ambiguously worded, a commit message that omits context, a Slack message that does not reference the relevant document: each of these is a coordination failure waiting to become a delay. The same message would not matter in a collocated context because someone could just walk over and ask. In a distributed context, each ambiguity creates latency.

Language and cultural differences compound these problems in globally distributed teams. Technical communication is already dense with implied context and shared assumptions. When team members have different first languages, different professional communication norms, and different assumptions about what counts as a complete answer versus a partial one, interpretation failures become more frequent. These are not failures of competence. They are failures of shared context, and they require structural solutions, shared glossaries, explicit communication norms, more time for confirmation, not individual effort to communicate better.

According to Gartner research on the digital workplace and collaboration technology, organizations that adopted distributed work during the COVID-19 period without supporting infrastructure for asynchronous coordination saw measurable impacts on project delivery and team cohesion (see https://www.gartner.com/en/newsroom for Gartner's current releases on this topic). I am hedging specific percentages here, but the directional finding is consistent with what the IS project management literature has shown for years before the pandemic made remote work universal.

COVID-19 did not create the distributed team coordination problem. It made it everyone's problem at once. Before 2020, organizations could choose whether to have distributed teams. After 2020, many organizations discovered they were managing distributed teams with processes, norms, and tooling built for collocated ones. The IS project management research on globally distributed software development had been documenting the coordination problems for at least two decades. The pandemic accelerated the practitioner recognition of what researchers already knew.

What I think is underappreciated is how much the coordination overhead varies by the type of dependency, not just the distance. Two developers in different cities working on independent modules face minimal coordination overhead. Two developers in different cities working on tightly coupled components, where one person's output is the other person's input, face serious latency problems unless they build explicit synchronization points. Mapping the dependency structure before distributing the work is the step that most project plans skip.

The research on transactive memory systems, developed through work by Wegner (1987) and operationalized in IS contexts by Lewis (2003), is also relevant here. Transactive memory is the shared knowledge in a group about who knows what. In collocated teams, you build this informally. You learn over time who to ask about which problem. In distributed teams, building that shared mental map of expertise requires deliberate effort, because the informal channels through which it normally develops are absent or attenuated.

I do not think distributed IS projects are inherently more likely to fail than collocated ones. But they are more sensitive to coordination infrastructure. A well-run distributed project with strong artifacts, clear async norms, and explicit dependency management can outperform a poorly run collocated project. The collocated team can cover for coordination failures with face time. The distributed team cannot.