Patterns Virtual Projects

PEVP_interior_012506.
qxp 1/25/06 1:16 PM Page i
chapter head here i

PEVP_interior_012506.qxp 1/25/06 1:16 PM Page ii
Contents
Preface v
Executive Overview vii

1. Introduction 1
2. Key Dimensions of a Virtual Project Typology 3
2.1. Virtuality 3
2.1.1. Views of virtuality 3
2.1.2. Integrated definition of virtuality 5
2.2. Technology 5
2.2.1. Views of technology 5
2.2.2. Integrated definition of technology 6
2.3. Project Characteristics 8
2.3.1. Views of projects 8
2.3.2. Integrated characterization of projects 10
2.4. Patterns and Pattern Theory 12
3. Key Factors for Managing Virtual Projects 15
3.1. Communication 15
3.1.1. Culture 16
3.1.2. Trust 17
3.1.3. Norms and expectations 17
3.1.4. Common ground 17
3.1.5. Leadership 18
3.1.6. Integrated definition of communication 19
3.2. Coordination 19
3.2.1. Views of coordination 20
3.2.2. Integrated definition of coordination 23
3.3. Control 23
PEVP_interior_012506.qxp 1/25/06 1:16 PM Page iii
3.3.1. Control – cybernetic view 24

3.3.2. Control – portfolio of modes 24
3.3.3. Integrated definition of control 25
4. Proposed Typology 27
4.1. Lean Projects 27
4.2. Hybrid Projects 28
4.3. Extreme Projects 29
4.4. Expected Effects 29
5. Methodology for Data Collection 33
5.1. Overview of Method 33
5.2. Participants 34
5.3. Brainstorming Tool and Agenda 35
5.4. Measures and Coding Scheme 37
6. Analysis and Results 41
6.1. Use of Technology 41
6.2. Project Types 43
6.3. Patterns for Effective Management of Virtual Projects 47
6.3.1. Patterns for lean projects 48
6.3.2. Patterns for hybrid projects 54
6.3.3. Patterns for extreme projects 60
7. Implications and Conclusions 67
8. References 69
Appendices:
Appendix A: Selected Tools for Virtual Collaboration
and Project Management 75
Appendix B: Introductory E-mail to Focus Group
Participants 85
Appendix C: Cover Letter Approved by Institutional
Review Board 87
Appendix D: Questionnaires for Focus Groups 89
PEVP_interior_012506.qxp 1/25/06 1:16 PM Page iv
PEVP_interior_012506.qxp 1/25/06 1:16 PM Page v
Preface
ur research would not have been possible without the financial sup-
O port of The Project Management Institute’s Research Foundation
and the University of Nebraska at Omaha. We very much appreciate the
Project Management Institute’s encouragement and enthusiastic support
of research to continue to bring new ideas into the practice of project
management.
The authors express sincere thanks to the organizations and employ-
ees who participated in the virtual focus groups for the study.
We also thank our graduate students who were involved in various
parts of the data collection and analysis: Azamatbek Mametjanov, Patricia
Morris, and Kavan Ravi.
V
PEVP_interior_012506.qxp 1/25/06 1:16 PM Page vi
PEVP_interior_012506.qxp 1/25/06 1:16 PM Page vii
Executive Overview
he management of virtual projects is fundamentally different from

T that of traditional projects. Furthermore, the research in this area
comes from different reference disciplines and perspectives, and a unified
view of theory of best practices does not yet exist. Being able to combine
perspectives in a seamless way with skills and technology could provide
integrative blueprints for best practices in virtual projects. The goal of
this research was to provide such a set of blueprints.
We conducted a literature review on best practices and theory in the
management of virtual projects and virtual teams. We used the theoreti-
cal frame of patterns to propose an integrative way of looking at recom-
mendations for best practices. Guided by the major concepts from our
literature review and the overall concept of patterns, we conducted a
series of electronic focus groups. Five companies participated in the focus
groups, with individuals from all over the world who had experience with
virtual projects. The brainstorming ideas from the focus groups were
used to develop a set of patterns for each type of project identified in our
typology.
This monograph includes the following: a comprehensive literature
review of the key concepts in the study; a proposed typology of projects
derived from the literature review; details on the method for conducting
the focus groups and coding the data; analysis and results of focus group
data; presentation of patterns and implications for project managers; and
conclusions. Several appendices provide supporting documentation for
the project.
VII
PEVP_interior_012506.qxp 1/25/06 1:16 PM Page viii
PEVP_interior_012506.qxp 1/25/06 1:16 PM Page 1
Introduction
he management of virtual projects is fundamentally different

T from that of traditional projects. Project managers, however, are
naturally inclined to carry their assumptions about, and skills in, tradi-
tional project management into a virtual environment. Three things
often keep project managers from rapidly adapting and being effective in
this new environment – their existing mindset, skill set, and tool set. The
rare manager who can combine all three things is someone who can man-
age through technology, rather than simply with technology. Being able to
combine perspectives in a seamless way with skills and technology is
something that could be taught if we had the blueprint. The research
described in this monograph addresses this issue and makes both theo-
retical and practical strides toward understanding and specifying such
blueprints.
We use the theoretical frame of patterns to propose an entirely new
concept. Our underlying hypothesis is that patterns of virtual projects can
be identified. We further propose that we can differentiate between effec-
tive and ineffective patterns. We focus on three concepts as the underly-
ing theoretical elements for identifying patterns: (1) coordination, (2)
communication, and (3) control. We believe that these elements are
uniquely different in virtual projects because of the reliance on commu-
nication technology, which defines the environment through which coor-
dination, communication, and control take place. The technology both
constrains and enables the way each element is handled, as well as the bal-
ance or pattern among elements. It is the existence and implications of
such patterns that we have investigated.
1
2 Patterns of Effective Management of Virtual Projects
The sections that follow take the reader through the development of
each of the key concepts in the study. Each concept is defined based on
existing research and its relevance to the goals of this project. In Section
2, we develop the basic concepts of virtuality, technology, projects them-
selves, and the idea of patterns. Section 3 defines the three key factors for
managing virtual projects, namely communication, coordination, and
control. Section 4 discusses and defines generic project stages, then puts
all these things together in a typology of virtual projects. The typology
brings together all the conceptual pieces defined earlier.
From there, we go into the actual data that was collected for the proj-
ect. Section 5 describes the methodology for data collection, including
the surveys and coding tools that were developed specifically for this
research. Section 6 describes the analysis and results of the data collec-
tion. Section 7 provides specific recommendations for projects managers
based on the data analysis, and concludes the monograph with specula-
tions for future research.
Key Dimensions of a
Virtual Project Typology
2.1. Virtuality
2.1.1. Views of virtuality
The concept of virtuality has become so embedded in the popular con-

sciousness that it is easy to forget how diverse the meaning of the term
can be. We identified three major perspectives on the meaning of virtual-
ity: (1) dispersion, (2) process/goals, and (3) technology.
The most common view of what it means to be “virtual” is based on
the characteristics of the virtual entity, and those characteristics are typi-
cally defined in terms of dispersion. This view describes virtual entities as
being dispersed on a variety of dimensions, most often geographically
and in time, but also on such other dimensions as organizational affilia-
tion, culture, continuity of team membership, experience, availability, or
availability and variability in technology. The greater the dispersion, the
more virtual the entity is said to be (Watson-Manheim, Chudoba, &
Crowston, 2002; Katzy, Evaristo, & Zigurs, 2000; Zigurs, 2003). Many
authors subscribe to this view and the idea has intuitive appeal. A key
question, however, is whether any of the dimensions is a necessary condi-
tion for dispersion. It would seem that an entity has to be at least geo-
graphically dispersed for it to have any level of virtuality. Beyond that, the
other dimensions add to the level of virtuality, but none of them alone are
sufficient to call an entity virtual.
A second and different view of virtuality builds more directly on the
process and goals of virtual entities. In this second view, virtuality is
3
defined as a management approach that defines explicit functional

requirements and the means by which to realize them, then provides for
dynamic switching among requirements and services (Mowshowitz,
1997). The dynamism of the switching process and the ability to charac-
terize problems and resources in explicit and consistent terms is the
essence of this concept of virtuality. An interesting and related aspect of
this view is the idea that we can easily build and experiment with social
systems that are embedded within the technology that makes virtuality
possible (Turoff, 1997). This second view of virtuality is fundamentally
different from the first, in that the emphasis is not on the characteristics
of the entity, but rather on the process by which it functions. Rapid
response and marshalling of appropriate resources are important factors.
Of course, implied in this view is that resources are available anywhere
and anytime.
A third view of virtuality focuses on the technology itself, arguing
that it is the computer and communications technology that makes vir-
tuality possible at all. In this third view, virtuality is defined as the extent
to which the virtual entity relies on computer-mediated communication
(Dubé & Paré, 2004).
All three views of virtuality imply a seamless connectivity across
boundaries, in an “anywhere/anytime/any form” type of world. The dis-
persion view carries somewhat of a negative undertone because of the
negative connotations associated with the dispersion concept. The
dynamic switching view is more positive, with its assumption that the
right resources attach to problems when needed. The technology view is
neither positive nor negative, but instead emerges from design decisions
and user interpretations of the technology available for virtual interaction.
In addition to these different views of the nature of this concept, it is
also important to be clear on the level of virtuality being examined.
Virtuality may exist in entities internal to an organization—that is,
among individuals, teams, or departments within the organization—or
as embodied in the organization as a whole. It may also exist external to
the organization, in business-to-business relationships, business-to-cus-
tomer, or customer-to-customer associations (Qureshi & Zigurs, 2001).
Virtual communities can cross both organizational and social worlds
(Dubé & Paré, 2004).
Key Dimensions of a Virtual Project Typology 5
2.1.2. Integrated definition of virtuality
Building on these different views and for purposes of this monograph, we

define virtuality as the extent to which project members are dispersed on
geographical and other dimensions and rely on information and communi-
cation technologies for carrying out project goals. In our definition, disper-
sion requires, but is not limited to, geography. Reliance on technologies is
also recognized as a fundamental component of virtuality. This definition
is particularly relevant for project teams as the unit of analysis, because it
describes a minimum state of virtuality and allows for different degrees.
A “virtuality indicator” can be used to help a team assess its extent of vir-
tuality at the start of and during different project phases.
2.2. Technology
2.2.1. Views of technology
A common problem in the early days of research on computer-support-

ed groups was the tendency to view technology as a monolithic concept.
Different frameworks and typologies of technology were developed, but
their very differences raised the question of how findings could be inte-
grated across such disparate views. In addition, technology support for
project management was generally treated as an area separate from the
research on collaborative tools.
Technology might be characterized on a wide variety of dimensions,
including hardware or software infrastructure (Evaristo & Munkvold,
2002); level of support for information exchange (DeSanctis & Gallupe,
1987); types of support provided—for example, communication,
process, or task (McGrath & Hollingshead, 1994; Munkvold, 2003;
Nunamaker, Dennis, Valacich, Vogel, & George, 1991; Zigurs & Buckland,
1998); time-space configuration (Johansen; 1988); or on any number of
characteristics of the underlying media (Carlson & Zmud, 1999; Dubé &
Paré, 2004). (See Zigurs and Munkvold [in press] for a more detailed
review of the typologies.)
How we define the technology is important because it has direct
implications for the role we expect technology to play in virtual projects.
If we define a technology environment in terms of fixed characteristics, as
the concept of media richness does, then we would expect all project team
members to view and use the technology in the same way. There is ample
evidence that people interpret technologies differently and adapt them to
their own needs. For example, channel expansion theory (Carlson &
Zmud, 1999) shows how the same technology is used in different ways,
depending on such factors as team members’ knowledge of each other
and the task at hand. There is evidence that even so-called lean media can
be used successfully for group development and cohesion (Burke, Aytes,
& Chidambaram, 2001). Another example is the theory of adaptive struc-
turation (DeSanctis & Poole, 1994), which explains how the basic rules
and resources that are inherent in the design of a collaborative tool can be
adapted and changed as the team interacts over time. These perspectives
argue for a definition of technology that accommodates both fixed and
emergent characteristics.
2.2.2. Integrated definition of technology
In the context of virtual projects, we argue that there are three dimen-
sions of technology that are most relevant: (1) communication, (2)
process structure, and (3) task support. These dimensions, although they
go by different terms, are consistent themes in many existing classifica-
tion schemes for collaboration technology, and they also capture the
essential needs of project teams. Therefore, we define technology for virtual
projects as consisting of an integrated and flexible set of tools for commu-
nicating among project members, structuring process, and supporting task
analysis and performance.
Communication support would be provided by any tool that allows
project members to communicate with one another, ranging from one-
to-one to many-to-many, and including text, voice, and video communi-
cation. Process structure means the organization of the steps by which a
project will be carried out. Technology for structuring process might be
provided by tools for setting an agenda, enforcing an agenda, supporting
facilitation, providing written records, or reconfiguring steps and phases.
Task analysis and performance could be provided by tools for informa-
tion processing—for example, decision analysis, problem modeling,
brainstorming, idea evaluation, and so on. Each of these three parts of
collaboration technology provides for a different aspect of project needs.
Table 1 shows examples of elements that might support each of the
three dimensions of our definition. Clearly, the challenge in any definition
of technology is how well it stands up to new technical developments. We

believe that our three-dimensional definition captures the essence of
technology in a lasting way. How the dimensions are implemented will
vary over time; hence, the examples of elements in the table reflect gener-
ic, current tools, and we can expect new elements to be added as new
technologies are developed. Appendix A provides a more detailed analy-
sis of selected examples of current tools for virtual collaboration and
project management, with each tool rated on the three dimensions of our
definition.
Dimension Example Elements
Communication • Simultaneous input

• Anonymous input
• Input feedback
• Group display
• Physical configuration of communication
channels (e.g., synchronous or asynchronous,
proximate or dispersed)
Process Structure • Agenda setting

• Agenda enforcement
• Facilitation
• Complete record of group interaction
Task Analysis • Information gathering

and Performance • Information aggregation
• Information evaluation
• Information structuring (e.g., allocation,
stakeholder analysis, multi-attribute utility
analysis, cross-impact analysis)
• Project task analysis and tracking (e.g., Gantt
chart, PERT/CPM, Work Breakdown Structure,
resource assignment)
Table 1 Examples of Elements for Each Dimension of Technology

Our definition specified that the technology should consist of inte-

grated and flexible tools that support the three dimensions. Both integra-
tion and flexibility are major challenges, especially for project
management. The dimension of task analysis and performance is the one
dimension for which traditional project management tools provide effec-
tive support. Gantt charts, PERT and CPM, Work Breakdown
Structures—these are all part of typical project management software.
The other two dimensions of communication and process structure are
much more rarely addressed in PM tools.
There is a clear need for greater integration that is specific to project
management support. For example, Chen, Nunamker, Romano, and
Briggs, (2003) reviewed six existing project management tools and found
that most tools focus on project reporting rather than in-depth analysis
and real collaboration among project members. The authors proposed a
collaborative project management system that would provide different
levels of collaboration support throughout the entire cycle of a project, as
well as support for collaborative knowledge management. They call this
type of system a CPM—Collaborative Project Management system—
reinforcing the importance of what we have called the communication
and process structure dimensions.
2.3. Project Characteristics

