Explicit Shared Objectives

Definition

Virtual teams must document and explicitly communicate shared goals, project scope, and decision-making authority rather than assuming team members will understand implicit norms. In colocated teams, much understanding accumulates through informal conversation and observation. Virtual teams lack these opportunities and must compensate by making expectations, standards, scope, and roles visible in writing on shared repositories like wikis.

In the Book

Chapter 1 emphasizes that teams with unclear shared objectives "will fracture along political or functional lines and the project will fail." The book advocates the SMART goal-setting approach: goals must be Specific (identify the problem), Measurable (determine if achieved), Attainable (realistic), Relevant (aligned with corporate strategy), and Time-bound (realistic deadline).

Chapter 2 describes the initial team meeting as the moment to "set expectations and ensure that everyone understands the goals, deliverables, and schedule." Critically, the book notes that in multicultural virtual teams, "the rules are generally implicit" within each culture, but what is implicitly understood in one culture may differ sharply in another. Therefore, managers must "be explicit with rules and expectations" and "make these expectations explicit in the beginning to alleviate potential conflicts."

Chapter 5 on project planning reinforces that expectations must be "clear and explicit (and preferably documented on the project's wiki or intranet so everyone has access to them)." The book also recommends managers provide "a centralized repository for project information" where "project-related information on an intranet site (also called a 'team room') where everyone can access it 24/7."

Why It Matters

This concept identifies a structural asymmetry: virtual teams lose the ambient information gathering of shared physical space but gain the ability to create permanent, searchable, reference-able documentation. The trade-off works only if teams actively populate that documentation. By treating the explicit statement of goals, scope, and authority as a design requirement rather than an optional nicety, teams prevent the confusion and rework that arises when members discover their understanding of "done" or "in scope" differs from their teammates'.