2.3.1. Views of projects
Projects are used in a wide variety of situations, and they differ from each
other in many aspects, including size, time span, industry, customer, and
technology. This variety makes it difficult to create a single, comprehen-
sive project typology. Projects can be classified based on the domain of
the project—for example, software engineering, construction, product
development, and so on. We start with an overview of different classifica-
tion schemes for projects, and conclude with an integrated view that
forms the foundation for our own typology. Many of our examples are
taken from the domain of software engineering because virtual project
management is so prevalent in that domain. However, the basic ideas are
generalizable to other domains.
One perspective on project types is based on a study of cultural dif-
ferences among global software development teams (Carmel & Agarwal,
2001). Projects are classified by whether they are centers or foreign enti-
ties in an outsourcing partnership. A center is the initiator of a project
and it coordinates efforts of the foreign entity. The taxonomy results in
four project types: domestics, foreign, intra-firm, and external to firm.
The purpose of this taxonomy is to help identify the extent of complexi-
ty that arises from language and cultural differences. This taxonomy pro-
vides a relatively straightforward way of identifying projects, based on
domestic versus foreign differences. But, as global collaboration becomes
increasingly complex in transcending traditional cultural and organiza-
tional boundaries, the taxonomy becomes difficult to apply.
A second approach develops a typology based on two general project
dimensions: (1) technological uncertainty and (2) project scope
(Shenhar, 1998). Technological uncertainty is defined in terms of the
extent to which a final product technology is uncertain at the outset of a
project. System scope is defined in terms of the nature of the final prod-
uct in the hierarchical relationship of components, modules, assemblies
of modules, systems, and arrays of systems. Technological uncertainty
reflects the risk of a project. System scope reflects the complexity of a
project. Both risk and complexity are important themes in project man-
agement (Project Management Institute [PMI], 2004), and this typology
is a useful step in incorporating these important concepts, but additional
concepts may be needed.
The third approach reviewed here comes directly from the research
on virtual teams, and can be termed a characteristics type of taxonomy
(Powell, Piccoli, & Ives, 2004). Project characteristics are defined in sever-
al categories. Characteristics related to individuals include team gender
composition, team member personal characteristics, and the number of
people involved in the project. Characteristics related to the project con-
text include project innovation, project scope, degree of resource
bundling, and project knowledge base mode. Project innovation can be
incremental or radical. Project scope varies from autonomous and local-
ized projects to systemic projects. The degree of resource bundling
reflects whether resources are redundant or complementary at each site
of the project. Project knowledge base mode reflects whether domain
knowledge possessed by experts is explicit or tacit, which also affects proj-
ect complexity (Powell et al., 2004).
Our brief review of project categorization is by no means exhaustive,
but we chose the examples because they reflect some consistent themes
and show key differences in how we might approach a typology of proj-

ects. Characterizing projects in terms of domestic versus foreign is prob-
lematic because of the breakdown of these categories in actual practice.
What is needed is a characterization that takes into account a managea-
bly small number of fundamental themes that provide an organizing
umbrella for the long list of characteristics that real projects have. The
fundamental themes should also allow for theorizing, rather than just a
checklist approach.
2.3.2. Integrated characterization of projects
We present three fundamental dimensions of project characteristics as

the organizing themes for understanding projects and the starting point
for a typology: (1) complexity, (2) scope, and (3) risk. All three dimen-
sions are reflected in some form in the typologies and taxonomies dis-
cussed earlier. As illustrated in Table 2, complexity reflects various issues
that have to be managed for successful completion of a project. Thus,
project complexity is defined in terms of the attributes of team size, cul-
ture, language, gender composition, personal characteristics, resources,
and knowledge. Scope identifies the boundaries of a project (Table 3).
According to PMI’s (2004) definition of project scope, it includes all of
the work required, and only the work required, to complete the project
successfully. Project duration, innovation, final product scope, and proj-
ect multiplicity are all attributes of the more general notion of project
scope. The risk dimension encompasses various unanticipated threats
or opportunities that may adversely or positively affect successful com-
pletion of a project. These risks can be programmatic, technical and
engineering, quality, logistical, and deployment-related (Christensen &
Thayer, 2001; IEEE, 2004). For each of the factors defining a project, we
recommend potential anchors that can serve to define a range of proj-
ect types.
Factor Potential Anchors
Team size Small vs. medium vs. large
Culture Homogeneous vs. hybrid vs. heterogeneous

(Royce, 1998)
Language Homogeneous vs. hybrid vs. heterogeneous
Gender Female-dominated vs. male-dominated vs.

composition mixed (Powell et al., 2004)
Personal Introvert-sensing vs. introvert-intuiting vs.

characteristics extravert-sensing vs. extravert-intuiting
(Powell et al., 2004)
Resources Redundant vs. complementary at each site

(Gassmann & Von Zedtwitz, 2003)
Knowledge Explicit vs. tacit (Gassmann & Von Zedtwitz,

2003; Grant, 1996)
Table 2 Factors Affecting Project Complexity
Factor Potential Anchors
Duration Short-term vs. medium-term vs. long-term
Innovation Incremental vs. radical (Gassmann & Von

Zedtwitz, 2003)
Scope Systemic vs. autonomous (Gassmann & Von

Zedtwitz, 2003)
Multiplicity Single vs. multiple (Evaristo & Munkvold,

2002)
Table 3 Factors Affecting Project Scope

Factor1 Potential Anchors
Programmatic Certain vs. uncertain

(Schedule, Cost, Political)
Technical and engineering Unambiguous vs. ambiguous

(Requirements, Security, Adequate vs. inadequate
Performance, Safety) Complete vs. incomplete
Quality (Implementation, Satisfactory vs. unsatisfactory

Maintenance)
Logistical (Reliability) Reliable vs. unreliable
Deployment Direct vs. cutover vs. phased

(Training, Integration) vs. pilot vs. parallel
Table 4 Factors Affecting Project Risk
2.4. Patterns and Pattern Theory

Using patterns as a way of understanding and dealing with complex-
ity is a well-established aspect of both human and machine behavior. The
general concept of a pattern is an intuitively appealing way of under-
standing the world around us. We find analogies to patterns in such ideas
as genre taxonomies (Yoshioka, Herman, Yates, & Orlikowski, 2001),
recurring themes, familiar processes, rules of thumb, or standard proce-
dures. However, there is a more structured theory of patterns that comes
from architecture and has established itself in software design. It is this
specific concept of patterns that we will use in this study.
Originally proposed in a classic book on architecture by Alexander,
and follow-up work with colleagues, the concept of design patterns is now
being applied in software engineering (Alexander, 1965; Alexander,
Ishikawa, Silverstein, Jacobson, Fiksdahl-King, & Angel, 1977; Gamma,
Helm, Johnson, & Vlissides, 1994). Alexander defines a pattern as a three-
part rule that expresses a relationship among a specific context, a problem,
1 The risk factors listed in this column are from IEEE (2004).
and a solution. The problem is a set of forces that occurs repeatedly in that
context. The solution is a certain “spatial configuration” that allows the
forces to resolve themselves. The pattern itself describes how the solution
can be used whenever the problem occurs in that particular context. A
collection of patterns represents a pattern language, defined as a system
of patterns that combines to produce a variety of important outcomes
(Alexander et al., 1977).
The basic concept of patterns and pattern theory has spread into a
variety of domains. For example, many Web sites are devoted to shar-
ing patterns for software development. A well-known site is the
Portland Pattern Repository, which provides software design patterns
(http://en.wikipedia.org/wiki/Portland_Pattern_Repository).
Patterns have also been applied in the domain of management, as
described in a case study by Austin and Westerman (2002). These authors
studied the evolution of a company that adopted patterns for structuring
the activity of the company itself. The company developed an elaborate
repository of patterns for management, and made them available to all
employees. The “swarm” pattern described in the case study provides an
interesting example of this application. The problem to which the pattern
applies is that a serious crisis emerges in a project. The solution is to
develop a “war room” mentality by swarming the problem with experts,
communicating frequently, and executing a carefully thought-out plan.
The pattern is accompanied by a more detailed discussion of its applica-
tion, but this brief summary captures the essential elements.
There has also been some research on patterns that relate specifically
to the area of computer-supported work. Schuemmer (2003) proposes a
sample structure for socio-technical patterns that can be used to support
participation in collaborative systems. Fernandez, Holmer, Rubart, &
Schuemmer (2002) focus on the design of groupware systems and pro-
pose specific patterns for designing groupware tools that help to establish
a common vocabulary. Homsky (2003) focuses on group interaction and
proposes patterns of group leadership to help influence the disposition of
a group. Examples of his patterns are “keep an ear to the ground,” “scape-
goat,” and “grand finale.”
Finally, Völter (2002) presents a set of patterns directly relevant to
project management. His paper uses the pattern format for describing
frustrations with project management and the things that go wrong, so
the patterns are really “anti-patterns” because they document all the
wrong responses to project management problems.

We have presented only a few examples of the many applications of
pattern theory. The examples suggest how patterns might be applied to
virtual project management. What is needed next is a discussion of the
key factors that we expect to be part of those patterns.
Key Factors for Managing

Virtual Projects
p to this point, we have defined the key concepts of virtuality and

U technology, presented a characterization of projects, and introduced
the idea of patterns as an organizing theory for our research. In this sec-
tion, we present the three major themes that we argue should be part of a
pattern theory for virtual project management. The three themes are
communication, coordination, and control. We discuss each theme in
turn, presenting what is known from the current research as it relates to
virtual project management.
3.1. Communication
Communication is fundamental to teamwork and has been a topic of
study for well over fifty years. A large body of knowledge has accumulat-
ed on traditional groups and prescriptions for effective communication
(e.g., McGrath, 1984; Shaw, 1981). A similar body of research is well
under way to examine whether and in what way those traditional pre-
scriptions and theories translate to a virtual environment.
The research in virtual teams has documented a variety of communi-
cation-related issues—for example, the difficulty of dealing with different
interaction styles and preferences (Sarker & Sahay, 2002), rapid and neg-
ative attributions based on infrequent communication and perceived lack
of responsiveness (Cramton, 2001), and the need for periodic face-to-face
communication to help build confidence and trust in working remotely
(Maznevski & Chudoba, 2000). Many of these issues are of particular
concern for group communication in virtual projects, including team
15
expectations, consensus, trust, norms, culture, leadership, and communi-

cation styles (Chinowsky & Rojas, 2003; Dubé & Paré, 2001; Dubé & Paré,
2004; Powell et al., 2004). The rest of this section focuses on the most crit-
ical issues that are particularly relevant to communication in virtual proj-
ect management.
3.1.1. Culture
Cultural differences in project teams have the potential to be extremely

beneficial, because diverse people can bring in new and different ideas
and perspectives. But benefits can only be realized if the risks from cul-
tural differences can be overcome. There is ample evidence that culture
has an impact on many different aspects of communication. Massey,
Hung, Montoya-Weiss, & Ramesh (2001) found cultural differences in
virtual team members in their preference for interaction and debate.
Asian and European participants preferred to use asynchronous commu-
nication tools so that they could be precise in the ideas they conveyed,
while U.S. participants preferred direct oral interaction. Rutkowski,
Vogel, Bemelmans, & Van Genuchten, (2002) examined teams of students
from China and the Netherlands over time, and found that interdepend-
ence was critical to success. They recommended that a collectivistic ori-
entation would be better than an individualistic one in virtual teams, and
that expectations of cross-cultural compatibility would have to be
addressed and carefully managed. Another study of global student
teams—this time from Belgium and the US—reinforces the importance
of a structured approach to helping team members understand cultural
differences (Van Ryssen & Godar, 2000).
Most of the studies related to culture interpret national culture in
terms of Hofstede’s dimensions—namely, individualism (individualism
vs. collectivism), power distance (equal vs. unequal power), uncertainty
avoidance (low tolerance vs. high tolerance), and masculinity (masculin-
ity vs. femininity) (Hofstede, 2001). A fifth dimension relating to long-
term orientation (long-term vs. short-term thinking) was added from a
later study that supplemented the original research with IBM. Hofstede’s
work is widely known and accepted in the research on virtual teams, so it
has the potential to be a useful starting point for both diagnosis and man-
agement of cultural issues.
Key Factors for Managing Virtual Projects 17
3.1.2. Trust
One of the most essential and challenging aspects of virtual teams is to

build trust. Since members may not know one another well and may be
communicating strictly over distance, the usual trust-building cues and
practices are difficult to maintain. The concept of “swift trust” has been
explored in virtual teams. Swift trust is a form of trust that develops quick-
ly, but has been found to be very fragile and difficult to sustain (Jarvenpaa
& Leidner, 1999). Trust is typically built on shared norms, ongoing inter-
action, and shared experiences. Since global virtual teams often form and
re-form quickly, the development of trust is especially challenging.
Two different situations may affect whether needed trust can devel-
op. First, there may be turnover among team members of virtual projects,
as expertise is added to the mix on an as-needed basis. New members
coming into the project have to be assimilated quickly. If trust is not cre-
ated almost immediately, it may not form at all (Jarvenpaa & Leidner,
1999). Furthermore, other members of the team are quick to make nega-
tive attributions in cases where trust has not developed (Cramton, 2001).
Second, even where turnover is fairly low, the nature of virtual interaction
may hinder trust development.
3.1.3. Norms and expectations
The development of a shared consensus on norms and expectations for

a virtual team is another essential component of effectiveness.
Communication is required to set and reinforce norms. Virtual team
members often report difficulties with getting appropriate attention and
commitment from team members (Cramton, 2001; Watson-Manheim &
Belanger; 2002).
3.1.4. Common ground
The concept of common ground appears in the literature on computer-

supported collaborative work. In that literature, common ground is
defined as the mutual understanding that team members develop during
the ongoing process of communication (Stahl, 2005).
Several studies reinforce the importance of this concept, even though
people use different terms for it. Suchan and Hayzak (2001) conducted an
in-depth analysis of virtual teams in a large consulting firm. The teams

developed knowledge repositories as a way to deal with the need for
information sharing. The development of a common language for the
repositories was a challenging database problem; but, via the process of
resolving those issues, the teams ended up with a shared communication
language. Their repositories became a common ground—a shared under-
standing of their domain.
Research on quick-response teams also shows some interesting
results for this concept. McKinney, Barker, Smith, and Davis (2004) stud-
ied flight teams as an example of swift-starting action teams. Although
team members were not geographically dispersed, these teams are a good
example of the way that members who do not know one another can get
up to speed very quickly—a phenomenon that is common in virtual proj-
ects. Explicit sharing of communication values was the key factor in the
success of these teams. The study reinforces the idea that values have to
be communicated and shared in order to build the common ground
required for effective teams.
3.1.5. Leadership
The final factor related to communication is leadership. Leadership is a

very interesting phenomenon for virtual environments, given that most
of what we believe about the way that leadership works is related to face-
to-face influence. Leadership for virtual teams requires special effort,
including taking advantage of face-to-face meetings if at all possible, pro-
viding for facilitation, encouraging frequent communication, and ensur-
ing increased awareness and visibility of the presence and activities of
team members (Avolio, Kahai, & Dodge, 2001; Maznevski & Chudoba,
2000; Zigurs, 2003).
A virtual project team will have assigned project leaders, but leader-
ship roles can be expressed by anyone within the team (and, in fact, may
need to be) to carry the team forward. Leadership roles might include
motivation, information or opinion seeking, mediation, and sometimes
gatekeeping—all aspects of important relational development within
groups (Zigurs & Kozar, 1994).
3.1.6. Integrated definition of communication
Based on the broad set of issues discussed previously in this chapter and
our specific focus on virtual project management, we define communica-
tion as the process by which people convey meaning to one another via some
medium through which they exchange messages and information in order to
carry out project activities. It is important to note that activities in both of
the other dimensions—coordination and control—are carried out via the
process of communication. But we identify communication as a separate
dimension in order to focus especially on the shared development of
meaning, as reflected in our definition of the term.
3.2. Coordination
Coordination is broadly described as “the harmonious functioning of
parts for effective results” (Encyclopædia Britannica Online, 2004). This
general definition sums up the essence of coordination as an activity that
brings diverse elements together to produce successful performance in
any group endeavor. In his seminal book on the structure of organiza-
tions, Henry Mintzberg (1979, p. 2-3) observes that in any organized
human activity there are two “fundamental and opposing requirements:
the division of labor into various tasks and the coordination of these tasks
to accomplish the activity.” Obviously, these concepts, particularly the
idea of coordination, are as important for simple day-to-day activities as
they are for project management. Minztberg further elaborates that there
are five principal means or coordinating mechanisms that explain the ways
in which organizations coordinate work: mutual adjustment, direct
supervision, standardization of work processes, standardization of work
outputs, and standardization of worker skills. These notions of coordina-
tion form an important underpinning for understanding the patterns rel-
evant to the management of virtual projects. Furthermore, the notion of
coordination in virtual projects, as in other aspects of life, is very closely
associated with control and communication.
Malone and Crowston (1994) extend Mintzberg’s notion by arguing
that the study of coordination is clearly interdisciplinary, and that
research in this area needs to draw from many disciplines, including com-
puter science, organization theory, operations research, linguistics, and
psychology. They broadly define coordination as a process of managing

dependencies among activities. They further maintain that coordination
problems are common across disciplines and that some coordination
mechanisms are common as well. The authors assert that the application
of coordination models to various kinds of systems results in different
mechanisms. They classify those mechanisms in terms of three elemen-
tary dependencies: flow, fit, and sharing. A flow dependency arises when-
ever an activity produces a resource or resources that are used by another
activity; a fit dependency occurs whenever multiple activities collectively
produce the same resource;, and a sharing dependency occurs whenever
the same resources are used by multiple activities.
Zalesny, Salas, and Prince (1995) culled definitions of coordination
from scientific investigations in a variety of fields, such as physical biolo-
gy, organization theory, organization behavior, music, physiology, and
computer science. From their analysis of these definitions, they identify
two key features: the notion of interdependence and an emphasis on the
temporal sequencing of activities. Based on the work of Malone and
Crowston (1994) and Turvey (1990), Zalesny et al. (1995) then provide a
broad characterization of coordination in terms of four key components:
identifying goals (i.e., what are the objectives of joint activities); mapping
goals to activities (i.e., what specific activities are needed); mapping activ-
ities to actors (i.e., who does what); and managing interdependencies
(i.e., sequencing and synchronizing activities).
3.2.1. Views of coordination
Past research on coordination in virtual projects has utilized several dif-

ferent approaches that draw on the fundamental ideas of coordination
described by Mintzberg and others. For example, in a review of research
on virtual teams, Powell et al. (2004) describe coordination in virtual
teams as a task-related process and they define coordination as the
“degree of functional articulation and unity of effort between different
organizational parts and the extent to which the work activities of team
members are logically consistent and coherent” (p. 12). On the other hand,
Gassmann and von Zedtwitz (2003) studied how coordination practices
varied in virtual projects with respect to the amount of centralization
used. In that study, the authors view coordination as a structural element
of project management. An alternate view of coordination considers it as
the sequence and types of activities in which teams engage during ongo-
ing team processes (Massey, Montoya-Weiss, & Hung, 2003). That
research emphasizes temporal rather than functional aspects of coordina-
tion. Massey et al. found that the successful enactment of temporal coor-
dination mechanisms produced distinct patterns of interactions in global
virtual teams, which led to different higher performance. Similarly, in a
study on the impact of temporal distance on communication, control and
coordination, Carmel and Agarwal (2001) found that temporal distance
exacerbates coordination and control problems directly or indirectly
through its negative effects on communication.
In another stream of work in the area of coordination in biological
systems, Turvey (1990) built on the work of Bernstein (1967) and devel-
oped a set of principles underlying coordination of movement in biolog-
ical systems. These principles emphasize the conceptualization that
coordination is more about “fitting things together… as units in coordi-
nation rather than as “units of coordination” (Zalesny et al., 1995).
Turvey’s principles form a useful basis for identifying patterns of coordi-
nation in virtual projects. In the specific context of coordination research
in civil engineering, Godart et al. (2001) explore two approaches to coor-
dination in virtual projects: explicit coordination based on explicit
process modeling, and implicit coordination based on group awareness.
Clearly, coordination appears to be an evolutionary and multidimension-
al construct. In this vein, Zigurs, Evaristo, and Katzy (2001) propose mul-
tiple dimensions to characterize coordination—namely, task, relational,
structural, temporal, role, values and norms, language and culture, and
media coordination.
Our focus of interest in virtual project management is both from the
perspective of a participant coordinating activities among individuals
and that of a manager or supervisor coordinating the work of others.
Therefore, in the table below, Zalesny et al.’s framework of coordination
components and processes is combined with Zigurs et al.’s dimensions to
develop a detailed characterization of coordination in the virtual project
context.
Components Associated Processes Applicable Dimensions
Goals Identifying goals Task coordination

• Decision-making Role coordination
• Communication Media coordination
• Conflict and resolution
• Organizational analysis
Activities/Tasks Mapping goals Task coordination

to activities Structural coordination
• Task analysis
• Task strategy
development
• Leadership
Actors/Team Mapping activities to Role coordination

Members actors/team members Task coordination
• Negotiations Relational coordination
• Leadership
• Person analysis
Interdepen- Managing Temporal coordination

dencies interdependencies Relational coordination
• Leadership Norms/Values
• Communication Coordination
• Problem solving Language/Culture
• Socialization of new coordination
members Media coordination
• Ongoing evaluation
and adjustments
• Training
• Policy development
(institutionalization)
Table 5 Coordination: Components, Processes and Dimensions

3.2.2. Integrated definition of coordination
Based on the preceding discussion and our particular interest in virtual

project management, we define coordination as the mechanisms through
which people and technological resources are combined to carry out specified
activities in order to accomplish stated goals (Crowston, 1991; Grant,
1996). In this context, collaborative technologies and human expertise are
critical resources necessary to accomplish project goals. The degree of
coordination necessary and the coordinating mechanisms utilized will
clearly depend upon many factors, including the nature of the project and
the extent of virtuality across its many dimensions. Furthermore, various
research studies in the area of virtual collaboration have identified other
contextual and organizational factors that may impede effective coordi-
nation—for example, proper team training, team trust, team cohesion
(Chinowsky & Rojas, 2003), dependency management (Malone &
Crowston, 1994), team and project structure (Gassman & Von Zedtwitz,
2003), temporal distance (Carmel & Agarwal, 2001), and reward systems
(Burke et al., 2001).
Given the many challenges to effective coordination in a virtual setting,
Turvey (1990) correctly asserts that coordination is achieved over time and
with practice, and does not necessarily happen the first time a group gets
together. Finally, we agree with the proposition that effective coordination
is probably not achieved by the efforts of individual members of a team, but
rather by the sum total of the members’ expertise and experiences with
similar tasks and their ability to socialize (Zalesny et al., 1995).
3.3. Control
Broadly speaking, control is a way of having power over our environ-
ment—through regulative action and/or via authority or power. The abil-
ity to control complex systems and other human endeavors involving the
management of people and resources in complex undertakings has
required formalization of mechanisms to monitor and assess perform-
ance. Because of this need to effectively manage the resources in projects,
the notion of control is treated very thoroughly in the existing project
management body of knowledge. The importance of control is exempli-
fied by the apparent emphasis in the PMI standards on control as a critical
element for effective project management (Project Management Institute,

2004; Kirsch, 1996).
The rest of this section focuses on current views of control with par-
ticular relevance to project management, and culminates in a definition
of control for our research study.
3.3.1. Control—cybernetic view
The dominant view of control in the practitioner project management

literature follows the historical cybernetic view of control, in which out-
puts are compared with standards or benchmarks, and corrective actions
are taken to correct variances (Henderson & Lee, 1992). This view can be
traced to Max Weber (1947), who defined control as a process of creating
and monitoring rules through hierarchical authority (Hendersen & Lee,
1992). This view has since been extended to include the notion that both
behaviors and outcomes can be potentially monitored and evaluated,
hence controlled through variance analysis. Managerial outcome control
in this perspective is the “extent to which the manager monitors and eval-
uates only the outcome produced by team members,” whereas manageri-
al behavioral control focuses on the “monitoring and evaluation of team
members’ behavior in order to assist them” (p. 759). This view is clearly
important in virtual project management; however, the inherent chal-
lenge of virtuality makes its difficult to sustain a hierarchical authority
structure. In fact, virtual projects have a dispersed and fluid team struc-
ture that would require a combination of decentralized and centralized
control mechanisms.
3.3.2. Control—portfolio of modes
In this relatively new multi-mode approach to control, Kirsch (1996;

1997) takes a broader view of control that encompasses all efforts by indi-
viduals in organizations to act in a manner “consistent with meeting
organizational goals and objectives” (Kirsch, 1997, p. 215). Kirsch (1997)
categorizes control into formal modes (behavior and outcome control)
and informal modes (clan or group level and self or individual level of
control) and asserts that these are implemented via a “variety of mecha-
nisms, such as linking pay with performance, socialization, and team-
building” that result in the regulation of behavior. (p. 215). Kirsch’s
research suggests that project teams implement a portfolio of control

modes that typically includes both formal and informal control modes
with redundant mechanisms used to exercise these modes of control. This
research has a close link to coordination in virtual projects, in that formal
mechanisms of control facilitate task management, whereas informal
mechanisms are necessary for relationship management and socialization
(Kirsch, Sambamurthy, Ko, & Purvis, 2002).
3.3.3 Integrated definition of control
Since virtual project management also involves managing both behaviors

and outcomes, we also take an inclusive view of control in this research
while sustaining the variance-based approach. Specifically, we define con-
trol as the process of monitoring and measuring project activities so as to
anticipate and manage variances from project plans and organizational
goals (Project Management Institute, 2004; Kirsch, 1996; Hendersen &
Lee, 1992). In this definition, monitoring may require the development of
a variety of mechanisms for assessing behavioral actions and project out-
comes, in order to take corrective actions as needed. For example, in the
virtual project context, the challenge of control could relate to establish-
ing standards for assessing team member performance, communication
of progress, establishment of norms for team member interaction, struc-
turing of teams, use of collaborative technology, or team performance. It
should also be noted that our definition of control does not preclude the
use of a portfolio of control modes as suggested by Kirsch (1996). Finally,
the challenges associated with controlling projects are closely tied with
coordination and communication issues. For example, temporal distance
exacerbates coordination and control problems directly or indirectly
through its negative effects on communication (Carmel & Agarwal,
2001). Thus, some organizations move towards reducing collaboration
complexity by giving up control and transferring ownership to foreign
entities, or by taking the full project ownership to the domestic entity.
Other challenges that impact control in virtual projects include reinforc-
ing project objectives (Chinowsky & Rojas, 2003), monitoring and meas-
uring issues, collaborative infrastructure (Evaristo & Munkvold, 2002),
knowledge of the systems development process by client (Kirsch et al.,
2002), and group leadership (Homsky, 2003).
Proposed Typology
learly, it would be impossible—and probably unhelpful—to develop

C a typology that accounted for every variation in projects based on
the characteristics that were developed previously. A typology is a theory-
building exercise (Doty & Glick, 1994) and should focus on the essential
characteristics of a phenomenon that make a difference. We use each of
the three dimensions of communication, coordination, and control, plus
the virtuality dimension, in order to develop a parsimonious typology of
virtual projects. The typology is a starting point that focuses on major
pressure points. Three projects types are defined: lean, hybrid, and
extreme. Each type is described in the following sections.
4.1. Lean Projects

Lean projects are defined as having low complexity, narrow scope, and
relatively low risk. Such projects tend to be easily subdivided into man-
ageable parts due to relatively clear and tangible requirements or out-
comes. Each part of a lean project will have unambiguous goals and
outcomes that can be achieved in a relatively short time using stable
methodologies. An example of a lean project is an in-house software
development project with multiple segments, within one organization
(though across multiple locations), with clarity of goals and resource
allocation, and with relatively established teams. Such a project is typical-
ly associated with experienced and relatively small teams, with an estab-
lished rapport among team members; structured problems; and, overall,
relatively homogeneous team and organizational characteristics.
27
Lean projects are initiated using well-established processes and

repeatable practices. A lean project, therefore, requires a management
approach that emphasizes control at all stages. Since the problem is rela-
tively structured and resources are well defined and available, the empha-
sis is on allocation of resources, project tracking, and task performance.
The technology for lean projects should focus on supporting task
performance and support. Examples of tools that are important for lean
projects include workflow, project management, CASE tools, change
management, and project repositories.
4.2. Hybrid Projects

Hybrid projects are defined as having varying levels of complexity, scope,
and risk. An example of a hybrid project is a project that uses a mix of in-
house and outsourced development—for example, a significant enhance-
ment of a customer relationship management application that will be
used by internal employees and call center partners. The project would be
characterized by a systematic approach to development, side-by-side with
the global heterogeneity of outside partnerships. There may be partners
who speak the same language and have the necessary expertise to build
such applications. They will have previously worked with the company
and, thus, have some shared culture and working practices. Only some of
the project team members might not have worked with each other previ-
ously and, therefore, need to establish rapport with their colleagues.
Another example of a hybrid project is the Y2K problem that many com-
panies faced. This problem required a high degree of coordination across
all segments of the organization and with outsourcing agencies at the
same time that the problem itself was relatively structured.
Given the mixed nature of their characteristics, hybrid projects
require a management approach that emphasizes coordination.
Coordination is of the essence because it focuses on combining people
and activities in an environment that mixes the known with the relative-
ly unknown.
The technology for hybrid projects must focus on supporting coordi-
nation. Virtual collaboration and knowledge management tools are
examples of tools that emphasize coordination.
Proposed Typology 29
4.3. Extreme Projects

Extreme projects are defined as having high complexity, broad scope, and
high risk. Such projects are generally mission-critical and highly visible.
Success factors for extreme projects are not apparent at the outset and
take a long time to complete. Consequently, extreme projects require
intense activity and participation by a number of teams and stakeholders.
A large number of team members in such projects will not have previously
worked with each other and, therefore, will not have an established rapport.
An example of an extreme project would be a multinational company
implementing a global supply chain application. Such a project is typically
associated with multiple units, both internal and external; varied cultur-
al orientations; conflicting goals; hidden agendas; different personalities;
potential variations in resource infrastructures; variations in legal and
quality standards; and, overall, a high degree of heterogeneity and disper-
sion in all aspects of the project.
An extreme project, therefore, requires a management approach that
places the greatest emphasis on communication. Communication is
required not only to develop a shared understanding of the problems
before any work can begin, but also at all stages of the project.
In terms of technology, support is required for sharing context, devel-
oping understanding, and maintaining high communication among
stakeholders. Project participants must share their differing contexts with
each other in order to achieve that understanding. Tools that support
high-bandwidth contextual information such as video conferencing are
conducive to developing a shared understanding.
4.4. Expected Effects

Based on the previous discussion, Table 6 shows the implications for the
typology on the management practices of coordination, communication,
and control, as well as suggested technology needs for each type of proj-
ect. The technology needs are a direct result of the dominant managerial
concern for each type of project. For lean projects, in which control is
prominent, technologies that provide information processing are recom-
mended. In hybrid projects, in which coordination is the key concern, the
technology must provide high process structure, so that project members
Dominant
Virtuality Technology
Project Type Managerial
Effects Needs
Concern
Lean Control Virtual project team already High information

(Low complexity, has an established shared processing:
narrow scope, context. However, absence PM/Workflow tools,
low risk—e.g., of physical interactions CASE tools, Software
maintenance might hinder successful configuration
virtual project) project completion management
Heterogeneity on various tools, vertical
dimensions (culture, team communication
experience, language, channels
gender, personalities,
resources and infrastructure,
knowledge management) is
not a critical factor because
it is managed by prior
experience within and
across team members and
through sharing of historical
repository of project
experiences
Hybrid Coordination Units/partners that High process

(Varying levels of do not share mutual structure:
complexity, scope project knowledge might Virtual collaboration
and risk—e.g., under-perform due to systems and knowledge
Y2K bug) miscommunicated needs management tools,
Differences in culture, lateral and vertical
team experience, language, communication
gender, personalities, channels
resources, infrastructure,
historical knowledge are
moderated by existence
of rapport among some
project members
Extreme Communication Relatively difficult to build High communication:

(High shared context while virtual Rich context
complexity, project team is dispersed communication tools,
broad scope, and physical contact is rare lateral communication
high risk—e.g., Differences in culture, channels (e.g., video
mission-critical team experience, language, conferencing, web-
virtual project) gender, personalities, based information
resources and infrastructure, management portal)
historical knowledge
exacerbate the difficulties
of communication
Table 6 Proposed Typology of Project Types

Proposed Typology 31
can structure and schedule project activities. For extreme projects, com-
munication is foremost and collaborative technologies that are high in
communication support are needed. Table 6 also highlights the effects of
virtuality for each type of project.
We would also expect some differences in management focus by proj-
ect stage, although we do not focus directly on this issue in our data col-
lection. But we can speculate on expected effects. Lean projects call for a
management approach that would emphasize control at all stages. These
projects are characterized by structured problems, well-established
processes, repeatable practices, and project teams that have previously
worked together. From the inception of a project through transition
phases, control is likely to be the most important critical success factor.
Team members can work more autonomously and the top managerial
concern would be formal and informal control of team member per-
formance, adherence to deadlines, and resource management.
Hybrid projects, on the other hand, are expected to require a manage-
ment approach that emphasizes coordination. There would still be a great
need for communication among team members at the inception and con-
tinuing phases of a project. However, because the majority of project
members would already have an established rapport with each other, they
could work in a more independent fashion and, thus, the coordination of
dispersed and autonomous members would become a more important
concern. For example, in the inception and follow-up phases, there would
be a need for brainstorming and condensing the most important success
criteria, resource needs, critical activities, and functional specifications.
The construction or development phase of a project would require coor-
dinated delegation of responsibilities and adherence to deadlines. The
transition or implementation phase would be associated with bringing
autonomously developed components into a coordinated final system.
Extreme projects are expected to require a management approach
that places the greatest emphasis on communication with a moderate
concern for coordination and control. For example, in the inception
phase of a project, there would be a need for extensive interaction
between stakeholders and analysts to develop a strong agreement on the
business case, build a visual representation in the form use cases, and
delimit the scope of the project. It is also clear that this phase would
require a great degree of work synchronization due to the need to under-
stand the project scope from the various stakeholder perspectives. The
construction phase would be characterized by intense development activ-

ity that would require high levels of communication given the high proj-
ect complexity and a large number of potential increments or segments
in the project.
The ideas and typology presented in the previous sections are devel-
oped from what we know from current literature and theory. They
remain to be tested in practice. The next section describes the study that
was designed and carried out as the first step of testing these ideas.
Methodology for Data

Collection
5.1. Overview of Method

We designed a study to test our proposed typology. The data collection
for this research project was conducted using the grounded theory
research approach and the techniques pioneered by Glaser and Strauss
(1967). We used grounded theory to inductively identify patterns of
coordination, communication, and control in effective virtual project
management in the context of any organization, while comparing results
across cases. According to Glaser and Strauss (1967, p. 2), grounded the-
ory is the “discovery of theory from data systematically obtained from
social research.” The value of this approach is that “such a theory fits
empirical situations, and is understandable to sociologists and layman
alike” (ibid, p. 1).
The grounded theory approach is especially relevant for this project
because it provides a useful way to explore a phenomenon in natural
settings that are complex and dynamic, and organizational settings cer-
tainly have those characteristics. As Lyles and Mitroff (1980, p. 104) state,
“grounded theory is particularly useful for exploratory research where
you cannot have a rigid and well-controlled experimental design.”
Grounded theory allows the researcher to develop theoretical generaliza-
tions grounded in empirical observations while providing a methodology
that is “iterative, requiring a steady movement between concept and data,
as well as comparative, requiring constant comparison across types of
evidence to control the conceptual level and scope of the emerging theory”
(Orlikowski, 1993, p. 4).
33
In practical terms, using grounded theory means that we used our

interactions with study participants as a basis for developing specific
patterns of coordination, communication, and control in different types
of virtual projects. The value of the grounded theory approach lies in
its emphasis on comparative analysis of data from various firms and
subjects, and an ability to adjust questions and concepts as the research
progresses.
5.2. Participants
Consistent with the theoretical sampling technique that is required in
grounded theory-building (Glaser & Strauss, 1967; Khazanchi, 2002), we
chose subjects from organizations that are both similar and different on
various characteristics, including the company’s sector or size, as well as
the nature of projects in which they are involved. Through our personal
# of # of
Company Participants Participants
Type of Company Committed to Who Actually
ID
Participate Participated
1 Global technology 2 2
manufacturer
2 Global services provider 8 6
3 Global software and 9 2

service provider
4 Global software and 7 5

service provider
5 Global research and 3 2

engineering firm
Total 29 17
Table 7 Participants in Focus Groups

Methodology for Data Collection 35
contacts in local and global businesses, we selected a convenient sample

of people who had specific previous experiences with virtual projects
and/or who were participating in or leading virtual projects.
Five firms participated in the focus groups. Anonymity was ensured
for all participants; therefore, any company or individual identification
has been removed in this report. Table 7 shows the number of partici-
pants from each company. As the table shows, not all of the participants
who committed to the study actually participated. Work-related emer-
gencies and overall workload interfered with their ability to carry through.
5.3. Brainstorming Tool and Agenda

We used WebIQ to conduct the focus groups. WebIQ is a Web-based
meeting support application that includes capabilities for building an
agenda, conducting electronic brainstorming, and administering ques-
tionnaires. (See http://www.webiq.net/.)
All sessions were conducted asynchronously. Participants were given
a 72-hour window in which to participate. Participants from each com-
pany were provided with their own unique session ID, so that each focus
group session consisted of people within each company. Participants were
notified by e-mail in advance of the session, so they could plan for their
participation. The e-mail letter is included as Appendix B. The attached
cover letter from the Institutional Review Board is included as Appendix
C. Reminder e-mails were sent during the session in order to encourage
more participation.
After logging in, each participant first filled out a questionnaire that
asked about a specific virtual project. The second and third steps on the
agenda were brainstorming questions, and the participant was asked to
enter as many ideas as possible during the 72-hour window, as well as
comment on the ideas of others. The final step on the agenda was a clos-
ing questionnaire that asked a few demographic questions. Table 8 shows
the agenda and instructions for each activity. The beginning and closing
questionnaires are included as Appendix D.
Activity Instructions
Session Welcome and we hope you enjoy the session. Start by clicking
on the first agenda activity—Beginning Questionnaire. After you
finish the questionnaire, then go into Brainstorming. There are
two Brainstorming questions on the agenda, and you can go into
each one as often as you like over the next 72-hour period,
adding your ideas and commenting on other people’s ideas.
When you are done with all your Brainstorming ideas, click on the
last agenda activity—Closing Questionnaire. Finish that and you
are done. Thanks for your participation!
Beginning Please answer all questions to the best of your knowledge. The
Questionnaire first question asks you to briefly describe a virtual project that you
worked on within the last year, and the remaining questions are
about that specific project. Once you get to the end, click
“Submit” to finish. If you want to pause, click “Save” and then
continue from there. Keep scrolling down to answer all questions.
After you have answered all questions and clicked “Submit,” you
will be taken back to the agenda. When you are back at the agenda,
go to Brainstorming Question 1 and start entering ideas.
Brainstorming: What specific management and team member practices contributed

Question 1 to the effectiveness of your project? Think broadly to include
individual behaviors, processes, technologies, and tools. For
example, a team member practice might be to hold regular
online meetings to monitor progress of the project. Enter 5 to 10
separate ideas, each one focused on a single theme. Log in again
later to comment on ideas other people have entered and/or to
enter more of your own ideas. Feel free to expand on other people’s
ideas. To do that, click on the idea that you want to comment on,
then choose the Comment button to bring up the comment box.
Brainstorming: What specific management and team member practices contributed

Question 2 to the ineffectiveness of your project? Think broadly to include
individual behaviors, processes, technologies, and tools. For
example, a team member practice that was ineffective might be
to keep important information private rather than sharing with
the group. Enter 5 to 10 separate ideas, each one focused on a
single theme. Log in again later to comment on ideas other people
have entered and/or enter more of your own ideas. Feel free to
expand on other people’s ideas. To do that, click on the idea that
you want to comment on, then choose the Comment button to
bring up the comment box.
Closing Please answer all questions. Once you get to the end, click
Questionnaire “Submit” to finish. If at any time you want to pause, click “Save”
and then continue from there. Keep scrolling down to answer all
questions. After you have answered all questions and clicked
“Submit,” you will be taken back to the agenda. At the agenda,
you can log off from the session.
Table 8 Focus Group Agenda and Instructions

5.4. Measures and Coding Scheme

Table 9 shows the questionnaire items that were used to measure each of
the key concepts in the study. The concepts of complexity, scope, and risk
were used to identify each project type—whether it was lean, hybrid, or
extreme.
Concept Data or Formula Used*
Project complexity Mean of Q3, Q11, Q12, Q13, Q16, Q23, Q26, Q27
Project scope Mean of Q4, Q15, Q24
Project risk Mean of Q17, Q18, Q19, Q20, Q21, Q22
Project type Mean of complexity, scope, and risk. Three proj-

ects with the highest mean were coded 3
(extreme); three projects with the lowest mean
were coded 1 (lean); remaining projects in the
middle range were coded 2 (hybrid).
Project success Mean of Q6, Q7, Q8, Q9
Virtuality Mean of Q10, Q14
*All data used is from Beginning Questionnaire – see Appendix D.

Table 9 Measurement of Key Concepts in Study
We developed a coding scheme to analyze output from the brain-

storming questions in the focus groups. Consistent with our research
goals, the objective of the coding scheme was to identify the themes that
emerged from the ideas entered for the two brainstorming questions. We
actively sought to identify ideas related to communication, coordination,
and control, but also looked for other emergent themes. We were also
interested in references to specific technologies and their positive or neg-
ative impact on the team.
The first step was to code for themes. Each complete idea from the
two brainstorming questions was coded for the existence of one or more
themes; that is, a brainstorming idea could refer to more than one theme.
Each theme was coded as communication, coordination, control, or an
emergent theme if none of those three applied. The theme was identified
based on the definitions of communication, coordination, and control
that were the basis for the research, as developed in the conceptual foun-
dations for the research. For our own exploratory use, we also coded sub-
themes for the major themes.
The second step was to code for technology. Each complete idea was
coded for any reference to a specific technology that was used for the vir-
tual project, and a + or – sign was used to show that the technology had
a positive or negative effect on the project. Again, each idea could men-
tion more than one technology; thus, multiple codes were possible.
Table 10 shows the coding scheme with specific examples. The first
column shows examples of complete ideas from the brainstorming data.
The second column shows the theme(s) of the idea. The third column
shows sub-categories of themes, if they were identified. The fourth col-
umn shows any technologies that were mentioned, and the final column
Sub-Category Technology
Text of Idea Theme +/-
(if applicable) (if applicable)
Utilized the phone for Communication Meaning Telephone +

discussion and error
diagnosis/resolution
Good error logging Coordination Distributed +

capabilities of tools. PM tools
Daily checkpoint Control

meetings amongst
the developers and
the architecture folks
were crucial and
added a lot value
Notes:
Communication = exchange of messages and information to convey meaning
Coordination = mechanisms for carrying out project activities
Control = monitoring and measuring
Table 10 Coding Scheme with Examples

indicates whether the technology was perceived to have a positive (+) or

a negative (-) effect on the project.
The two authors of this report worked together to identify the codes
for ideas from the first company. Any disagreements were resolved
through discussion. The remaining data was divided for separate coding
by the two authors, but they reviewed each other’s work and agreed on
any major discrepancies. It should be noted that disagreements were rel-
atively rare. Thus, we believe that the coding scheme is easy to apply in a
reasonably consistent way. We did not calculate inter-rater reliabilities
because of the high initial agreement and follow-up consensus. Such an
approach was possible because the number of ideas was not overwhelm-
ingly large.
Analysis and Results
his section describes the analysis and results of the data that was
T collected in the focus groups. We begin with descriptive information
from the questionnaire data, focusing first on technology and then on
the different aspects of the project as described by participants and
organized by project type.
6.1. Use of Technology

Table 11 shows the responses of the participants when asked about the
extent to which they used specific technologies to work with team mem-
bers on the project (questions 29 through 43 in Appendix D). The table
also shows the mean for technology used by project type. The table is
sorted by the most frequently to least frequently used technologies overall.
Our data confirms that e-mail is still the most often-used technology
for communication among virtual team members, followed by various
forms of the telephone (including conference calling and voice mail). The
data for face-to-face meetings is especially interesting, because it shows
that team members make the most use of face-to-face communication in
extreme projects.
There is a clear break in the frequency with which participants used
the more “traditional” e-mail and voice tools, versus the tools for group
work that have been developed more recently. Such tools as simultaneous
document editing and shared whiteboard were rarely used. Again, the
table shows the persistence of familiar tools that are easily accessible and
comfortable for all.
41
Mean for Mean for Mean for

Overall Overall
Technology Lean Hybrid Extreme
Mean Std. Dev.
Projects Projects Projects
E-mail 4.65 5.00 5.00 4.93 0.27
Telephone 3.00 4.71 4.50 4.29 0.91
Conference calling 2.67 4.57 4.50 4.14 0.95
Voice mail 2.33 4.00 4.00 3.64 0.84
Face-to-face meetings 1.33 3.14 3.25 2.79 1.12
Web-based intranet tools

1.00 2.71 2.75 2.46 1.27
(e.g., groove.net)
Group calendaring 1.00 3.14 2.25 2.43 1.45
Distributed project
1.00 2.57 1.75 2.00 1.30
management tools
Electronic meeting systems

(e.g., WebIQ, GroupSystems, 1.00 2.14 1.75 1.79 1.19
Facilitate.com)
Video conferencing (room

1.00 2.14 1.75 1.79 1.25
and/or desktop)
Simultaneous
1.00 2.14 1.50 1.71 0.99
document editing
Workflow system 1.67 1.57 1.75 1.64 0.63

Shared whiteboard 1.00 1.71 1.50 1.50 0.52
Instant messaging 1.67 1.14 2.00 1.50 0.85
Fax 1.67 1.14 1.50 1.36 0.50
Scale: 1 = Never; 5 = Almost Always
Table 11 Use of Technologies During Virtual Projects
It is also worth noting that distributed project management and electronic

meeting systems were used very little across all project types. The means
of usage are highest in hybrid projects for both these tools, but, even
so, the means are still low. These two tools, in particular, support struc-
ture for group process, but they require a greater learning curve and
reinforcement.
Analysis and Results 43
6.2. Project Types

Table 12 shows the project type for each of the respondents and the val-
ues of the associated composite variables. (The calculation of each of
these variables was described in section. 5) The table is sorted by type of
project, ranging from lean to extreme. As the table shows, three projects
were identified as being lean projects, four were identified as being
extreme projects, and the remaining seven were identified as being hybrid
projects. Table 13 summarizes the same information by project type.
Part. Comp. Project Project Project Overall Project Project

Virtuality
ID ID Scope Complexity Risk Mean Type Success
17 4 1.67 2.33 2.00 1 4.00 2.00

4 2 2.00 2.50 2.50 2.33 1 4.00 1.00
18 5 2.67 2.57 2.80 2.68 1 4.25 4.00
14 4 1.67 3.29 4.67 3.21 2 2.67 3.00
15 4 4.00 2.88 2.83 3.24 2 2.00 3.00
16 4 2.33 2.75 4.67 3.25 2 3.67 2.00
2 1 3.00 3.88 3.50 3.46 2 3.33 3.00
19 5 3.33 3.75 3.50 3.53 2 3.50 4.00
10 2 3.33 3.50 3.83 3.55 2 5.00 4.00
11 3 4.67 3.25 3.33 3.75 2 4.75 4.00
13 4 4.33 4.00 3.50 3.94 3 4.00 3.00
1 1 4.33 4.00 3.67 4.00 3 4.00 3.00
12 3 4.33 4.25 3.50 4.03 3 4.25 3.00
6 2 4.00 3.75 4.50 4.08 3 4.75 3.00
Overall
3.26 3.34 3.60 3.36 3.87 3.00
Mean
StDev 1.06 0.63 0.69 0.64 0.81 0.88
Note:Project Type 1 = Lean; 2 = Hybrid; 3 = Extreme

Scale for all other values is 1 = lowest, 5 = highest
Table 12 Measurement of Project Type and Related Variables

Project Project Project Project Overall Project

Virtuality
Type Scope Complexity Risk Mean Success
Lean 2.11 2.47 2.65 2.34 4.08 3.11
Hybrid 3.19 3.33 3.76 3.43 3.56 3.14
Extreme 4.25 4.00 3.79 4.01 4.25 2.92
Table 13 Means of Key Variables by Project Type
Table 14 shows the means on the questionnaire responses by project type.

The anchor points for the scales of each question are also indicated.
There are several interesting observations to be made from the ques-
tionnaire responses reported in these tables. As noted earlier, we calculat-
ed project type based on our definition of key concepts, namely scope,
complexity, and risk. The complexity measure takes into account many of
the issues that are present in virtual teams that contribute to the challenges
of their management—for example, variety in cultural background and
language differences. However, we also had a separate measure of greatest
time difference among members, which we used in the overall measure of
virtuality. Interestingly, the greatest time differences among members were
in lean projects rather than extreme projects, which contributed to a vir-
tuality measure that was similar across all three types of projects.
Another interesting finding was that participants in extreme projects used
face-to-face meetings more often than the other project types. When com-
bined with the measure of project success, this finding makes sense. Extreme
projects were actually rated more successful than either of the other two proj-
ect types. (It should be noted that nearly all projects were rated positively on
success.) Face-to-face time and success for virtual projects are an important
prescription in the literature, and that prescription is reinforced by this data.
The next table shows the dominant managerial concern as perceived
by participants. All participants were asked to identify the dominant
managerial concern for the project on which they were brainstorming
ideas. Table 15 shows the actual text from each questionnaire, showing
the dominant managerial concern for each project. The first column
shows the project type, the second column shows the coding of the com-
ment (by the authors), and the third column is the actual text of the
comment. The same coding scheme as described for the brainstorming
ideas (see section 5) was used to code these comments.
Question Lean Hybrid Extreme

Size of project team (1=Small, 5=Large) 1.67 3.57 4.50
Planned schedule (1=less than 6 months,
1.00 2.43 4.25
5=greater than 12 months)
Project was completed as scheduled * 3.33 3.43 4.00
Project was completed within budget 4.00 3.80 3.67
Project met its goal and specified requirements* 4.00 4.43 3.75
Project was a success* 4.00 4.14 4.00
Greatest time difference between team members
3.67 1.86 2.50
(1=less than 3 hours, 5=greater than 10 hours)
Cultural background of team members (1=homo-
1.00 3.57 5.00
geneous, 5=heterogeneous)
Language differences between team members
1.00 1.86 3.50
(1=homogeneous, 5=heterogeneous)
Proficiency with virtual team technology 4.00 3.25 2.50
(1=expert, 5=novice)
Number of firms in team (1=single, 5=more than two) 1.00 4.71 3.50
Overall scope of project (1=very small, 5=very large) 1.67 3.71 4.75
Overall complexity of project (1=extremely simple,
3.33 4.43 4.50
5=extremely complex)
Programmatic risk of project** 2.50 3.86 4.25
Technical and engineering risk of project** 2.50 4.00 3.75
Quality risk of project** 2.00 3.71 3.75
Logistical risk of project** 2.50 3.57 4.00
Deployment risk of project** 2.50 3.86 3.25
Overall risk of project** 3.50 3.57 3.75
Availability of historical knowledge
3.67 2.43 4.50
(1=explicit, 5=implicit)
Level of innovation (1=Extremely traditional,
3.67 3.43 3.75
5=Extremely innovative)
Degree of resources available (1=Redundant,
3.00 5.00 5.00
5=Complementary at each site)
Personality of majority of team members
2.33 2.71 3.00
(1=Homogeneous, 5=Heterogeneous)
*1=Strongly disagree, 5=Strongly disagree
** 1=Very low risk, 5=Very high risk
Table 14 Means on Questionnaire Responses by Project Type

Project Project
Type Management Participants’ Dominant Concern
Dimension
Understanding user requirements and staying within the
1 Control
limits of the scope of the project.
Staying focused - major distractions were a combination
of what we call “drive-by’s” (unexpected questions that
are directed to you for resolution that can take anywhere
from 2 minutes to 2 days . . .) and experiencing “techni-
1 Coordination cal difficulties” with the application we were testing
(e.g., the database/script wasn’t configured correctly, or
we encountered a software issue that was a showstop-
per. We didn’t have the knowledge/experience with the
application to fix/find anything other than basic issues).
How to ensure all project participants had a common
understanding about the client’s expectations, the activi-
1 Communication
ty functions we were to address, and the “story” we had
to tell with the concept description.
Working with contract manufacturers to develop a tech-
nology that had not been previously used by one of the
2 Control contractor manufacturers, and attempting to keep the
other contract manufacturer focused on the delivery and
quality of the programs to be delivered.
Level 1 communication in the project was critical as we
were extending and rewriting some of the process, and
2 Communication
there was a time zone difference between us, making it
difficult to get questions answered immediately.
2 Communication Making people work in different time zones
2 Control Scalability and availability of the solution

2 Communication Perception being delivered to upper management
Resolution of offered solutions - when several “solutions”
were offered and there were differences in those solutions—
2 Communication
how to select the solution to be implemented. Solutions
took the form of both concepts and technical solutions.
3 Communication Keeping meeting length reasonable.
Managing schedules remotely, integration of data
3 Coordination between two sites. New technologies or technologies
that people were not familiar with
3 Communication Effective communication, people retention
Amount of information required to understand the system
Communication
3 to a good extent and coordination/enforcement of central
& Coordination
design principles
Note: Project Type: 1 = Lean, 2 = Hybrid, 3 = Extreme
Table 15 Dominant Managerial Concern (From Questionnaire)

Consistent with our earlier expectations, every one of the extreme proj-
ects had communication as a dominant concern. (One extreme project
also included coordination.) The lean projects did not have a consistent
theme. We had expected control to be the key theme in lean projects, but
instead there was a mix of concerns. Hybrid projects also did not exhibit
the coordination theme that we expected. This is only one piece of evi-
dence, however, and it serves as an “overall” type of check against the
more detailed evidence, which comes from the coding of the brainstorm-
ing questions.
6.3. Patterns for Effective Management of Virtual Projects
We started this study with the assertion that patterns of virtual proj-
ects can be identified. Furthermore, we hypothesized that it is possible to
differentiate between effective and ineffective patterns. We argued that
three theoretical elements should help to define patterns. Those elements
are communication, coordination, and control. Furthermore, technology
was expected to constrain and enable the way that each element is han-
dled and the balance or pattern among elements. Thus, a potential design
pattern for virtual project management would include descriptions of
processes, best practices, factors, tools and/or techniques that impinge
upon coordination, communication, and control.
Each of the following sub-sections details the patterns we identified
for lean, hybrid, and extreme projects, respectively. Each pattern is based
on the brainstorming data from the virtual focus groups. That is, for each
type of project (lean, hybrid, extreme), we examined all the comments
that were coded for each dimension of management practice (communi-
cation, coordination, control) and developed a pattern based on that set
of comments. Multiple patterns could be generated from one set of com-
ments.
Each pattern is described in terms of: (1) the pattern’s name—a
descriptive word or phrase that captures its essence; (2) the context—a
description of the situation to which the pattern applies; (3) the prob-
lem—a question that captures the essence of the problem that the pattern
addresses; (4) the solution—a prescription for dealing with the problem;
and (5) an optional discussion—any additional information that might
be useful in applying the pattern.
6.3.1. Patterns for Lean Projects
Communication Time
Context
Team members do not have a shared understanding of project issues
and solutions.
Problem
How do you ensure effective communication among team members?
Solution
Schedule periodic conferences using technologies that emphasize
communication (e.g., telephone and telephone conferencing, e-mail,
and video conferencing).
Discussion
The study participants working on lean projects were particularly con-
cerned about communication. Since lean projects are neither complex
nor large in scope, the study participants handled them mostly via a
virtual mode and predominantly used e-mail and regularly scheduled
telephone conferencing for communicating with stakeholders.
Shared Resources
Context
Team members and other project stakeholders are unable to share
resources easily.
Problem
How do you provide access to shared resources?
Solution
Provide high-speed telecommunications infrastructure for access to
shared resources. Set up access policy for all project stakeholders,
including vendors and team members.
Discussion
Flex Work Time
Context
It is difficult for team members to work extra hours when needed.
Problem
How do you find the right mix of team members who enjoy working
extra hours when needed?
Solution
Include a mix of recent college graduates with experienced
members. Recent graduates tend to enjoy working late hours and
could provide the flexibility needed to accomplish tasks during
crunch times.
Discussion
Team Project Control
Context
A delay occurs in a project task that could impact dependent
activities.
Problem
How do you monitor project progress within a virtual team?
Solution
Schedule periodic (weekly or daily as needed) project review meet-
ings for all or some members of the virtual team. These meetings are
used to review progress on project tasks, discuss timelines and
dependent activities, and to resolve issues. The frequency of the
meetings may vary depending on the total timeline for the project
and the criticality of the issue to the success of the project.
Discussion
Our study’s participants particularly emphasized the advantages of
regular face-to-face meetings of some or all team members to
resolve issues and monitor project progress.
Managerial Project Control
Context
The progress of the project is impeded due to inadequate informa-
tion sharing between the project team members and the manager
responsible for interacting with the client.
Problem
How do you monitor project changes based on interactions with
your client?
Solution
Schedule periodic (weekly or daily, as needed) project review meet-
ings for all or some team members with the project manager or
manager interacting with your client(s). These meetings are used
both to update the manager regarding the project status and to cull
new information obtained from the project client(s) that may have a
direct impact on project tasks.
Discussion
Task Coordination
Context
There is a complete disconnect between team members as new
members are added.
Problem
How do you ensure task coordination as new members are added to
a team?
Solution
Coordinate task assignment to new team members by clearly com-
municating revised roles and responsibilities along with timelines
and tasks to all the team members. Ensure that everyone
understands the assignment of new members in the team and con-
vey this to all stakeholders and team members.
Discussion
Change Control Coordination
Context
The project involves too much rework.
Problem
How do you ensure that rework is minimized by effectively coordi-
nating project milestones?
Solution
Coordinate rework on project by (a) establishing a client sign-off
requirement at each major milestone on the project, (b) insisting on
client sign-off at each milestone, (c) reviewing with clients the
impact on scope, cost and schedule, and (d) building contractual
language to manage excessive rework requests.
Discussion
Gatekeeping
Context
Problem
How do you ensure that rework is reduced?
Solution
Obtain client sign-off as each major milestone on the project is com-
pleted. Follow solution provided under the earlier pattern, “change
control coordination.”
Discussion
Version Control
Context
Your project has less-than-rigorous “version control” of the larger
document that the team is working on. Because of this, people are
working from a product version that is slightly or significantly out of
date or incomplete.
Problem
How do you effectively coordinate version control?
Solution
Manage versioning of documents by using PM/Workflow tools and/or
CASE tools. Such tools include document versioning and management
features that have features such as controlled document access, auto-
mated routing, document publishing control, etc.
Discussion
Expertise
Context
You are unable to fix something within the team and progress is
stalled until this issue is resolved. This is difficult enough in a co-
located office environment, but the virtual nature of your project
substantially increases the magnitude of the problem/issue.
Problem
How do you coordinate access to human expertise to assist with
problems that are stalling the project?
Solution
Plan for and provide the project team with easy access to subject
matter experts, technical experts, and experienced software/system
architects who can provide advice/help needed to resolve
problems/issues that crop up during the project. Use process tech-
nologies such as Web-based intranets and/or knowledge
management portals to share experiences across the organization
and dispersed team members.
Discussion
Scope Creep
Context
Your project has major scope creep because of an absence of clear
definition of scope at the outset.
Problem
How do you coordinate and control for project scope creep that
could substantially delay or increase the cost of the project?
Solution
Manage scope creep by re-scoping the project with stakeholders and
managing expectations. Conduct an impact analysis and attach a
revised cost and schedule on the new requirements. Set clear project
expectations. Document requirements and review them with the
stakeholders before any sign-off. Develop a flexible project plan,
allowing users to participate in the analysis and design phases of the
project. Establish a formal change management process that makes
users asking for more functionality accountable for the demand.
Postpone late change requests to a new phase of the project. Build
chance processes into the contract itself by allowing for some per-
centage of change in requirements.
Discussion
6.3.2. Patterns for Hybrid Projects
Face Time
Context
Team members neither agree nor have a shared understanding of proj-
ect issues, solutions, work processes, and documentation requirements.
Problem
How do you ensure effective communication and build trust among
team members?
Solution
Schedule periodic face-to-face (FTF) conferences by flying some
team members—possibly by rotation—to different locations. Though
costly, even occasional participation in FTF meetings over the lifetime
of a project is very effective. FTF meetings can engender increased
trust and engagement among team members, and can also help
clarify various facets of the project and resolve issues/conflicts.
Discussion
Shared Resources
Context
Team members and other project stakeholders are unable to share
resources easily.
Problem
How do you provide access to shared resources?
Solution
Provide high-speed telecommunications infrastructure for access to
shared resources. Set up access policy for all project stakeholders,
including vendors and team members.
Discussion
Meeting Design
Context
During meetings conducted via conference calls, your team gets
bogged down in details that do not necessarily apply to many team
members. This becomes increasingly complicated with a large num-
ber of project stakeholders.
Problem
How do you develop a meeting environment that stimulates effec-
tive communication among team members?
Solution
Schedule periodic conferences using a variety of technologies that
emphasize communication (e.g., telephone and telephone confer-
encing, e-mail, and video conferencing). Design meetings based on
the following guidelines: (a) use the participation of all stakeholders
when the goal is to inform and develop a shared understanding of
broad project goals and issues; (b) use selective participation of rele-
vant stakeholders to deal with specific issues and challenges; (c) keep
meeting agendas short. Remember that people have short attention
spans, particularly when you cannot see them. Anything more than
an hour is probably better suited to a focused small meeting; consid-
er having more meetings rather than long ones; and (d) consider
which format would work best at meetings for the issues at hand.
Discussion
Role Coordination
Context
Your team members are unclear about their roles and responsibilities
in the project. This is causing misunderstandings about project goals
and resulting in a delayed project.
Problem
How do you provide team members with a clear understanding of
their individual roles and responsibilities in the project?
Solution
Cleary define team members’ roles and responsibilities and work
processes at the outset. If new members are added, clearly commu-
nicate revised roles and responsibilities along with timelines and
tasks to all the team members. Ensure that they all understand their
assignment and provide them with the tools to deliver.
Communicate roles, responsibilities, and work processes to all stake-
holders and team members. If feasible, consider rotating members
through different roles. Use technologies with a high process struc-
ture (such as virtual collaboration systems and knowledge manage-
ment tools) to share information on the team’s work processes and
roles/responsibilities of team members. Include team members in
designing work processes and delineating roles/responsibilities. This
will increase team ownership.
Discussion
Human Expertise
Context
You are unable to fix something within the team, and progress is
stalled until this issue is resolved. This is difficult enough in a co-
located office environment, but the virtual nature of your project
substantially increases the magnitude of the problem/issue.
Problem
How do you coordinate access to human expertise to assist with
problems that are stalling the project?
Solution
Plan for, and provide the project team easy access to, subject-matter
experts, technical experts and experienced software/system
architects who can provide advice/help needed to resolve
problems/issues that crop up during the project. Use process tech-
nologies such as Web-based intranets and/or knowledge
management portals to share experiences across the organization
and to dispersed team members.
Discussion
Relationship Coordination
Context
Your team is having difficulties accepting each other’s information. This is
aggravated by the difficulty of building mutual trust in a virtual setting.
Problem
How do you build strong relationships among team members?
Solution
Set up immediate trust between team members while working on
building mutual trust over time. Encourage a team culture that
accepts constructive criticism and questioning of each other’s deliver-
ables. A team culture that builds on respect, courtesy, open communi-
cation, and flexibility will go far in building stronger relationships.
Remember that people are quick to make attributions the effects of
which last. Make sure that those early attributions are positive.
Discussion
Conflict Resolution
Context
Your team is not able to manage conflicts and resolve them during
discussions on a shared understanding of requirements, resolution of
project-related issues, and challenges.
Problem
How do you establish consensus and resolve conflicts effectively
when team members have differing personalities, cultural and lan-
guage backgrounds, and personal goals?
Solution
Establish and communicate the project vision, goals, tasks, roles, and
responsibilities clearly. When team members have shared goals and
work towards them, projects are successful. At the outset, establish,
in consultation with the team, a clear work process for evaluating
recommendations on issues and handling conflicts. Potentially, you
could use a team steering group to handle conflicts that do not
reach a consensus solution. Have a mechanism to prioritize problems
and issues for consideration by the whole team.
Regular and open communication among team members, team
and management, team and vendors, and team and customers will
impact the team’s ability to manage the conflict resolution process.
All recommendations should be given due consideration and, if
accepted, must be acted upon. In addition, building consensus on
solutions and the meaning of requirements and goals will depend on
team cohesion and project leadership.
Discussion
Scope Creep
Context
Your project has major scope creep because of an absence of clear
definition of scope at the outset.
Problem
How do you coordinate and control for project scope creep that
could substantially delay or increase the cost of the project?
Solution
Manage scope creep by re-scoping project with stakeholders and
managing expectations. Conduct an impact analysis and attach a
revised cost and schedule to the new requirements. Set clear project
expectations. Document requirements and review them with the
stakeholders before any sign-off. Develop a flexible project plan
allowing users to participate in the analysis and design phases of the
project. Establish a formal change management process that makes
customers asking for more functionality accountable for the
demand. Postpone late change requests to a new phase of the proj-
ect. Build chance processes into the contract itself by allowing for
some percentage of change in requirements.
Discussion
Change Control Coordination
Context
Problem
How do you ensure that rework is minimized by effectively coordi-
nating project milestones?
Solution
Coordinate rework on project by (a) establishing a client sign-off
requirement at each major milestone on the project, (b) insisting on
client sign-off at each milestone, (c) reviewing with client the impact
on scope, cost and schedule, and (d) building contractual language
to manage excessive rework requests.
Discussion
Project Leadership
Context
Your team does not have adequate project and technical leadership.
Problem
What are the elements of effective project leadership?
Solution
Effective project leadership in virtual teamwork is absolutely essential
for project success. It is achieved when there is a single individual
tasked with leading the virtual team, and when this person is held
accountable for both success and failure. The leader develops (in con-
sultation with the team) and credibly communicates the project vision
and strategy. This helps create a culture of open communication and
consensual decision-making. The leader also motivates and inspires
team members so that they are energized and are able to overcome
any barriers of working in virtual settings, including time zone and
geographic differences, organizational and political challenges, and
resource constraints. Finally, an effective leader is also responsible for
aligning the “right” people for the project and tasks therein.
Discussion
6.3.3. Patterns for Extreme Projects
Extreme projects are likely to need all of the patterns that we previously
identified for Hybrid projects. The following patterns are in addition to
what we already identified for Hybrid projects.
Coordinating Human Resource
Context
Your team is having difficulties coordinating the problem resolution
process between consultants at a remote site. These delays are fur-
ther exacerbated by an inability to get required participants together
at both ends for a discussion.
Problem
How do you effectively communicate between remote and local sites
for problem resolution?
Solution
In addition to regular conferencing, place consultants and experts at
both remote and local sites. This approach could alleviate a number
of concerns, including those associated with language and cultural
differences, and delays in getting together participants for problem
resolution.
Discussion
Management Commitment
Context
You have just been assigned to a large virtual project that does not
seem to have adequate top management commitment at this time.
Problem
How do you ensure virtual project success through top management
commitment?
Solution
Management commitment is crucial to sustaining the virtual team
model. Develop a strong “business case” to educate senior manage-
ment about the benefits and costs associated with running a large
virtual project. Seek to engage a senior executive with appropriate
political clout and innovative spirit to champion the virtual team and
manage the interactions with other senior executives in your organi-
zation. This senior executive can also serve as the final arbiter of
issues that cannot be resolved within the virtual team.
Discussion
Managing Virtuality
Context
Your team is having difficulty with time zone differences at both the
national and global levels. This is particularly highlighted during
crunch time or crisis situations when communication is not prompt,
delaying the problem resolution process.
Problem
How do you overcome time zone and geographic differences and
effectively engage all team members?
Solution
Overcome distance barriers due to time zone and geography by
eliminating them during activities requiring intensive interaction and
coordination, such as project initiation, by temporarily collocating
team members. Require periodic site visits and travel by team mem-
bers to different sites. Designate team member liaisons as focal
points of coordination who spend some time in the home office
location, to become acculturated and informed about technical
issues; liaisons can then transfer knowledge to local sites for day-to-
day coordination. Assign team members in one geographic region
(e.g., North and South America) to tasks requiring telephone or
video-based interactions because they share time zones and thus can
more easily schedule conferences.
Discussion
Collocating team members for face-to-face interactions can also help
them establish ground rules and common understanding that facili-
tate communication and coordination when team members return
home. This also allows team members to build a social network and
stimulates the development of team identity, cohesion, and commit-
ment that can be potentially sustained once team members are
again dispersed. (Davidson & Tay, 2003).
Overcoming time zone differences is critical not just for global
teams. For example, in the USA, one of our study participants stated
that project notifications from the pacific time zone would reach the
central time zone later in the day, leaving less time or required work
outside of normal hours for team members.
Standardization
Context
Your team members are documenting project requirements and
solutions in multiple formats. This is causing enormous effort for
some members who are integrating and creating final project docu-
ments.
Problem
How do you reduce rework with project documentation through
standardization?
Solution
Any project tasks, activities, document formats/templates, reports,
and team member roles/responsibilities that can be structured
should be formalized or standardized, and communicated or shared,
with team members. This is good practice across all projects, but
particularly critical for virtual projects. Any such standardization can
reduce the complexities of virtual team coordination. Many analysis
and design activities for projects may be structured to minimize the
need for coordination and face-to-face interaction. Utilize collabora-
tive technologies such as workflow tools for simultaneous document
editing and web-based information management tools for sharing
knowledge and standardized processes, documents, and roles.
Discussion
Knowledge Management
Context
Team members are unable to share intelligence, best practices, and
simultaneously edit master documents. In some instances, your team
members are not following established processes.
Problem
How do you mobilize and share knowledge across the team and
your organization?
Solution
Start with input from project team members across the organization
and build a repository of best practices, templates, learning tools,
workflow standards, and examples of processes within standard
methodologies. Make sure all members of the team have access to,
and can contribute to, the knowledge portal.
Discussion
Shared Understanding
Context
Team members do not feel that they are a unified whole. People feel
they are working independently rather than together.
Problem
How do you create synergy in your team and a shared understand-
ing of project goals?
Solution
Use face-to-face or video conferencing to introduce and socialize
team members at the inception of a project. Communicate clearly
and often on project goals and individuals’ roles in the project.
Create a culture that encourages the sharing of issues, good and bad
news, and all project-related information; a discussion of solutions;
and the flexibility to accept differences. Follow all the suggestions
made in the earlier pattern, “managing virtuality”.
Discussion
Training
Context
There are differences in training between team members. For exam-
ple, the test lead does not recognize the connection between
requirements and the test plan.
Problem
How do you reduce the impact of differences in training and back-
ground?
Solution
Require training for all new team members on standard work
processes and project methodologies prior to starting new projects.
Encourage initial communication between team members, using
video or telephone conferencing to discuss standards, roles/responsi-
bilities, methodologies, team culture, and issue resolution processes.
Assign individuals with the skills to successfully accomplish their
tasks. Build on individual team members’ strengths while allowing
them to expand their skills and expertise through additional training
and role rotation.
Discussion
Implications and
Conclusions
his study makes several contributions. First, we provided a clear def-

T inition of key concepts related to virtual project management, based
on an integration of existing literature. Second, we developed a project
typology that has a strong theoretical foundation. Third, we developed a
set of measures by which to classify projects within the typology. Fourth,
we developed a coding scheme to identify key project management con-
cerns. Finally, we provided a set of patterns for the effective management
of virtual projects.
The contributions to theory come from the development of concept,
the typology, and the pattern approach. The contributions to research
methodology arise from the measures and coding scheme. The contribu-
tions to practice are in the patterns. Managers of virtual projects can fol-
low either a deductive or inductive process. A deductive approach would
start with identifying the type of project (using the measures developed),
then searching the patterns for that project type, and applying the pre-
scribed solution for each relevant problem. An inductive approach would
start with a search of the pattern library, looking for any patterns that
apply. If the problems fall primarily into one project type, then the man-
agers can reasonably infer that this is the type of project.
As with any study of this kind, several limitations apply. The patterns
were derived from a limited data set. Even though we had participants
from five different companies, and the type of projects they were com-
menting on had sufficient diversity for our categorization, the generaliz-
ability of our conclusions is still limited. Furthermore, even though the
coding scheme was based on theory, there may be other dimensions that
67
also matter in addition to the ones we identified and used in the develop-
ment of patterns. The next steps for research follow naturally from the
limitations of the study. Additional settings can be examined and the con-
cepts tested with additional data.
One issue that was reinforced throughout these projects is the impor-
tance of communication. Regardless of the type of project, communica-
tion was mentioned time and time again as a fundamental necessity. Both
research and our study reinforce the idea that communication is impor-
tant in and of itself, as well as through its relationship to coordination
and control. All of these teams relied heavily on e-mail and voice media,
both of which emphasize communication. Thus, the communication
dimension of technology had the greatest priority—more so than process
structure or information processing.
Another interesting result related to technologies was the relatively
low use of distributed project management tools. Indeed, there was gen-
erally low use for all of the technologies that we would categorize as pro-
viding support for process structure or information processing. Clearly,
there is much room for improvement in providing better tools and train-
ing for virtual teams in these areas.
We started with the goal of going beyond a cookbook approach to the
management of virtual projects. The theoretical framework of patterns
helps us make a large step toward that goal. The results from this study
provide immediate and practical guidance for managers of virtual proj-
ects, and provide a strong foundation for continuing research in this
important area.
References
Alexander, C. (1965). Notes on the synthesis of form. Cambridge, MA: Harvard

University Press.
Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I., &
Angel, S. (1977). A pattern language: Towns, buildings, construction. New
York: Oxford University Press.
Austin, R. D., & Westerman, G. (2002). Destiny WebSolutions, Inc. Case Study.
Boston: Harvard Business School Press.
Avolio, B. J., Kahai, S., & Dodge, G. E. (2001). E-Leadership: Implications for
theory, research, and practice. Leadership Quarterly, 11(4), 615-668.
Bernstein, N. (1967). The coordination and regulation of movement. London:
Pergamon.
Burke, K., Aytes, K., & Chidambaram, L. (2001). Media effects on the develop-
ment of cohesion and process satisfaction in computer-supported work-
groups: An analysis of results from two longitudinal studies. Information
Technology & People, 14(2), 122-141.
Carlson, J. R., & Zmud, R. W. (1999). Channel expansion theory and the expe-
riential nature of media richness perceptions. Academy of Management
Journal, 42(2), 153-170.
Carmel, E., & Agarwal, R. (2001). Tactical approaches for alleviating distance in
global software development. IEEE Software, March/April, 22-29.
Chen, F., Nunamaker, Jr., J. F., Romano, N. C., & Briggs, R. O. (2003). A collabo-
rative project management architecture. Proceedings of the 36th Hawaii
International Conference on System Sciences. IEEE Computer Society
Press, Track 1, p. 15.1.
69
Chinowsky, P. S., & Rojas, E. M. (2003). Virtual teams: Guide to successful

implementation. Journal of Management in Engineering, 19(3), 98-106.
Christensen, M. J., & Thayer, R. H. (2001). The project manager’s guide to soft-
ware engineering’s best practices. Los Alamitos, CA: IEEE Computer
Society.
Cramton, C. D. (2001). The mutual knowledge problem and its consequences
for dispersed collaboration. Organization Science, 12(3), 346-371.
Crowston, K. (1991). A coordination theory approach to organizational process
design. Organization Science, 8(2), 157-175.
Davidson, E. J., & Tay, A. S. M. (2003). Studying teamwork in global IT support.
Proceedings of the 36th Hawaii International Conference on Systems
Sciences (HICSS).
DeSanctis, G., & Gallupe, R. B. (1987). A foundation for the study of group
decision support systems. Management Science, 33(5), 589-609.
DeSanctis, G., & Poole, M. S. (1994). Capturing the complexity in advanced
technology use: Adaptive structuration theory. Organization Science,
5(2), 121-147.
Doty, D. H., & Glick, W. H. (1994). Typologies as a unique form of theory
building: Toward improved understanding and modeling. Academy of
Management Review, 19(2), 230-251.
Dubé, L., & Paré, G. (2001). Global virtual teams. Communications of the ACM,
44(12), 71-73.
Dubé, L., & Paré, G. (2004). The multi-faceted nature of virtual teams. In D. J.
Pauleen (Ed.). Virtual teams: Projects, protocols, and processes (pp. 1-39).
Hershey, PA: Idea Group Publishing.
Encyclopædia Britannica Online (2004).
Retrieved December 1, 2004, from http://search.eb.com.leo.lib.unoma-
ha.edu/dictionary?srcho=va&hdwd=coordination&listword=coordina-
tion&book=Collegiate&hiword=&jump=coordination&list=coordinatio
n%3D239940%3Bcoordination+complex%3D239951%3Bcoordination+
number%3D239968&x=2&y=20
Evaristo, R., & Munkvold, B. E. (2002). Collaborative infrastructure formation
in virtual projects. Journal of Global Information Technology
Management, 5(2), 29-47.
Fernandez, A., Holmer, T., Rubart, J., & Schuemmer, T. (2002). Three group-
ware patterns from the activity awareness family, EuroPLoP 2002.
Seventh European Conference on Pattern Languages of Programs, July
3-7, 2002. Irsee, Germany.
References 71
Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design patterns:
Elements of reusable object-oriented software. Reading, MA: Addison-
Wesley.
Gassmann, O., & Von Zedtwitz, M. (2003). Trends and determinants of manag-
ing virtual R and D teams. R & D Management, 33(3), 243-262.
Glaser, B. G., & Strauss, A. L. (1967). The discovery of grounded theory: Strategies
for qualitative research. Chicago: Aldine Publishing Company.
Godart, C., Bouthier, C., Canalda, P., Charoy, F., Molli, P., Perrin, O., et al.
(2001). Asynchronous coordination of virtual teams in creative applica-
tions (co-design or co-engineering): Requirements and design criteria.
Australian Computer Science Communications, 23(6),135-142.
Grant, R. M. (1996). Toward a knowledge-based theory of the firm. Strategic
Management Journal, 17 (Winter Special Issue), 109-122.
Henderson, J. C., & Lee, S. (1992). Managing IS design teams: A control theo-
ries perspective. Management Science, 38(6), 757-777.
Hofstede, G. J. (2001). Culture’s consequences: Comparing values, behaviors,
institutions and organizations across nations (2nd ed.). Thousand Oaks,
CA: Sage Publications.
Homsky, O. (2003). More patterns for group leadership, EuroPLoP 2003.
Seventh European Conference on Pattern Languages of Programs, June 25-
29, 2003. Irsee, Germany.
IEEE. (2004). IEEE Standard 1540-2004. IEEE Standard for Software Life Cycle
Processes – Risk Management. IEEE Press.
Jarvenpaa, S., & Leidner, D. (1999). Communication and trust in global virtual
teams. Organization Science, 10(6), 791-815.
Johansen, R. (1988). Groupware: Computer support for business teams. New
York: Macmillan.
Katzy, B., Evaristo, R., & Zigurs, I. (2000). Knowledge management in virtual
projects: A research agenda. Proceedings of the Thirty-Third Hawaii
International Conference on System Sciences. Maui, HI.
Khazanchi, D. (2002). Understanding and measuring corporate IS sophistication:
An exploratory investigation using grounded theory, in L. Cromwell (Ed.).
Issues in Information Systems. IACIS, Volume III, 327-333.
Kirsch, L. J. (1996). The management of complex tasks in organizations:
Controlling the systems development process. Organization Science, 7(1),
1-21.
Kirsch, L. J. (1997). Portfolios of control modes and IS project management.
Information Systems Research, 8(3), 215-239.
Kirsch, L. J., Sambamurthy, V., Ko, D.-G., & Purvis, R. L. (2002). Controlling the
information systems development projects: The view from the client.
Management Science, 48(4), 484-498.
Lyles, M. A., & Mitroff, I. I. (1980). Organizational problem formulation: An
empirical study. Administrative Science Quarterly, 25, 102-117.
Malone, T., & Crowston, K. (1994). The interdisciplinary study of coordination.
ACM Computing Surveys, 26(1), 87-119.
Massey, A. P., Hung, Y. C., Montoya-Weiss, M., & Ramesh, V. (2001). When cul-
ture and style aren’t about clothes: Perceptions of task-technology “fit”
in global virtual teams. Proceedings of the 2001 International ACM SIG-
GROUP Conference on Supporting Group Work, September 2001, 207-
213.
Massey, A. P., Montoya-Weiss, M. M., & Hung, Y. (2003). Because time matters:
Temporal coordination in global virtual project teams. Journal of
Management Information Systems, 19(4), 129-155.
Maznevski, M. L., & Chudoba, K. M. (2000). Bridging space over time: Global
virtual team dynamics and effectiveness. Organization Science, 11(5),
473-492.
McGrath, J. E. (1984). Groups: Interaction and performance. Englewood Cliffs,
NJ: Prentice-Hall.
McGrath, J. E., & Hollingshead, A. B. (1994). Groups interacting with technology:
Ideas, evidence, issues, and an agenda. Thousand Oaks, CA: Sage
Publications.
McKinney, E. H., Barker, J. R., Smith, D. R., & Davis, K. J. (2004). The role of
communication values in swift starting action teams: IT insights from
flight crew experience. Information & Management, 41, 1043-1056.
Mintzberg, H. (1979). The structuring of organizations: A synthesis of the
research. Englewood Cliffs, NJ: Prentice-Hall.
Mowshowitz, A. (1997). Virtual organization. Communications of the ACM,
40(9), 30-37.
Munkvold, B. E. (2003). Implementing collaboration technologies in industry:
Case examples and lessons learned. London: Springer-Verlag.
Nunamaker, J. F., Dennis, A. R., Valacich, J. S., Vogel, D. R., & George, J. F.
(1991). Electronic meeting systems to support group work.
Communications of the ACM, 34(7), 40-61.
Orlikowski, W. J. (1993). CASE tools as organizational change: Investigating
incremental and radical change in systems development. MIS Quarterly,
17(3), 1-29.
References 73
Powell, A., Piccoli, G., & Ives, B. (2004). Virtual teams: A review of current liter-
ature and directions for future research. The database for advances in
information systems, 35(1), 6-36.
Project Management Institute. (2004). A guide to the project management body
of knowledge (PMBOK® guide) (3rd ed.). Newtown Square, PA: Author.
Qureshi, S., & Zigurs, I. (2001). Paradoxes and prerogatives in global virtual
collaboration. Communications of the ACM, 44(12), 85-88.
Royce, W. (1998). Software project management – A unified framework. Reading,
MA: Addison-Wesley.
Rutkowski, A.-F., Vogel, D., Bemelmans, T. M. A., & Van Genuchten, M. (2002).
Group support systems and virtual collaboration: The HKNet project.
Group Decision and Negotiation, 11(2), 101-125.
Sarker, S., & Sahay, S. (2002). Information systems development by US-
Norwegian virtual teams: Implications of time and space. Proceedings of
the 35th Annual Hawaii International Conference on System Sciences. IEEE
Press, Volume 1, p. 18.
Schuemmer, T. (2003). Evolving a groupware pattern language. Position paper
for ECSCW2003. Fifth International Workshop on Collaborative Editing.
Helsinki, Finland, September 15, 2003.
Shaw, M. E. (1981). Group dynamics: The psychology of small group behavior
(3rd ed.). New York: McGraw-Hill.
Shenhar, A. J. (1998). From theory to practice: Toward a typology of project
management styles. IEEE Transactions on Engineering Management,
45(1), 33-48.
Stahl, G. (2005). Collaborating with technology: Mediation of group cognition.
Boston: MIT Press.
Suchan, J., & Hayzak, G. (2001). The communication characteristics of virtual
teams: A case study. IEEE Transactions on Professional Communication,
44(3), 174-186.
Turoff, M. (1997). Virtuality. Communications of the ACM, 40(9), 38-43.
Turvey, M. T. (1990). Coordination. American Psychologist, 45(8), 938-953.
Van Ryssen, S., & Godar, S. H. (2000). Going international without going inter-
national. Journal of International Management, 6, 49-60.
Völter, M. (2002). Hope, belief and wizardry – Three different perspectives on
project management. EuroPLoP 2002. Seventh European Conference on
Pattern Languages of Programs, July 3-7, 2002. Irsee, Germany.
Watson-Manheim, M. B., & Belanger, F. (2002). Exploring communication-
based work processes in virtual work environments. Proceedings of the
35th Hawaii International Conference on System Sciences. IEEE Computer

Society Press, Volume 8, p. 272.2.
Watson-Manheim, M. B., Chudoba, K. M., & Crowston, K. (2002).
Discontinuities and continuities: A new way to understand virtual work.
Information Technology & People, 15(3), 191-209.
Weber, M. (1947). The theory of social and economic organizations. New York:
The Free Press.
Yoshioka, T., Herman, G., Yates, J., & Orlikowski, W. (2001). Genre taxonomy: A
knowledge repository of communicative actions. ACM Transactions on
Information Systems, 19(4), 431-456.
Zalesny, M. D., Salas, E., & Prince, C. (1995). Conceptual and measurement
issues in coordination: Implications for team behavior and performance.
Research in Personnel and Human Resources Management, 13, 81-115.
Zigurs, I. (2003). Leadership in virtual teams: Oxymoron or opportunity?
Organizational Dynamics, 31(4), 339-351.
Zigurs, I., & Buckland, B. (1998). A theory of task/technology fit and group
support systems effectiveness. MIS Quarterly, 22(3), 313-334.
Zigurs, I., Evaristo, R., & Katzy, B. (2001). Collaborative technologies for virtual
project management. Academy of Management, Washington, DC.
Zigurs, I., & Kozar, K. (1994). An exploratory study of roles in computer-sup-
ported groups. MIS Quarterly, 4(1), 277-297.
Zigurs, I., & Munkvold, B. E. (in press). Collaboration technologies, tasks, and
contexts: Evolution and opportunity. In D. Galletta & P. Zhang (Eds.).
Human-computer interaction in management information systems:
Applications, Vol. II. Armonk, NY: M. E. Sharpe, Inc.
APPENDIX A
SELECTED TOOLS FOR VIRTUAL

COLLABORATION AND
PROJECT MANAGEMENT
Extent of Support for:
Communication
Other features
Information
Product
Description
Process
Name
ASAP ASAP provides online meetings.

Convoq Presence detection capabilities and
installation-free participation for sched-
uled and ad-hoc meetings. Rich media
including text chat, file transfer, video,
VoIP, annotated screen and presentation
sharing. Internet-based hosted solution.
Brigit Instantly information sharing. Meet in

Conferencing remote locations, share documents,
SMART get feedback. Synchronous, distributed
Technologies conferencing. Integrate with SMART
Inc. boardTM whiteboard. By subscription
or buy and host.
Centra 7 Web-based portal for online meeting

v7.1 support that addresses workflow before,
during, and after live collaboration
sessions. Tracking tools for project
work, such as timesheets, scheduler,
post-meeting summaries. Presentations
with follow-up surveys and polls. Uses
set-up wizards for agenda building and
planning. Interfaces with MS applica-
tions. Outsourced hosting, subscription
ASP service, or ASP/hosted deployment.
75
Communication
Other features
Information
Product
Description
Process
Name
Comotiv Virtual conference room with conversa-

Collaboration tion among all participants. Full video
presents everyone “in person”. Triple
des encryption. Purchase client soft-
ware (self-host) and hosted solutions.
DocuPortal.NET DocuPortal.NET is a company/organi-

DocuPortal AG zation server with collaborative docu-
ment management tools. Quality
management according to ISO 9000
standard. Knowledgebase, catalog
system and reference books, project
management for medium agencies
with simultaneous access for cus-
tomers; intranets; date and group
administration; coordinated document
filing and information; place and time-
independent teamwork. No meeting
capability. Hosted and ASP solutions.
EMC2 Web-based collaborative environ-

Documentum ment. Provides a digital workspace
eRoom 6.0 that allows distributed teams to work
together on content, processes, and
projects. Workflow process from
project workspaces. Supports the
classification of collaborative content
according to corporate taxonomies.
Agenda setting, event scheduler,
project plan, document sharing and
editing, discussion, polling, inbox,
database access, help files, presence
tracking. Hosted solution.
eZmeeting Desktop software application that

allows small groups to simultaneously
review, share, markup and archive
copies of documents. Live online
meetings, real-time telestrator markup,
instant messaging, interactive desktop
viewer, desktop sharing, multi-location
collaboration, presentation tools, inter-
active whiteboarding. Combine
eZmessenger, eZconference, and
eZdesktop to achieve desired function-
ality; hosted solution. Help desk.
Selected Tools fo Virtual Collaboration and Project Management 77
Communication
Other features
Information
Product
Description
Process
Name
Facilitate.com A group support system application

8.5 with idea generation, decision making,
and action planning in face-to-face
and distributed meetings.
Simultaneous brainstorming, anonymi-
ty, polling, voting, prioritization, action
plan, complete recording. Supports
asynchronous collaboration for online
meetings and surveys any time any
place. Self-host or hosted solutions.
FoxSuite Scalable Groupware/Intranet package,

GroupWare combining 25 application modules
DCASoft using a common database. Designed
to run on a web server installed on
Intranet or Internet webserver.
Includes backend database. Control
access and use with passwords and
user authentication. Self-hosted.
GoToMeeting Basic web conferencing application

Citrix to conduct online meetings.
Permissions can be set to allow
screen sharing between participants.
Integrates with Outlook to do sched-
uling. Lacks sophisticated videocon-
ferencing, whiteboarding and VoIP;
but is economical and well suited for
presentations. Most secure meeting
product available, according to Citrix
press release. Hosted solution, Flat
fee w/unlimited monthly usage.
Groove Virtual Allows teams to work together as if

Office V3 they were in same physical location.
Groove Enables users to communicate and
NETWORKS interact directly with one another syn-
chronously or asynchronously. Supports
individual and group interactions.
Presence aware, file sharing, synchro-
nization, project tracking. Advanced
project toolset in professional edition
has full set of meeting tools including
agenda setting, recording, and project
plan integration updates. Server soft-
ware or hosted solutions.
Communication
Other features
Information
Product
Description
Process
Name
GroupSystems Allow team members to work togeth-

er to gather ideas, vote, create action
plans, and track progress using suite
of collaborative tools. Supports both
face-to-face meetings and distributed
meetings with remote participants.
Supports both same-time collabora-
tion and asynchronous anytime appli-
cations. Based on group support
system processes of diverge, converge,
organize, evaluate, and build consen-
sus. Server software or hosted solutions.
GrouputerNet Facilitator-led collaborative program.

Enables structured online communi-
cation for meetings, training, presen-
tations, polling, and eLearning. For
distributed or co-located environ-
ments. Structured working environ-
ment with agenda planning and
enforcement. Business process
authoring tools allow facilitation to
be packaged. Decision-support and
people management features.
GrouputerNet uses group support
system processes for divergence,
convergence, and consensus. Secure
access and encryption. Onsite server
software or hosted solutions.
GroupWise Provides e-mail and scheduling capa-

V 6.5 bilities, including sophisticated mes-
Novell sage filtering and online access and an
instant messaging component called
Novell GroupWise Messenger. Includes
basic document management from
within e-mail and scheduling client;
community collaboration capabilities;
and Novell Virtual Office, which pro-
vides browser-based collaboration tools
such as document sharing, threaded
discussions and delegated administra-
tion. A client notification program
called GroupWise Notify monitors
incoming e-mail and calendar events.
Communication
Other features
Information
Product
Description
Process
Name
LiveLink Web-conferencing and real-time

MeetingZone meeting tool that allows participants
OpenText to collaborate with team members
Corp. anywhere in the world and save con-
tent generated during a meeting in
LiveLink’s knowledge repository for
reference and re-use at a later date.
Automated meeting preparation,
conduct, and follow-up. Spontaneous
collaborative exchanges, distributed
synchronous and asynchronous
capability. Onsite server software or
hosted solutions.
Lotus Notes Provides integrated groupware, Web

& Domino conferencing, instant messaging and
V. 6.5.1, V. 7 document management. Includes
IBM IBM Lotus Team Workplace, for Web
and Notes interfaces to team collab-
oration databases that support docu-
ment sharing, threaded discussions
and workflow. Supports check-in/
checkout and version control.
MeetingPlace Rich-media conferencing solution

Cisco that integrates voice, video, and Web
conferencing capabilities. Deployed
“on network”, behind the firewall.
Integrates directly with private voice
and data networks and enterprise
applications.
MeetingServer Web conferencing solution for serv-

Data ice providers and large enterprises
Connection that want to manage their own web
conferencing service. Incorporates
whiteboard, presentation, applica-
tion sharing, text chat, voting, and
web video.
Communication
Other features
Information
Product
Description
Process
Name
Meeting Web-based provider of networked

Success meetings. Uses non-proprietary deci-
sion support software with a facilitator
operating the system to guide partici-
pants through electronic processes of
brainstorming, reviewing, organizing,
evaluation, and prioritization of ideas,
then developing a plan of action.
Structured process and agenda with
anonymity, group support systems
principles of operation.
MeetingWorks Provides consulting and facilitation

services to streamline collaboration
and software electronic meeting
package to enhance collaboration,
decision-making, and productivity in
facilitated meetings based on group
support systems principles of diverge,
converge, organize, evaluate, and
consensus.
MegaMeeting Offers 100% browser-based video

and Web conferencing. Can host or
attend a conference by opening a
browser. Works with web cameras,
including firewire connected cam-
eras. Includes collaboration tools such
as desktop/application sharing (with-
out the necessity to upload any files)
and remote control technical support.
MS NetMeeting Major components include enterprise

& Exchange e-mail, scheduling and task manage-
Server; Office ment; enterprise instant messaging;
2003 Web conferencing, application sharing
Microsoft and chat; community-based collabora-
tion, document management and
sharing, and threaded discussions.
Client Outlook provides online and
off-line interface to e-mail, scheduling
and tasks.
Communication
Other features
Information
Product
Description
Process
Name
Oracle Provides basic enterprise e-mail fea-

Collaboration tures through a built-in Web inter-
Suite Release 2 face, Web conferencing, voice and
Oracle fax integration, and basic groupware
features, but not instant messaging.
Lacks an e-mail client. The portal
includes document sharing, delegat-
ed administration and polling. Web
Conferencing integrates with
Collaboration Suite to provide Web
conferencing capabilities, including
application sharing, whiteboarding,
presentation multicasting, polling
and integrated chat.
Share360 Groupware suite with applications

Cybozu Corp like Scheduler, WebMail, Cabinet,
Announcements, Project, Web Forms
and more. Provides applications to
communicate and coordinate office
teams or groups; collaborative work
management focus; has meeting
scheduling capabilities but web-
based meetings would require a
web-meeting provider.
Siemens Open, presence-aware, real-time

HiPath communications software suite
Openscape designed to synchronize people and
information to facilitate action or
decision-making. The workgroup
portal is a conferencing environment
that includes control, status, and
monitoring features for user-defined
workgroups and work-group proper-
ties. Instant conferencing, real-time
participant status, document reposi-
tory and viewer, and one-click media
advance to web-conference.
Compatible with all telephony
switches. Server software, user-
deployment.
Communication
Other features
Information
Product
Description
Process
Name
smartMeeting Provides communications and collab-

oration applications. Synchronous
and asynchronous meeting participa-
tion, simultaneous participation,
instant meetings, shared document
retrieval, viewing, and archival, video
streaming, text char, persistent con-
tent, synchs to Outlook calendar for
shared scheduling, shared whiteboard,
user profiles, full administrative con-
trols. Hosted solution for Windows
client plus Internet Explorer.
teamspace Virtual office for teamwork over the

5 POINT AG Internet. Includes creativity and idea
evaluation module that supports
creative problem solving processes
through problem clarification, idea
finding, idea evaluation, and display
of results. Idea finding (brainstorm-
ing) and evaluation is conducted
anonymously and team leader decides
when a stage is complete. Strong
project management orientation.
Hosted or web-server software self-
deployment.
Umeeting Real-time web conferencing and col-

laboration services, including video
conferencing, desktop sharing,
Internet voice and interactive white-
boards. Choice of three moderation
styles (none to very structured), doc-
ument sharing & broadcasting, pres-
ence awareness, multipoint video,
polling and tests, break out sessions,
meeting organizer, and synching
with Outlook calendar and Lotus
Notes. Secure; will run behind cor-
porate firewall. Hosted solution, vary-
ing usage plans and features.
Communication
Other features
Information
Product
Description
Process
Name
WebConferenc Communications platform for con-

es.com ducting collaborative meetings, sem-
inars and presentations. Integrated
audio, video, chat, polling, white-
board, moderation options. Hosted
solution only; Internet-based, distrib-
uted meetings, flat monthly rate.
WebEx Suite of on-demand (pay-per-use)

MeetingCenter web meetings and applications.
Integrates voice, data, and video with
multimedia presentation formats.
Collaboration in real-time, sponta-
neous question-and-answer, docu-
ment sharing and annotation,
product demonstrations. Meeting-
assist services for helping plan,
rehearse, record, and conduct a post-
meeting review. Hosted solution.
WebEx Suite of intranet applications. Includes

WebOffice document manager, web and audio
conferencing, task manager, online
calendar and group scheduling, opin-
ion polls, discussion forums. Monthly
user fees based on components
selected, although web conferencing
module alone is a flat fee. Accessed
via Internet using password. SSL
encryption. Solution is hosted only.
WebIQ Internet-based tool that gathers and

organizes teams with tools for gener-
ating ideas, organize and evaluate
alternatives, analyze numbers, and
create action plan. Agenda creation,
threaded discussion, distributed and
asynchronous meetings. Based on
group support system principles of
diverge, converge, organize, evalu-
ate, and build consensus. Many
tools. Hosted solution.
Sources:
Collaborative Groupware Software, retrieved 14 December 2004 from:
http://www.svpal.org/~grantbow/groupware.html
All other sources used were the Web sites of collaborative software or
collaboration solution providers.
APPENDIX B
INTRODUCTORY E-MAIL TO
FOCUS GROUP PARTICIPANTS
Dear xxx (name of company) team,
Thank you for agreeing to participate in the Virtual Projects Study

and share your ideas in a virtual focus group session. We hope you will
enjoy this experience, and we very much appreciate your time in helping
all of us learn something about the effective management of virtual proj-
ects. This e-mail gives you a preview of what to expect, so that once you
we actually start, you can jump right in.
The virtual focus group will be conducted with WebIQ, a web-based
brainstorming and group decision tool. Later today or early tomorrow,
you will get an e-mail from the WebIQ folks with the URL and your per-
sonal login and password for our session. KEEP THAT MESSAGE, but
don’t start yet. We won’t start the actual session until the middle of this
week. You will get another e-mail from us letting you know when to login
and start brainstorming.
The purpose of this study is to get your views on the practices
that contribute to the effectiveness of virtual projects. The agenda of
the WebIQ session has four parts: (1) Beginning Questionnaire, (2)
Brainstorming Question 1, (3) Brainstorming Question 2, and (4) Closing
Questionnaire.
The Beginning Questionnaire will ask you to describe and answer
questions about a specific virtual project in which you participated with-
in the last twelve months. By virtual project, we mean any project that
consists of team members who are distributed geographically. Virtual
project team members could also be from different organizations, with
85
different cultures, or working in different time zones. But the key is that
because of the geographic dispersion, a virtual team has to rely on com-
munication technologies like e-mail or intranets or chat rooms to achieve
project goals.
The two Brainstorming questions are about the specific virtual proj-
ect that you described in the Beginning Questionnaire. You will enter
your own ideas in response to the questions, and see and be able to com-
ment on the ideas of other participants. The Closing Questionnaire just
asks a few questions about demographics.
All this will take place during a 72-hour window. We will e-mail
you to let you know when to login and get started (expect that e-mail
on Wednesday of this week). Once you complete the Beginning
Questionnaire, you can login in as many times as you want to brainstorm
ideas during the 72-hour window. When you are done with all your com-
ments and ideas, you should fill out the Closing Questionnaire.
The time period for brainstorming is spread over 72 hours in order
to accommodate your schedule. We expect you might take a total time of
one to two hours of input. But we hope you will log in often and enter
ideas and comment on new ideas that others have entered in the mean-
time. Your anonymity is ensured and your name or company name will
not be used in any way to report any of the data.
Attached to this message is a letter about the study, informing you of
your rights as a participant in a research study conducted through UNO.
The study has been approved by the Institutional Review Board. Once
again, thank you and please e-mail either one of us if you have any ques-
tions at any time during the study.
Best regards,
Ilze Zigurs and Deepak Khazanchi
APPENDIX C
COVER LETTER APPROVED

BY INSTITUTIONAL
REVIEW BOARD
Dear Participant,
We are studying best practices in virtual project teams by conducting

focus groups in several companies in the Omaha area. We are asking your
help in the project by participating in a focus group session. Your partic-
ipation will take approximately one-and-a-half to two hours.
All responses will be confidential. Most results will be reported at an
aggregate level. In all cases, your identity will be made anonymous in any
reporting of results. You are free to withdraw your consent to participate
and may discontinue your participation in the study at any time without
consequence.
There are no anticipated risks, compensation or other direct benefits
to you as a participant in this study. However, there will be indirect ben-
efits. In particular, we will share results with you and other people who
could benefit from them in the improvement of virtual project manage-
ment in your organization.
If you have any questions about this research project, please contact
us. Questions or concerns about research participants’ rights may be
directed to the Institutional Review Board, 402-559-6463.
The information from this study may be published or presented at
meetings, but your identity will not be revealed.
Thanks for your participation in this project, which will help to
improve project management processes in virtual teams.
Sincerely,
Ilze Zigurs and Deepak Khazanchi,
PKI 284E, University of Nebraska at Omaha, 402-554-3182
87
APPENDIX D
QUESTIONNAIRES FOR
FOCUS GROUPS
BEGINNING QUESTIONNAIRE
Instructions: Please answer all questions to the best of your knowledge.
The first question asks you to briefly describe a virtual project that you
worked on within the last year, and the remaining questions are about that
specific project. Once you get to the end, click “Submit” to finish. If you
want to pause, click “Save” and then continue from there. Keep scrolling
down to answer all questions. After you have answered all questions and
clicked “Submit,” you will be taken back to the agenda. When you are back
at the agenda, go to Brainstorming Question 1 and start entering ideas.
1. Briefly describe the purpose of the virtual project in which you par-
ticipated during the last twelve months. This project will be the basis
for the ideas that you enter in the next agenda item. The rest of the
questionnaire asks more detailed questions about this project.
2. What was your role in the project?

__ Project Manager
__ Developer/Programmer/Software Engineer
__ Business Analyst
__ Domain Expert
__ Business Manager
__ Other, please specify _____________________
89
3. What was the size of your project team?

__ Small (up to 5 persons)
__ Medium (6 to 15 persons)
__ Large (greater than 15 persons)
4. What was the planned schedule for the project?

__ Less than 6 months
__ 7 to 12 months
__ Greater than 12 months
5. What was the approximate budget for the project in US dollars?

___________
6. Overall, the project was completed as scheduled.

__ Strongly Agree
__ Agree
__ Neutral
__ Disagree
__ Strongly Disagree
7. Overall, the project was completed within budget.

__ Strongly Agree
__ Agree
__ Neutral
__ Disagree
8. Overall, the project met its goal and specified requirements.

__ Strongly Agree
__ Agree
__ Neutral
__ Disagree
9. Overall, the project was a success.

__ Strongly Agree
__ Agree
__ Neutral
Questionnaires for Focus Groups 91
__ Disagree
10. What was the greatest time difference between you and other
project team members?
__ Time zone difference was less than 3 hours
__ Time zone difference was between 4 and 9 hours
__ Time zone difference was greater than 10 hours
11. Which phrase best describes the cultural background of the

__ Same culture (homogeneous)
__ Different culture (heterogeneous)
__ Different but team members had similar cultural traits or
value systems (hybrid)
12. Which phrase best describes the language differences prevalent

between the team members participating in the project?
__ Same language (homogeneous)
__ Different languages—for example, U.S. and France
(heterogeneous)
__ Same language, but no shared meaning—for example,
U.S. and East Indian English (hybrid)
13. Which phrase best describes the proficiency of project team

members with virtual team technology?
__ Novice (first-time users)
__ User (used technology previously and familiar with main
concepts)
__ Expert (completely familiar with the technology)
14. Which statement best describes the number of organizations or

firms represented by project team members?
__ Team members represented a single organization
(intra-organization)
__ Team members represented two different organizations
__ Team members represented more than two different
organizations
15. Which phrase best characterizes the overall scope of the project?
__ Very large
__ Somewhat large
__ Medium
__ Somewhat small
__ Very small
16. Which phrase best characterizes the overall complexity of the

project?
__ Extremely complex
__ Somewhat complex
__ Average complexity
__ Somewhat simple
__ Extremely simple
17. Which phrase best characterizes the programmatic risk of the

project (e.g., schedule, cost, political issues)?
__ Very high risk
__ Somewhat risky
__ Average or medium risk
__ Low risk
__ Very low risk
18. Which phrase best characterizes the technical and engineering risk
of the project (e.g., requirements, security, performance, safety)?
__ Very high risk
__ Somewhat risky
__ Low risk
__ Very low risk
19. Which phrase best characterizes the quality risk of the project
(e.g., implementation, maintenance, software engineering)?
__ Very high risk
__ Somewhat risky
__ Low risk
__ Very low risk
20. Which phrase best characterizes the logistical risk of the project
(e.g., making resources available when and where needed)?
__ Very high risk
__ Somewhat risky
__ Low risk
__ Very low risk
21. Which phrase best characterizes the deployment risk of the

project (e.g., training, system integration)?
__ Very high risk
__ Somewhat risky
__ Low risk
__ Very low risk
22. Which phrase best characterizes the overall risk of the project?
__ Very high risk
__ Somewhat risky
__ Low risk
__ Very low risk
23. Which phrase best characterizes the availability of historical

knowledge needed to conduct the project’s activities?
__ Knowledge was explicit
__ Knowledge was implicit
__ Neither of the above, please specify _______________
24. Which phrase best characterizes the level of innovation inherent

in the project?
__ Extremely innovative project (brings with it radical change)
__ Somewhat innovative
__ A mix of innovation and traditional
(brings with it incremental change)
__ Somewhat traditional
__ Extremely traditional project (little or no change)
25. What was the gender composition of the project team?

__ Female-dominated (more than 75% members are females)
__ Male-dominated (more than 75% members are males)
__ Mixed
26. Which phrase best describes the degree of resources available for
the project?
__ Resources where redundant at each site
__ Resources where complimentary at each site
__ Other, please specify ____________
27. Which phrase best describes the personality of a majority of the

__ Extremely homogeneous
__ A mixture of personality groups
__ Extremely heterogeneous
28. What was the dominant managerial challenge on this project, that
is, what was the one major thing that the team had to pay atten-
tion to during the project?
29. How often did you personally use video conferencing (room
and/or desktop) to work with team members on the project?
__ Never
__ Seldom
__ Moderately often
__ Frequently
__ Almost always
30. How often did you personally use fax to work with team members
on the project?
__ Never
__ Seldom
__ Moderately often
__ Frequently
__ Almost always
31. How often did you personally use email to work with team mem-
bers on the project?
__ Never
__ Seldom
__ Moderately often
__ Frequently
__ Almost always
32. How often did you personally use voice mail to work with team
members on the project?
__ Never
__ Seldom
__ Moderately often
__ Frequently
__ Almost always
33. How often did you personally use the telephone to work with
team members on the project?
__ Never
__ Seldom
__ Moderately often
__ Frequently
__ Almost always
34. How often did you personally use Web-based intranet tools
(example: groove.net) to work with team members on the project?
__ Never
__ Seldom
__ Moderately often
__ Frequently
__ Almost always
35. How often did you personally use conference calling to work with
__ Never
__ Seldom
__ Moderately often
__ Frequently
__ Almost always
36. How often did you personally use face-to-face meetings to work
with team members on the project?
__ Never
__ Seldom
__ Moderately often
__ Frequently
__ Almost always
37. How often did you personally use an electronic meeting system
(e.g., WebIQ, GroupSystems, Facilitate.com) to work with team
members on the project?
__ Never
__ Seldom
__ Moderately often
__ Frequently
__ Almost always
38. How often did you personally use instant messaging to work with
__ Never
__ Seldom
__ Moderately often
__ Frequently
__ Almost always
39. How often did you personally use simultaneous document editing
to work with team members on the project?
__ Never
__ Seldom
__ Moderately often
__ Frequently
__ Almost always
40. How often did you personally use group calendaring to work with
__ Never
__ Seldom
__ Moderately often
__ Frequently
__ Almost always
41. How often did you personally use distributed project

management tools to work with team members on the project?
__ Never
__ Seldom
__ Moderately often
__ Frequently
__ Almost always
42. How often did you personally use a workflow system to work with
__ Never
__ Seldom
__ Moderately often
__ Frequently
__ Almost always
43. How often did you personally use a shared whiteboard to work
with team members on the project?
__ Never
__ Seldom
__ Moderately often
__ Frequently
__ Almost always
44. How often did you personally use any other technologies not
mentioned in the above questions to work with team members on
the project?
__ Never
__ Seldom
__ Moderately often
__ Frequently
__ Almost always
CLOSING QUESTIONNAIRE
Instructions:
Please answer all questions. Once you get to the end, click “Submit” to fin-
ish. If at any time you want to pause, click “Save” and then continue from
there. Keep scrolling down to answer all questions. After you have
answered all questions and clicked “Submit,” you will be taken back to the
agenda. At the agenda, you can logoff from the session.
1. Gender (check one): Female __ Male __

2. How many years of project experience do you have?
3. How many years of higher education (after high school)
have you had?
4. What industry is your firm in?
5. What is the size of your company in # of employees and/or
annual revenue?
6. What is the scope of your firm (global, national, regional)?
Thank you for your participation.

Patterns Virtual Projects

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Patterns Virtual Projects

Încărcat de

Drepturi de autor:

Formate disponibile

PEVP_interior_012506.

qxp 1/25/06 1:16 PM Page i

chapter head here i

Executive Overview vii

3.3.1. Control – cybernetic view 24

he management of virtual projects is fundamentally different from

he management of virtual projects is fundamentally different

2 Patterns of Effective Management of Virtual Projects

The concept of virtuality has become so embedded in the popular con-

4 Patterns of Effective Management of Virtual Projects

defined as a management approach that defines explicit functional

Key Dimensions of a Virtual Project Typology 5

2.1.2. Integrated definition of virtuality

Building on these different views and for purposes of this monograph, we

A common problem in the early days of research on computer-support-

6 Patterns of Effective Management of Virtual Projects

2.2.2. Integrated definition of technology

Key Dimensions of a Virtual Project Typology 7

of technology is how well it stands up to new technical developments. We

Dimension Example Elements

Communication • Simultaneous input

Process Structure • Agenda setting

Task Analysis • Information gathering

Table 1 Examples of Elements for Each Dimension of Technology

8 Patterns of Effective Management of Virtual Projects

Our definition specified that the technology should consist of inte-

2.3. Project Characteristics

Key Dimensions of a Virtual Project Typology 9

10 Patterns of Effective Management of Virtual Projects

and show key differences in how we might approach a typology of proj-

2.3.2. Integrated characterization of projects

We present three fundamental dimensions of project characteristics as

Key Dimensions of a Virtual Project Typology 11

Factor Potential Anchors

Team size Small vs. medium vs. large

Culture Homogeneous vs. hybrid vs. heterogeneous

Language Homogeneous vs. hybrid vs. heterogeneous

Gender Female-dominated vs. male-dominated vs.

Personal Introvert-sensing vs. introvert-intuiting vs.

Resources Redundant vs. complementary at each site

Knowledge Explicit vs. tacit (Gassmann & Von Zedtwitz,

Table 2 Factors Affecting Project Complexity

Factor Potential Anchors

Duration Short-term vs. medium-term vs. long-term

Innovation Incremental vs. radical (Gassmann & Von

Scope Systemic vs. autonomous (Gassmann & Von

Multiplicity Single vs. multiple (Evaristo & Munkvold,

Table 3 Factors Affecting Project Scope

12 Patterns of Effective Management of Virtual Projects

Factor1 Potential Anchors

Programmatic Certain vs. uncertain

Technical and engineering Unambiguous vs. ambiguous

Quality (Implementation, Satisfactory vs. unsatisfactory

Logistical (Reliability) Reliable vs. unreliable

Deployment Direct vs. cutover vs. phased

Table 4 Factors Affecting Project Risk

2.4. Patterns and Pattern Theory

Key Dimensions of a Virtual Project Typology 13

14 Patterns of Effective Management of Virtual Projects

wrong responses to project management problems.

Key Factors for Managing

p to this point, we have defined the key concepts of virtuality and

16 Patterns of Effective Management of Virtual Projects