See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/3076915

Leadership of information system development projects

Article  in  IEEE Transactions on Engineering Management · June 2006

DOI: 10.1109/TEM.2006.872245 · Source: IEEE Xplore

CITATIONS READS
82 766

2 authors:

Samer Faraj V. Sambamurthy

McGill University Michigan State University
83 PUBLICATIONS   8,985 CITATIONS    113 PUBLICATIONS   7,179 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

design theory and management View project

All content following this page was uploaded by Samer Faraj on 04 November 2014.

The user has requested enhancement of the downloaded file.

238 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 53, NO. 2, MAY 2006
Leadership of Information Systems
Development Projects
Samer Faraj and V. Sambamurthy
Abstract—How best to lead an information systems project
team continues to be an open issue. For three decades, the re-
search literature has contrasted between the leadership of the
“chief programmer” led team to that of the “egoless” software
team with little clarity as to what is appropriate leadership and
under what circumstances. Software project teams, like other
knowledge teams, are characterized by distributed expertise, the
reliance on methodologies, high levels of collaboration, as well as
the need to meet the expectations of a diverse set of stakeholders.
We propose a theoretical model of information systems project
team leadership that focuses on empowering and directive lead-
ership practices and investigate whether this leadership is more
effective than the use of traditional coordination mechanisms;
we also test whether these relationships are moderated by fac-
tors such as task uncertainty or professional experience. We test
this model using data from 69 software development teams. Our
results indicate that empowering leadership has an important
impact on team performance but only under conditions of high
task uncertainty or team expertise.
Index Terms—Project management, software development,
team leadership.
I. INTRODUCTION
T HE EFFECTIVE management of information systems (IS)
projects continues to be a critical organizational challenge
and imperative, particularly in order to ensure integration be-
tween information technologies and business priorities and ac-
tivities [1]. Estimates from the Project Management Institute
suggest that U.S. firms spend $2.3 trillion on IS projects each
year and that the global project spending might reach $10 tril-
lion [2]. However, most organizations continue to find that the
management of these projects is difficult [3]. Over a quarter of
large IS projects are never completed [4], and a vast majority
of IS projects are not completed on time or on budget. The av-
erage IS project is more than a year late and costs twice its ini-
tial estimate [5]. And of the projects that are completed, some
three quarters of them are considered operating failures that do
not function as intended [3]. Recently, the failure of high-profile
projects such as the Confirm reservation system [6], the Denver
International Airport automated baggage handling system [7],
Manuscript received October 1, 2004; revised April 1, 2005 and July 1, 2005.
Review of this manuscript was arranged by Special Issue Department Editors
R. T. Watson and E. Karahanna.
S. Faraj is with the R. H. Smith School of Business, University of Maryland,
College Park, MD 20742 USA (e-mail: sfaraj@rhsmith.umd.edu).
V. Sambamurthy is with the Eli Broad College of Business, Michigan State
University, East Lansing, MI 48824 USA (e-mail: sambamurthy@bus.msu.
edu).
Digital Object Identifier 10.1109/TEM.2006.872245
0018-9391/$20.00 © 2006 IEEE
or the IRS system update [8] seem to indicate that IS project
problems are increasingly in the public eye and can cost hun-
dreds if not billions of dollars. Therefore, improving the pro-
ductivity and quality of IS projects is important. While early ap-
proaches were focused on the discovery of better methodologies
and tools (JAD, client-server, object orientation, CASE tools,
etc.), there is a growing realization that IS projects are charac-
terized by challenges in communication, coordination, learning,
and negotiation [9]–[11]. Therefore, examinations of the effec-
tiveness of IS projects must include an understanding of the de-
velopment process and “peopleware” [12]–[15].
Teams are the fundamental organizational unit through which
IS projects are executed. A team structure brings together busi-
ness and process knowledge and the requisite design and pro-
gramming skills. However, three challenges characterize the ef-
fectiveness of IS project teams. First, knowledge required for
the completion of IS project tasks is distributed across team
members [9]. IS project teams must discover effective ways of
collaboration, knowledge sharing, and problem solving to tap
the expertise of the team members [16]. Second, IS projects re-
quire a portfolio of control strategies, including a combination
of formal and informal modes of control [17]. Expertise is re-
quired in knowing how to exercise the appropriate combinations
of control strategies during the duration of the project. Finally,
IS projects are characterized by varying levels of task uncer-
tainty and coordination challenges. As a result, the project teams
must be capable of dealing with the resultant ambiguity of their
project tasks [18].
Leadership of IS projects is an important factor contributing
to the success of IS projects [19]. Project leaders are formally
vested with the authority to guide, monitor, and direct the work
of the other members of the project team. They must be well
versed in how to select appropriate control strategies to guide
their projects [11]. At the same time, they must apply a means
of motivating their team members to collaborate and engage in
problem solving. What leadership practices are likely to impact
the success of IS projects? Though there is a vast array of re-
search on leadership behaviors and their impacts, research is
still needed on the exercise of leadership in IS project teams for
several reasons. First, most studies of leadership have been in
broader organizational contexts, unlike focused work contexts,
such as IS development. Second, IS projects represent knowl-
edge work contexts, where individual team members bring spe-
cific slices of expertise and attempt to integrate their expertise
in determining the scope of the project, how to manage it effec-
tively and efficiently, and how to satisfy stakeholder expecta-
tions. Traditional styles of leadership which are more directive
FARAJ AND SAMBAMURTHY: LEADERSHIP OF INFORMATION SYSTEMS DEVELOPMENT PROJECTS
and hierarchical in nature, because they delineate clear lines of
leadership control, might not be very effective in such contexts
[46]. Studies are needed about the exercise of leadership in such
work contexts. Finally, with the growing salience of IS projects,
specific studies of leadership are needed in this important do-
main of practical interest and economic value creation.
The goal of this paper is to answer two core research ques-
tions: 1) What types of team leadership behaviors influence IS
project team performance? and 2) Under what circumstances
are specific leadership behaviors more effective? We propose
a model to investigate the effects of alternative leadership be-
haviors on the performance of project teams. In particular, we
test whether their impacts are moderated by task uncertainty and
professional experience. The next section of this paper presents
a review of the literature of IS development and develops a
conceptual framework. Then, we describe the methodology for
the study. Finally, we present our findings and discuss their
implications.
II. THEORY
A. Research on IS Development Processes
A variety of theoretical approaches have framed investiga-
tions about the performance of IS development teams. Early re-
search efforts identified individual level human factors that af-
fect outcomes, such as how individuals generate, understand,
and debug small programming problems. Utilizing laboratory-
based investigations of how people generate, understand, and
debug small programs, this research has formed the basis for
the human side of software engineering (see [20] and [21] for a
review of this literature). The key finding of these studies was
that large differences (up to a factor of 100) in performance can
occur between individual programmers working with the same
task. As a result, some have concluded that the most effective
way to improve IS project performance is to simply use individ-
uals with superior programming abilities [22], [23].
Field studies of IS development have emphasized team
processes. Robey et al. [24] showed that participation and in-
fluence are linked to increased conflict and conflict resolution.
Other studies have shown that user-developer problems have
their bases in interdepartmental political conflict [25], [26]. A
number of studies have targeted team control and found that
outcome measurability and a combination of high-managerial
outcome control and high team behavioral controls lead to better
team outcomes [11], [17], [27]. Other IS development studies
have demonstrated the importance of within-team knowledge
acquisition and sharing processes [9], [28]. More recently,
Guinan et al. [14] found that task-related group processes
were significantly more important in predicting IS project team
performance than either team factors or usage of automated
tools. These findings were confirmed by a study of 69 software
teams where expertise coordination processes were linked to
stakeholder ratings of performance [16]. In conclusion, though
a number of field studies have demonstrated the importance of
team processes, few researchers have specifically focused on
the role of the leader in creating or sustaining these important
team processes.
239
B. Traditional IS Project Team Organizing
An IS project team has the following characteristics: 1) it is
cross functional; 2) its members bring multidisciplinary knowl-
edge; 3) its work is characterized by time pressures; and 4) out-
comes must be adaptive to changing stakeholder expectations
and business and technology conditions. The team must find
ways of integrating distributed expertise. Membership is fluid,
and new members are integrated into the software development
task, as needed. The team members perform highly interdepen-
dent and often concurrent tasks. Due to their highly intellective
tasks and the enormous amount of coordination that must take
place, particularly for the sharing and integration of knowledge,
IS project teams are unique and different from other teams in
action in organizations [16], [29].
How best to lead a software team has remained an evolving
issue. Traditionally, software teams were structured based on
seniority and experience, with a senior programmer serving as
leader. Authority and lines of responsibility were clear and easy
to understand. Each junior programmer was evaluated by a su-
perior. Competition among team members was seen as a nat-
ural occurrence and is believed to motivate individuals to work
harder. A widely used traditional form is that of the chief pro-
grammer-led team. A chief programmer produces the critical
core of the system and specifies, evaluates, and integrates all
other programming tasks for the system [30]. As team leader,
the chief programmer has the highest level of expertise and thus
is better able to divide the work, assign roles, and help the other
team members. The leader is basically responsible for all posi-
tive and negative outcomes but also has significant power to con-
trol and direct the team as needed. Brooks draws a positive par-
allel between a software team thus structured and a surgical team
with the chief programmer playing the role of surgeon [12].
An alternative to the chief programmer approach is the ego-
less programming team. It reflects a more egalitarian philosophy
of programming proposed by Weinberg [31] in order to remedy
the deficiencies of traditional team governance. The team is de-
centralized and programmers communicate freely with others
on difficult tasks [32]. Expertise is distributed, collaboration is
encouraged, and task assignments are negotiated by the whole
team.
Clearly, each of these team governance structures leads to dif-
ferent emergent roles among team members and a different set
of interrelations. A chief programmer structure assumes low in-
terdependence, coordination through the hierarchy, and does not
reward teamwork. The centralization of decision making and
communication leaves the team vulnerable to leader saturation
(e.g., [33]). It may not be appropriate for complex tasks as it
assumes that a leader’s technical skill goes hand in hand with
effective communication ability [32]. Conversely, an egoless de-
velopment team is likely to engage in a richer set of lateral co-
ordination patterns. Basic management activities such as task
assignments, goal direction, and decision making are likely to
be more diffuse and take longer [21].
Most firms have tried different forms of organizing that cover
variations of the archetypal team structures mentioned above.
However, the question of how to organize and lead an IS project
team remains unanswered. Research is needed about the impact
240
of team leadership on performance. One reason for this dearth
of knowledge is that the process of leading a team on a long du-
ration, high-complexity, and interdependent task cannot be re-
duced to a simple categorization of leadership acts. Rather, the
type of project task, the resource constraints, and the nature of
membership on the team all matter and affect the kind of ac-
tivities and behaviors that a leader chooses to engage in. Recent
advances in the managerial leadership literature offer promising
new conceptualizations.
C. Directive and Empowering Leadership
Team leadership has emerged as a significant element in-
fluencing team effectiveness in today’s environments that re-
quire fast decision making based on sometimes inaccurate, un-
available, or equivocal information [34], [35]. Leaders of IS
project teams can impact team outcomes in a number of ways.
First, a leader can encourage high levels of individual perfor-
mance from the team members [36]. Second, a leader can en-
courage teamwork in order to promote expertise coordination
among members, an important predictor of team performance
[16]. Third, a leader can challenge team members intellectu-
ally and stimulate them intellectually to develop new ways of
looking at problems and thus speed up the development process
[37]. Finally, involving team members in goal setting is likely to
generate increased commitment, acceptance of team goals, and
the activation of higher order needs [36], [38].
Since software teams rely on distributed expertise and they
work on tasks that are highly interdependent and require close
coordination, their team leaders require unique skills and
a potentially high degree of technical involvement. Thus, a
premium is placed on leader behaviors rather than appeals to
emotion and values (e.g., as in transformational leadership).
Empowering leadership and directive leadership form the
opposite ends of this activity-focused continuum. Empowering
leaders encourage an active participation from followers or
team members. In contrast, directive leaders typically do not
expect or allow team members to take initiative but provide
expertise, control, and guidance.
Directive leaders centralize decision making and personally
direct team activities. They expect team members to follow their
commands and directions [39]–[41]. These behaviors are called
“directive.” Theoretically, this type of leadership is similar to
the autocratic leadership identified in Vroom and Jago’s partic-
ipative leadership framework [42], [43] and directive leadership
in path-goal theory [44], [45]. A directive leader corresponds
to the image of the traditional boss who relies on a position of
power to autocratically lead and sometimes sanction subordi-
nates. Such a leader uses direction, command, assigned goals,
instruction, and reprimand as the primary mechanisms to influ-
ence subordinate behavior. Directive leadership has been advo-
cated in knowledge work because it offers needed structure for
intrinsically unstructured work [46].
A directive leader may benefit an IS project team by man-
aging coordination and control. A directive leader assigns tasks,
controls the budget, manages the schedule, and coordinates in-
dividual output integration, all of which are demanding tasks
that a typical team member may not have time or expertise to
IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 53, NO. 2, MAY 2006
do. The leader may also buffer the team from user demands by
managing team boundaries. Typically, a team leader tends to be
more experienced than other team members in how to control
and coordinate the activities of the team members, manage re-
sources, and may have already demonstrated technical excel-
lence or a deep understanding of user domain. A recent study
of 66 medium-sized software development projects found that
leaders’ active involvement in managing team members is posi-
tively associated with higher team performance [14]. The role of
the leader is essential because team members have to overcome
an often fluid set of requirements, interface with each others’
work and expertise, and integrate their various efforts into a co-
herent whole. Thus, we propose the following.
Hypothesis 1a (H1a): Directive leadership is positively
related to team performance.
Alternatively, IS project teams may also benefit from an
empowering leader. An empowering leader consults with
and makes joint decisions with team members and delegates
responsibilities to team members. Manz and Sims [36], [47]
have proposed empowering leadership as a participative and
self-management focused form of leadership. The empowering
leader encourages team members’ active participation and
self-leadership. The roots of empowering leadership are based
on theoretical perspectives such as the supportive leadership
behavior of path-goal theory [44], [45], the decision procedures
identified in the participative leadership framework [42], [43],
social cognitive theory [48], and the participative aspects of
goal setting theory (e.g., [49]). An empowering leader encour-
ages followers to actively provide input, participate in team
decisions, and display initiative. An implication of empowering
leadership is that much of the decisions and control processes
that traditionally had been the prerogative of the team leader are
now shared with the team. An empowered team will actually
share in team leadership. Since team empowerment can be
more time consuming, it is best applied to knowledge teams
engaged in complex work where tasks are highly interdepen-
dent or require high levels of creativity [35], [37]. Empowered
leadership can enhance team performance by allowing mem-
bers room for creativity while encouraging coordination and
sharing of expertise. Such leadership allows team members to
collectively take responsibility for team performance. In the
type of knowledge work that characterizes software develop-
ment, empowered leadership might provide the balanced levels
of autonomy and control necessary for effective performance.
Therefore, we propose the following.
Hypothesis 1b (H1b): Empowering leadership is posi-
tively related to team performance.
D. Moderating Role of Professional Experience and Task
Uncertainty
Software development teams experience different levels of
task uncertainty and bring together varying levels of profes-
sional expertise to their tasks. Since software development is
knowledge intensive, highly interdependent, and requires a high
degree of coordination, variations in the levels of task uncer-
tainty or professional experience might impact the degree to
FARAJ AND SAMBAMURTHY: LEADERSHIP OF INFORMATION SYSTEMS DEVELOPMENT PROJECTS
which the teams experience pressures for effective communi-
cation, collaboration, and problem solving. As a result of these
varying pressures, we propose that the effects of leadership on
performance might be moderated by task uncertainty and pro-
fessional experience.
Leadership research has identified a number of situational as-
pects (e.g., task environment and organizational characteristics)
and team characteristics (e.g., skills and professionalism) that
moderate the effects of managerial leadership [50], [51]. Vroom
[43] emphasizes forceful action in situations where timing of
decisions is critical. Under such circumstances, a leader should
make decisions that at other times would be delegated to team
members. The path–goal theory of leadership (e.g., [32]) sug-
gests that directive leadership is less useful when followers are
more experienced. Finally, Vroom’s normative decision making
theory [42] also suggests that subordinate participation is more
appropriate when subordinates possess the information required
to complete the task. Thus, a contingency perspective on lead-
ership of software teams appears warranted.
In her study of how software development teams utilize
control strategies to monitor and direct their work, Kirsch
[11] found that knowledge of the IS development process and
tasks is a critical factor. Knowledgeable teams are able to
define their activities, structure their work, monitor their task
accomplishment, and manage key stakeholders (see also, [17]).
In other words, when team members have significant levels of
professional experience with software development, they are
more likely to possess relevant expertise and valuable experi-
ence on how to manage their project activities. For such teams,
an empowering leadership approach might be more appropriate
since members may need less direct control and coordination
and possibly possess as much relevant task expertise as the
team leader. In contrast, when teams have low professional
experience, a directive leadership might be more appropriate
because the members look to the leader to provide needed
directions and guidance about their work processes. Therefore,
we expect that the level of professional experience will mod-
erate the effects of both directive and empowering leadership
on performance. Therefore, we propose the following.
Hypothesis 2a (H2a): Empowering leadership will make
a greater contribution to team performance when profes-
sional experience is high than when it is low.
Hypothesis 2b (H2b): Directive leadership will make
a greater contribution to team performance when profes-
sional experience is low than when it is high.
Similarly, IS project teams face different levels of uncertainty
about their tasks. Sometimes, software teams face tasks of low
analyzability (that is, few objective procedures are available
to resolve problems) and high variety (occurrence of new and
unexpected events during the task completion process). Task
uncertainties refer to challenges faced by the team about how
to structure their activities, coordinate actions of the different
members, and apply the appropriate control strategies [22],
[23], [52], [53]. Faraj et al. [18] found that task uncertainty is a
significant barrier to the effectiveness of software development
teams, especially if it is not managed well. When teams face
241
high levels of task uncertainty, they have to make sense of
their tasks, improvise their work processes, and adjust how
they make progress toward agreed upon goals for the software
project. Under such conditions, the ability and willingness
of the team members to engage in cumulative sense-making
and collaboration is important. An empowering leadership
approach will be more effective because it solicits ideas and
inputs from team members and allows them to participate in
the management of the teams’ activities. However, when task
uncertainty is low, a well-structured and routinized approach
toward the management of the team’s activities will be ap-
propriate [43]. Consequently, a directive leadership approach
will be suitable. Hence, we anticipate that task uncertainty will
moderate the impact of the alternative leadership approaches
on performance.
Hypothesis 3a (H3a): Empowering leadership will make
a greater contribution to team performance when task un-
certainty is high than when it is low.
Hypothesis 3b (H3b): Directive leadership will make a
greater contribution to team performance when task un-
certainty is low than when it is high.
E. Traditional Sources of Influence of IS Project Team
Performance
Although our focus is on leadership, we recognize that other
team and task characteristics are certainly important. Team size
could be an obstacle to team performance, a finding that has con-
sistently appeared in the software development literature due to
the diseconomies of scale, exploding complexity, and exponen-
tially increasing project interactions that characterize software
development [4], [12], [54]. Therefore, we use team size as a
control variable.
A second influential factor is administrative coordination, de-
fined as processes that manage resource interdependences. Ad-
ministrative coordination has been shown in previous research
to affect performance [53], [55]. Following Faraj and Sproull
[16], we define administrative coordination as formal or pre-
specified mechanisms used to assign tasks, allocate physical and
economic resources, manage resource dependencies, and inte-
grate outputs. These mechanisms include budgets, staffing ta-
bles, critical path analysis, milestones, inspections, and review
meetings, etc. The use of administrative coordination mecha-
nisms may be independent of leadership practice and thus could
impact team performance by improving work processes.
Fig. 1 provides a graphical representation of our theoretical
model.
III. METHOD
A. Sample
Data on IS projects were collected from the applications de-
velopment division of a large high-technology firm specializing
in software development. This very large division develops ap-
plication software for some internal clients but primarily for
commercial clients. Senior management approved the study, and
all key regions and divisions of the firm participated. We se-
lected IS project teams from a variety of industries and types of
242
Fig. 1. Theoretical model.
application. We selected teams from across the country to max-
imize geographic diversity but chose those involved in business
applications development to keep the task comparable. We also
limited ourselves to teams ranging from 4 to 15 full-time mem-
bers in order to control for the different dynamics and processes
that characterize very small or large teams. Finally, we chose
teams that had completed their requirements definition stage in
order to eliminate teams that were still in formation or struggling
to define their task. We did not include teams that had completed
their projects in order to avoid retrospection bias.
B. Respondents
Two complementary approaches were used for gathering the
data. First, data were gathered directly from the team members.
These data pertained to all of the independent, moderator, and
control variables in our model. Each team member was pro-
vided with a survey instrument along with a stamped envelope
to return the survey directly to the researchers. The instrument’s
cover page prominently guaranteed individual and team level
confidentiality. Further, data on team performance were gath-
ered through a survey of two project stakeholders, one from the
IS and the other from the client organization. These respondents
provided an overall and exogenous view of team performance.
These stakeholders were senior managers who were knowledge-
able about the team and its work and were both affected by
the outcome of the project and were capable of affecting the
team’s performance. Previous research has shown that subjec-
tive assessments of effectiveness provided by knowledgeable
managers have a high level of convergence with other objective
measures of performance [56]. The stakeholders were identified
by the team and assessed for appropriateness by the manager in
charge of the study.
Responses were received from 13 different sites in the U.S.,
including all the organization’s key regions and several indepen-
dent sites. A total of 333 respondents from 69 teams participated
in the study. In addition, we collected ratings of these teams
from 135 stakeholder respondents. Nine out of 78 teams in the
sample did not participate or complete the study (the projects
were cancelled or the managers changed during the study pe-
riod), for a team-level response rate of 88%. The data collection
from team members took place during the coding phase (after
IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 53, NO. 2, MAY 2006
requirements analysis and design, but prior to implementation).
However, we collected team performance ratings from the stake-
holders at the end of the project since stakeholders are usually
unable to assess project outcomes until implementation.
C. Demographics
Approximately one third of the team respondents were fe-
male. The mean age of the respondents was 39 years. They
had almost 12 years experience in the software field, with al-
most all of them (11 years) spent at the current firm. A ma-
jority of respondents (84%) had completed college with 23%
of them holding a masters degree or higher. Respondents chose
among nine supplied job descriptions. Approximately 20% of
the respondents identified themselves as team leaders, 30% of
respondents chose the title of programmer, 17% chose the title
of system analysts, while a further 17% chose the title of spe-
cialists or consultants. The average size of project was approx-
imately 11 thousand person-hours. Regional analysis indicated
no performance difference between the regions.
D. Measures
Leadership: Measures related to directive and empowering
leadership were adapted from Pearce and Sims [57], who built
upon previously validated measures (e.g., [58]) and developed
multicontext validated measures of leadership types. Direc-
tive leadership is made up of three interrelated dimensions:
1) instruction and command (three items); 2) reprimand (three
items); and 3) assigned goals (three items). Empowering leader-
ship is made up of three interrelated dimensions: 1) encourage
self-development (five items); 2) encourage teamwork (five
items); and 3) participative goal setting (three items). Minor
modifications were made to the original scales. Assessments
about the exercise of these behaviors were gathered from the
team members and subsequently aggregated to the team level.
Team Size: Team leaders were asked to indicate the number
of members on the team. Since the projects were all selected
based on a relatively similar duration (12–15 months), this vari-
able mean s.d. is deemed a good proxy of project
size.
Professional Experience: Years of work experience is one
of the most useful proxies for domain knowledge and technical
capability [12], [23]. Each respondent was asked about his or her
total number years of experience in the software development
field mean s.d. . The responses were gathered
from individual team members and aggregated to create a team
level variable.
Task Uncertainty: The instrument developed by Whithey et
al. [59] has been used in a large number of studies, and its reli-
ability and validity have been confirmed. We used the four-item
version customized and validated by Nidumolu [52] specifically
for the software development environment. The four-items in-
strument has shown a high degree of reliability in a similar soft-
ware development setting. Measures were gathered from indi-
vidual team members and aggregated to the team level.
Administrative Coordination: Administrative coordination
refers to the formal mechanisms to manage schedules, doc-
uments, and communication that the team engages in order
to accomplish its task. We used the Kraut and Streeter [53]
FARAJ AND SAMBAMURTHY: LEADERSHIP OF INFORMATION SYSTEMS DEVELOPMENT PROJECTS 243

TABLE I
SUMMARY STATISTICS AND CORRELATIONS

formal and interpersonal administrative coordination measures IV. RESULTS

since they have already been used in the context of software
development. The measures of administrative coordination
refer to the extent of use on this project of: 1) formal policies
and procedures for coordinating the team’s work; 2) project
milestones and delivery schedules; 3) project documents and
memos; 4) regularly scheduled team meetings; 5) require-
ments/design review meetings; and 6) design inspections. The
six items (1–5 scale, range: from to a small extent, to a great
extent) form a succinct and coherent set of administrative
coordination measures mean s.d. . statistically significant results. Using Cohen’s suggested level
Measures were gathered from individual team members and
aggregated to the team level.
Team Performance: Objective measures of IS project team
performance are problematic [27], [60]. Objective productivity
measures such as lines of code per person per month are often
unavailable, are subject to manipulation, and may reflect the
specific accounting practices of a site rather than an “actual”
performance. Further, using objective measures assumes com-
parability across software projects and does not control for dif-
ferences between projects or unique situational constraints and
thus raise a new set of methodological and measurement is-
sues. Recent studies of organizational teams have relied on the
expert judgment of experienced stakeholders as the best way
to assess team performance [14], [27], [61]. We asked stake-
holders (one from the IS organization and one from the client
organization) to assess the performance of the project team com-
pared with other software teams with which they were familiar
on dimensions such as: budget performance, schedule perfor-
mance, and the extent of meeting design objectives. We aver-
aged the three items to develop a measure of team effectiveness
mean s.d. . All the constructs and
their underlying items are listed in Appendix A.
A. Measurement Analysis
Within-Team Response: We received, on average, five re-
sponses per team. The average size of the team participating in
our study was 9.4 people. Thus, the within-team response rate
was over 50%.
Power Analysis: Most team studies are analyzed at the
team level and thus face sample-size limitations that require an
assessment of whether the statistical procedure used will yield
of power of .8 and an level of .26 [62, p. 414], and in line
with similar team level studies [52], [63], we derive a required
sample size of 61 teams. Since the actual sample contains 69
teams, the appropriate sample size requirement has been met.
Aggregation Analysis.: Before aggregating individual re-
sponses to the team level, we tested the conformity of the level
of measurement to the level of the theoretical analysis [64]. We
used a procedure, called Rwg, to assess within-team rater agree-
ment among the respondents for each team [65]. Table I pro-
vides the Rwg values for this study’s variables. The values range
from .67 to .87 and thus reflect a high degree of within team
agreement and thus provide support for the aggregation of indi-
vidual responses to the team level.
Since we collected project performance ratings from both
an IS stakeholders (senior manager) and from the client side
(client project manager), we tested for agreement between the
stakeholders regarding team performance. The Rwg value for
team performance was .8, indicating high agreement among the
raters.
Internal Consistency of Measurements: Finally, we used a
confirmatory factor analysis approach to measure internal con-
sistency of the measures underlying each construct. The analysis
244 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 53, NO. 2, MAY 2006
TABLE II
CONFIRMATORY FACTOR ANALYSIS ESTIMATES
was undertaken at the individual response level and was oper-
ationalized using the LISREL (version 8.71) framework [66].
The composite reliability index (also called RHOc) is analogous
to Cronbach’s alpha and evaluates the internal consistency of
the indicators underlying a construct by calculating the propor-
tion of trait variance accounted for by the measures (see [67]).
Table II provides the composite reliabilities for each of the six
constructs included in this paper. The values of the composite
reliabilities are: Instruct and command Reprimand
Assigned goals Encourage self-development
Encourage teamwork , and Participative goal setting
. All of our constructs noticeably exceed the accepted
minimum level of .7 (that at least 70% of the variance is due to
the trait) [68].
In addition, we calculated reliability using a traditional anal-
ysis approach by calculating the Cronbach alpha levels of all our
variables. As seen in Table I, the Cronbach alpha levels are all
greater than .7, and thus comfortably demonstrate internal con-
sistency of measurement.
Convergent and Discriminant Validity: Convergent va-
lidity in a confirmatory factor analysis framework is the amount
of agreement among measures of the same trait. As indicated by
Table II, all the t-values underlying each indicator in the model
are statistically significant at the level, thus providing
an initial indication of convergent validity. A stronger test of
both convergent and discriminant validity is provided by square
root of the average variance extracted (AVE). The AVE values
of our constructs are shown in Table II and exceed the .707
value (corresponding to an AVE of .5) which indicates that the
majority of the variance is accounted for by the construct.
Discriminant validity focuses on the extent of difference
between constructs. A construct should share more variance
with its indicators than with other constructs. One criterion for
discriminant validity is to compare the AVE to the correlation
table values [69]. An examination of Table I indicates that all
our constructs have AVE values that are larger than their
correlation with other constructs, demonstrating discriminant
validity.
A third test for discriminant validity is to compare the theo-
retical measurement model to other models, where constructs
are specified as fully correlated [70]. This analysis requires the
comparison between a constrained model whose interconstruct
correlations are set to one and the unconstrained model. If the
constrained model exhibits a significantly higher chi-squared
value compared to the unconstrained model, then discrim-
inant validity has been supported. Tests of the constrained
model yielded the following results: chi-square
Root Mean Square Residual . We
ran 15 different models corresponding to all permutations
where two constructs are set to be correlated. These models
produced chi-square values ranging from 549 to
728.5. Even for the best constrained model, the difference
between its chi-square and that of the theoretical model was
high: chi-square difference . The
significantly lower chi-square value for the theoretical model,
compared to the best constrained model, provides further
support for discriminant validity.
A similar analysis was also performed to assess the unidimen-
sionality of our team performance measures. We used a prin-
cipal component factor analysis due to the smaller sample size
( , since the measures focused on the team level). The
results confirmed the existence of only one dimension of stake-
holder rating of team performance. Overall, the measures meet
the basic requirements of reliability and validity.
Second-Order Leadership Factors: Based on consistent
findings in the literature [32], [36], [38], [57], [71], we concep-
tualized directive and empowering leadership as second-order
factors. A second order formulation is necessary when the un-
derlying measures can be viewed as a reflection or an expression
of the higher-level construct [72]. This is in line with recent for-
mulations of empowering and directive leadership as theoretical
archetypes [73] and with previous literature (e.g., [74] and [75]).
Using Lisrel, we performed a second-order factor analysis in
order to confirm this theoretical orientation. Our second-order
model with directive and empowering leadership had the fol-
lowing properties: chi-square RMSEA
CFI . Both the root mean square error of approxi-
mation (RMSEA) and the comparative fit index (CFI) values
comfortably meet the accepted threshold values of less than
.08 and larger than .9, respectively [66]. We conclude that the
modeling of leadership as a second-order factor is reasonable
and meets accepted specification tests.
Descriptive Results: Table I presents the means, standard
deviations, and intercorrelations of the variables present in the
research model. The distributional properties (e.g., skewness) of
the variables were well within the accepted range. The correla-
tions are below the .8 levels that would indicate high collinearity
[76]. We note that the correlation between assigned goal (a di-
rective dimension) and participative goal setting (an empow-
ering dimension) is relatively high . This is most likely
due to both sets of items being focused on goals. Because we
FARAJ AND SAMBAMURTHY: LEADERSHIP OF INFORMATION SYSTEMS DEVELOPMENT PROJECTS
TABLE III
REGRESSION RESULTS FOR LEADERSHIP MODEL OF TEAM PERFORMANCE
passed the AVE and confirmatory factor analysis tests, and
because the measures are conceptually distinct, we do not con-
sider this level of correlation a threat to validity.
B. Hypothesis Testing Results
Analysis Strategy: A structural equation modeling frame-
work could not be used due to two reasons. First, the sample size
is relatively small; second, the aggregation necessary
for group level analysis makes it impossible to take advantage
of the measurement advantages of programs such as Lisrel or
PLS. In particular, the limited degrees of freedom for testing in-
teraction effects through Lisrel or PLS constrained our ability to
do path analysis. Thus, while we were able to take advantage of
Lisrel’s capabilities for measurement analysis, we applied hier-
archical regression analysis on team-level aggregated scores for
hypothesis testing.
Since our theoretical propositions require the testing of both
the direct effects of leadership on team performance, as well as
the moderating effects of team expertise and task uncertainty,
variables were mean centered in order to reduce the potential
problem of multicollinearity [77]. Table III presents the results
of our analysis. Model 1 shows the results for the control
variables (administrative coordination and team size). Next, we
enter the main leadership variables as well as the moderator
variables (models 2 and 4). In a final step, we enter the interac-
tion terms (models 3 and 5). Finally, we test the joint effect of
the moderator variables by entering them jointly in model 6.
Results: Hypothesis 1a proposed a direct link between di-
rective leadership and IS project team performance. The path is
not significant, indicating that directive leadership has no im-
pact on IS project team outcomes. Hypothesis 1b suggested a
direct link between empowering leadership and team perfor-
mance. We found no significant link between those two vari-
245
ables (see model 2). Hypotheses 2a and 2b proposed a mod-
eration effect by professional experience, whereas hypotheses
H3a and 3b proposed a moderating effect by task uncertainty on
the link between leadership and team performance. The results
(models 3 and 5, respectively) show that the moderation effect is
operating for both professional experience ( % for
) and task uncertainty ( %
for ). However, we found no support for
the moderation of the directive leadership–team performance
link by either experience or task uncertainty. Finally, we found
strong support for the moderation by experience
and task uncertainty of the empow-
ering leadership–team performance link, thus providing partial
support for our hypothesized relationships.
The results of model 6 provide support for the joint effect
of expertise and task uncertainty. The dual impact model has
the highest adjusted (21.7%), and both moderators are sig-
nificant (experience ; task uncertainty
).
In order to facilitate interpretation of interaction terms, we
present further analysis of the two moderator effects by plotting
the moderating effects of professional experience and task
uncertainty on the relationship between empowering leader-
ship and team performance. Following Aiken and West [77],
the above reported interaction effects are graphically plotted
in a series of figures. Fig. 2(a) indicates that when the team
has low levels of professional experience, team performance
deteriorates if the leader is empowering. However, when the
team is experienced, empowering leadership is strongly linked
to higher team performance. Fig. 2(b) indicates a similar effect
for task uncertainty: when the task is not uncertain, empow-
ered teams perform worse. When the task is highly uncertain,
empowered teams perform better.
246
Fig. 2. Effect on team performance of interaction of (a) professional expe-
rience and empowering leadership and (b) task uncertainty and empowering
leadership.
V. DISCUSSION
This paper’s primary goal is to develop and test a model of
leadership in IS project teams. The empirical results do not show
a direct effect of either of directive or empowering leadership on
team performance. However, the results strongly suggest that
empowering leadership plays an important positive role under
conditions of high team expertise (as measured by professional
experience) and high task uncertainty.
Our findings suggest that previously inconclusive results be-
tween software development team leadership and performance
may have resulted from expectations of direct effects when the
relationship is actually more complicated and moderated by fac-
tors such as task ambiguity and team expertise. These findings
corroborate the expectation that task characteristics and team
skills are important factors that moderate the impact of leader-
ship [50], [51]. We also provide support to Vroom’s [43] nor-
mative model of leader actions that emphasize the importance
for leaders to match their action to the demands of the task.
The current results do confirm previous research findings
about the limitation of using directive leadership and perfor-
mance [21] [32]. Modern IS project work may be too complex,
technology too specialized, and expertise too distributed for
traditional centralized leader techniques such as a chief pro-
grammer approach to work. On the other hand, we did not find
a direct effect of empowering leadership, which we view as the
modern successor of the egoless programming team concept
suggested three decades ago as an alternative to the rigidity of
the chief programmer approach. The effects of empowering
leadership are highly contingent on the expertise present on the
team and the demands of the task. These findings are in tune
IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 53, NO. 2, MAY 2006
with recent work in leadership of knowledge work teams that
favors a contingent approach [37], [39], [71].
Our results extend current research on the control and coor-
dination of software teams by suggesting how leader practices
can affect team outcomes. Previous research on control focused
on the relationship between project leaders and client or IS
stakeholders, with a focus on investigating factors that allow
the stakeholder to effectively control the project [11], [17]. Our
findings suggest that leadership may be an important unspeci-
fied factor that mediates between control and project outcomes.
Similarly, the coordination of software development literature
has emphasized the importance of coordination mechanisms
and of expertise coordination among team members [16], [53].
Our results provide specific guidance to software developers
by suggesting that a leader’s practices may impact outcomes in-
dependently from the use of coordination mechanisms. A leader
may play a crucial role in setting the stage for the informal co-
ordination of expertise by encouraging teamwork or setting in-
trateam assistance goals. A more delicate balancing act relates
to the interplay between the need to provide effective control
and coordination through traditional project management tech-
niques and the necessity to allow the team to engage in joint
problem solving and expertise sharing without going through
formal roles or mechanisms (e.g., the leader or team meetings).
A possible heuristic suggested by our results is to engage in em-
powering leadership behaviors only for complex and uncertain
projects.
Administrative coordination, included in our model as a
control variable, has been prized by IS managers, as the essence
of hands-on project management. Our results show that admin-
istrative coordination explains significant variance by itself but
that empowering leadership provides additional explanatory
power when the task is uncertain or the team is high on exper-
tise. This suggests that leadership impacts performance over
and above the use of administrative coordination and is needed
for higher team performance.
Given the historic prevalence of software development studies
in the laboratory, the current study is noteworthy in its focus on
long-duration software teams in a field setting and the use of
stakeholders to measure team performance. It is one of the first
field studies to directly contrast two important types of IS project
team leadership. However, a number of limitations need to be
recognized. First, the cross-sectional nature of the investigation
limits our ability to study how leadership unfolds over time.
Second, the measure of performance relies on the evaluation of
stakeholders and thus cannot be taken as “objective” measures
of performance. We tried to limit this subjective bias by using
informants from both the IS and the client organizations and by
using multi-item measures. Future research may benefit from the
collection of more objective performance measures (function
points, historic versus final budget and schedule).
Generalizability of our results is another concern because our
sample came from a single, albeit very large, organization and
from middle-sized teams working on business software. While
much of the strength of our findings is due to the careful se-
lection of teams based on a predefined criterion, future research
would benefit from studying different sized teams in other orga-
nizational settings and working on other types of software (e.g.,
FARAJ AND SAMBAMURTHY: LEADERSHIP OF INFORMATION SYSTEMS DEVELOPMENT PROJECTS
systems software) to validate our findings. One intriguing aspect
of our taking a knowledge perspective on team leadership and
team performance is that our results have relevance to a broader
segment of teams engaged in knowledge work. Recent research
on software teams [16], [29] that has taken a knowledge team
perspective has similarly stressed the relevance of their findings
to teams such as consulting, legal, and fast response settings
where knowledge is distributed and the task uncertain.
VI. CONCLUSION
Researchers have long called for more research on manage-
rial aspects of software development [22], [78], software project
management [19], software team coordination [16], and soft-
ware team control [17]. Leadership of software development
teams has seen little attention since the pioneering investiga-
tions of Weinberg [31] and Mantei [32] well over two decades
ago. The research reported here focuses on team leadership as
an important factor in IS project teams and is an answer to these
calls. The results support the contention of early IS researchers
regarding the importance of studying leadership as a core factor
affecting all aspects of teamwork and performance [32].
This research improves our understanding of the importance
of leadership, especially empowering leadership, for team per-
formance. It provides an explanation for the inconclusive find-
ings that have left practitioners with little guidance as to what
leadership type is more effective in software development. By
demonstrating the importance of leadership over and above the
impact of administrative coordination mechanisms as well as
specifying the contingent nature of empowering leadership, this
research has contributed by extending early conceptualizations
of software team leadership and shed light on previously contra-
dictory findings on how best to manage software teams. Future
studies of IS project teams may benefit from a deeper investiga-
tion of the leadership factors uncovered in this research.
APPENDIX
CONSTRUCT DESCRIPTION
Directive Leadership: Instruction and Command
(1–5 scale, range: definitely not true to definitely true)
When it comes to my work, my team leader gives me in-
structions on how to carry it out.
My team leader gives me instructions about how to do my
work.
My team leader provides commands in regard to my work.
Directive Leadership: Reprimand
(1–5 scale, range: definitely not true to definitely true)
My team leader reprimands me when my performance is
not up to par.
When my work is not up to par, my team leader points it
out to me.
My team leader lets me know about it when I perform
poorly.
Directive Leadership: Assigned Goals
(1–5 scale, range: definitely not true to definitely true)
My team leader establishes my performance goals.
My team leader sets the goals for my performance.
My team leader establishes the goals for my work.
247
Empowering Leadership: Encourage Self Development
(1–5 scale, range: definitely not true to definitely true)
My team leader encourages me to learn new things.
My team leader encourages me to seek out opportunities to
learn.
My team leader encourages me to develop my skills and
abilities.
My team leader encourages me to learn by extending my-
self.
My team leader encourages me to develop myself.
Empowering Leadership: Encourage Team Work
(1–5 scale, range: definitely not true to definitely true)
My team leader encourages me to work together with other
individuals who are part of the team.
My team leader encourages cooperation among members
of the team.
My team leader urges me to work as a team with other
individuals who are part of the team.
My team leader emphasizes the importance of working to-
gether for a common goal.
My team leader advises me to coordinate my efforts with
other individuals who are part of the team.
Empowering Leadership: Participative Goal Setting
(1–5 scale, range: definitely not true to definitely true)
My team leader and I sit down together and reach agree-
ment on my performance goals.
My team leader works with me to develop my performance
goals.
My team leader and I work together to decide what my
performance goals should be.
Administrative Coordination. Rate the coordination mech-
anisms listed below according to the extent of their use on the
project.
(5 point scale; range: to a small extent—to a great extent)
formal policies and procedures for coordinating the team’s
work;
project milestones and delivery schedules;
project documents and memos;
regularly scheduled team meetings;
requirements/design review meetings;
design inspections.
Team Performance. Compared to other software teams you
are familiar with:
(1–5 scale; range: well below average—well above average;
given only to stakeholders)
the team’s adherence to schedules;
the team’s adherence to budgets;
extent to which the system meets the design objectives.
REFERENCES
[1] C. Benko and F. W. McFarlan, Connecting the Dots: Aligning Projects
With Objectives in Unpredictable Times. Boston, MA: Harvard Bus.
School Press, 2003.
[2] PMI Project Management Factbook, 2nd ed. Newton Square, PA:
Project Manage. Inst., Inc., 2001.
[3] W. W. Gibbs, “Software’s chronic crisis,” Sci. Amer., pp. 86–95, 1994.
[4] C. Jones, Applied Software Measurement. New York: McGraw-Hill,
1996.
[5] K. H. Moller and D. J. Paulish, Software Metrics. London, U.K.:
Chapman & Hall, 1993.
248
[6] E. Oz, “When professional standards are lax: The CONFIRM failure
and its lessons,” Commun. ACM, vol. 37, pp. 29–36, 1994.
[7] J. S. Bozman, “United to simplify Denver’s troubled baggage project,”
Computerworld, p. 76, 1994.
[8] D. C. Johnston, At I.R.S., a system update gone awry. New York: New
York Times, 2003.
[9] B. Curtis, H. Krasner, and N. Iscoe, “A field study of the software
design process for large systems,” Commun. ACM, vol. 31, pp.
1268–1287, 1998.
[10] S. Faraj and R. Geter, “Understanding software project failures,” in
Proc. Amer. Inf. Syst. (AIS) Annu. Conf., 1998.
[11] L. J. Kirsch, “The management of complex tasks in organizations: Con-
trolling the systems development process,” Org. Sci., vol. 7, pp. 1–21,
1996.
[12] F. P. Brooks, The Mythical Man-Month. Reading, MA: Addison-
Wesley, 1975.
[13] T. DeMarco and T. Lister, Peopleware. New York: Dorset, 1987.
[14] P. J. Guinan, J. G. Cooprider, and S. Faraj, “Enabling software
development team performance during requirements definition: A
behavioral versus technical approach,” Inf. Syst. Res., vol. 9, pp.
101–125, 1998.
[15] L. Wallace, M. Keil, and A. Rai, “How software project risk affects
project performance: An investigation of the dimensions of risk and an
exploratory model,” Decision Sci., vol. 35, pp. 289–321, 2004.
[16] S. Faraj and L. Sproull, “Coordinating expertise in software develop-
ment teams,” Manage. Sci., vol. 46, pp. 1554–1568, 2000.
[17] L. J. Kirsch, V. Sambamurthy, D.-G. Ko, and R. L. Purvis, “Controlling
information systems development projects: The view from the client,”
Manage. Sci., vol. 48, pp. 484–498, 2002.
[18] S. Faraj, V. Sambamurthy, and P. J. Guinan, “Control strategies and
performance of software development teams: The mediating role of
experienced ambiguity,” Working Paper, 2005.
[19] L. J. Kirsch, Software Project Management: An Integrated Perspective
for an Emerging Paradigm, R. W. Zmud, Ed. Cincinnati, OH: Pin-
naflex Educational Resources, 2000, pp. 285–304.
[20] B. Curtis, Tutorial: Human Factors in Software Development. Los
Angeles, CA: IEEE Computer Soc. Press, 1985.
[21] B. Schneiderman, Software Psychology. Cambridge, MA: Winthrop,
1980.
[22] S. P. J. Brooks, “No silver bullet: Essence and accidents of software
engineering,” Computer, vol. 20, pp. 10–19, 1987.
[23] B. W. Boehm, “Improving software productivity,” Computer, pp.
43–57, Sep. 1994.
[24] D. Robey, D. L. Farrow, and C. R. Franz, “Group process and conflict
in system development,” Manage. Sci., vol. 35, pp. 1172–1191, 1987.
[25] M. L. Markus, “Power, politics and MIS implementation,” Commun.
ACM, vol. 26, pp. 430–444, 1983.
[26] C. R. Franz and D. Robey, “An investigation of user-led system de-
sign: Rational and political perspectives,” Commun. ACM, vol. 27, pp.
1202–1209, 1984.
[27] J. C. Henderson and S. Lee, “Managing I/S design teams: A control
theories perspective,” Manage. Sci., vol. 38, pp. 757–777, 1992.
[28] D. B. Walz, J. J. Elam, and B. Curtis, “Inside a software design team:
Knowledge acquisition, sharing, and integration,” Commun. ACM, vol.
36, pp. 63–77, 1993.
[29] M. Hoegl and H. G. Gemuenden, “Teamwork quality and the success
of innovative projects: A theoretical concept and empirical evidence,”
Org. Sci., vol. 12, pp. 435–449, 2001.
[30] F. T. Baker, “Chief programmer team management of production pro-
gramming,” IBM Syst. J., vol. 11, pp. 56–73, 1972.
[31] G. M. Weinberg, The Psychology of Computer Programming. New
York: Van Nostrand Reinhold, 1971.
[32] M. Mantei, “The effect of programming team structures on program-
ming tasks,” Commun. ACM, vol. 24, pp. 106–113, 1981.
[33] M. E. Shaw, Group Dynamics. New York: McGraw-Hill, 1981.
[34] J. R. Hackman, Leading Teams. Boston, MA: Harv. Bus. School
Press, 2002.
[35] C. L. Pearce and J. A. Conger, Shared Leadership: Reframing the
How’s & Why’s of Leadership. Thousand Oaks, CA: Sage, 2003.
[36] C. C. Manz and H. P. Sims, “Leading teams to lead themselves: The
external leadership of self-managing work teams,” Admin. Sci. Quart.,
vol. 32, pp. 106–128, 1987.
[37] C. L. Pearce, “The future of leadership: Combining vertical and shared
leadership to transform knowledge work,” Acad. Manage. Executive,
vol. 18, pp. 47–59, 2004.
[38] G. Yukl, Leadership in Organizations, 5th ed. Upper Saddle River,
NJ: Prentice-Hall, 2002.
IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 53, NO. 2, MAY 2006
[39] S. S. Kahai, J. J. Sosik, and B. J. Avolio, “Effects of leadership style
and problem structure on work group process and outcomes in an elec-
tronic meeting system environment,” Personnel Psychol., vol. 50, pp.
121–146, 1997.
[40] H. P. J. Sims and C. C. Manz, Company of Heroes: Unleashing the
Power of Self-Leadership. New York: Wiley, 1996.
[41] C. C. Durham, D. Knight, and E. A. Locke, “Effects of leader role,
team-set goal difficulty, efficacy, and tactics on team effectiveness,”
Organizational Behavior Human Decision Processes, vol. 72, pp.
203–231, 1997.
[42] V. H. Vroom and A. G. Jago, The New Leadership: Managing Partici-
pation in Organizations. Englewood Cliffs, NJ: Prentice–Hall, 1988.
[43] V. H. Vroom, “Leadership and the decision-making process,” Org. Dy-
namics, vol. 28, pp. 82–94, 2000.
[44] R. J. House, “Path-goal theory of leadership: Lessons, legacy, and a
reformulated theory,” Leadership Quart., vol. 7, pp. 323–352, 1996.
[45] R. J. House and T. R. Mitchell, “Path-goal theories of leadership,” Con-
temporary Bus., vol. 3, pp. 81–98, 1974.
[46] C. A. Schriesheim, R. J. House, and S. Kerr, “Leader initiating struc-
ture: A reconciliation of discrepant research results and some empirical
tests,” Org. Behav. Human Performance, vol. 15, pp. 197–221, 1976.
[47] C. C. Manz and H. P. Sims, Superleadership: Leading Others to Lead
Themselves. Englewood Cliffs, NJ: Prentice–Hall, 1989.
[48] A. Bandura, Social Foundations of Thought and Action: A Social Cog-
nitive Theory. Englewood Cliffs, NJ: Prentice-Hall, 1986.
[49] E. A. Locke and G. P. Latham, A Theory of Goal Setting and Task
Performance. Englewood Cliffs, NJ: Prentice-Hall, 1990.
[50] S. Kerr and J. M. Jermier, “Substitutes for leadership: Their meaning
and measurement,” Organizational Behavior Human Performance, vol.
22, pp. 375–403, 1978.
[51] J.-P. Howell, P. W. Dorfman, and S. Kerr, “Moderator variables in lead-
ership research,” Acad. Manage. Rev., vol. 11, pp. 88–102, 1986.
[52] S. Nidumolu, “The effect of coordination and uncertainty on software
project performance: Residual performance risk as an intervening vari-
able,” Information Syst. Res., vol. 6, pp. 191–219, 1995.
[53] R. E. Kraut and L. A. Streeter, “Coordination in software develop-
ment,” Commun. ACM, vol. 38, pp. 69–81, 1995.
[54] S. Conte, H. Dunsmore, and V. Shen, Software Engineering Metrics
and Models. Readings, MA: Benjamin/Cummings, 1986.
[55] A. H. Van de Ven, A. L. Delbecq, and R. Koenig, “Determinants of
coordination mode within organizations,” Amer. Sociological Rev., vol.
41, pp. 322–338, 1976.
[56] N. Venkatraman and V. Ramanujan, “Planning system success: A con-
ceptualization and an operational model,” Manage. Sci., vol. 33, pp.
687–705, 1987.
[57] C. L. Pearce and H. P. J. Sims, “Vertical versus shared leadership as
predictors of the effectiveness of change management teams: An ex-
amination of aversive, directive, transactional, transformational, and
empowering leader behaviors,” Group Dynamics, vol. 6, pp. 172–197,
2002.
[58] J. F. Cox and H. P. J. Sims, “Leadership and team citizenship be-
havior: A model and measures,” Advances Interdisciplinary Studies
Work Teams, vol. 3, pp. 1–41, 1996.
[59] M. Withey, R. Daft, and W. Cooper, “Measures of Perrow’s work unit
technology: An empirical assessment and a new scale,” Acad. Manage.
J., vol. 26, pp. 45–63, 1983.
[60] C. F. Kemerer, “An agenda for research in the managerial evaluation
of computer-aided software engineering tools impact,” in Proc. 22nd
Annu. Hawaii Int. Conf. Syst. Sci., 1989, pp. 219–228.
[61] A. C. Edmondson, “Psychological safety and learning behavior in work
teams,” Admin. Sci. Quart., vol. 44, pp. 350–383, 1999.
[62] J. Cohen, Statistical Power Analysis for the Behavioral Sciences.
Hillsdale, NJ: Lawrence Erlbaum, 1988.
[63] D. G. Ancona and D. F. Caldwell, “Bridging the boundary: External ac-
tivities and performance in organizational teams,” Admin. Sci. Quart.,
vol. 37, pp. 634–665, 1992.
[64] K. J. Klein and S. W. J. Kozlowski, Multilevel Theory, Research, and
Methods in Organizations. San Francisco, CA: Jossey-Bass, 2000.
[65] L. R. James, R. G. Demaree, and G. Wolf, “Estimating within-group
interrater reliability with and without response bias,” J. Appl. Psychol.,
vol. 69, pp. 85–98, 1984.
[66] K. G. Jöreskog and D. Sörbom, LISREL8: Structural Equation Mod-
eling With SIMPLIS Command Language, 2nd ed. Chicago, IL: Sci-
entific Software, 1993.
[67] A. C. Edmondson, “Learning from mistakes is easier said than done:
Group and organizational influences on the detection and correction of
human error,” J. Appl. Behav. Sci., vol. 32, pp. 5–24, 1996.
FARAJ AND SAMBAMURTHY: LEADERSHIP OF INFORMATION SYSTEMS DEVELOPMENT PROJECTS
[68] R. P. Bagozzi, Y. Yi, and L. W. Phillips, “Assessing construct validity
in organizational research,” Admin. Sci. Quart., vol. 36, pp. 421–458,
1991.
[69] C. Fornell and D. F. Larcker, “Evaluating structural equations models
with unobservable variables and measurement error,” J. Marketing
Res., vol. 18, pp. 39–50, 1981.
[70] N. Venkatraman, “The concept of fit in strategy research: Toward
verbal and statistical correspondence,” Acad. Manage. Rev., vol. 14,
pp. 423–444, 1989.
[71] S. Yun, S. Faraj, and H. P. J. Sims, “Contingent leadership and effective-
ness of trauma resuscitation teams,” J. Appl. Psychol., to be published.
[72] R. L. Purvis, V. Sambamurthy, and R. W. Zmud, “Assimilation of
knowledge platforms in organizations: An empirical investigation,”
Org. Sci., vol. 12, pp. 117–135, 2001.
[73] C. L. Pearce, H. P. J. Sims, J. F. Cox, G. Ball, E. Schnell, K. A.
Smith, and L. K. Trevino, “Transactors, transformers and beyond: A
multi-method development of a theoretical typology of leadership,” J.
Manage. Development, vol. 22, pp. 273–307, 2003.
[74] R. T. Keller, “Transformational leadership and the performance of
research and development project groups,” J. Manage., vol. 18, pp.
489–501, 1992.
[75] B. M. Bass, Leadership and Performance Beyond Expectations. New
York: Free Press, 1985.
[76] P. Kennedy, A Guide to Econometrics. Cambridge, MA: MIT Press,
1985.
[77] L. S. Aiken and S. G. West, Multiple Regression: Testing and Inter-
preting Interactions. Newbury Park, CA: Sage, 1991.
[78] V. B. Basili and J. Musa, “The future engineering of software: A man-
agement perspective,” IEEE Comput., vol. 24, no. 1, pp. 90–96, 1991.
Samer Faraj received the M.S. degree in technology
and policy from the Massachusetts Institute of Tech-
nology, Cambridge, and the Ph.D. degree in manage-
ment information systems from the School of Man-
agement, Boston University, Boston, MA.
Prior to getting his doctorate, he spent a decade
working in a variety of consulting and IS positions.
He is currently an Associate Professor in the De-
partment of Decision and Information Technologies,
University of Maryland, College Park. His research
interests include the coordination of expertise in
knowledge teams in settings such as software development and trauma care,
View publication stats
249
the development of online knowledge communities, and the impact of IT on
organizations. His work has appeared or is forthcoming in journals such as In-
formation Systems Research, Management Science, MIS Quarterly, Journal of
Applied Psychology, Journal of Strategic Information Systems, and Information
Technology & People.
Dr. Faraj received a Fulbright Award. He is an Associate Editor of Informa-
tion Systems Research and serves on the Editorial Board of Organization Sci-
ence and Information and Organization. In addition, he is currently co-editing
the Special Issue of Organization Science on IT and Organizational Form and
Function.
V. Sambamurthy received the Ph.D. degree from the
University of Minnesota, Minneapolis, in 1989.
He is the Eli Broad Professor of Information
Technology and Executive Director of the Center for
Leadership of the Digital Enterprise at the Eli Broad
Graduate School of Management, Michigan State
University, East Lansing. He has researched issues
related to the impacts of CIO and top management
team characteristics on firms’ success with IT
assimilation, the impacts of institutional forces on
organizational IT assimilation, and the capabilities
associated with strategic leverage of IT. His work has been published in journals
such as MIS Quarterly, Information Systems Research, Management Science,
Organization Science, Decision Sciences, and the IEEE TRANSACTIONS ON
ENGINEERING MANAGEMENT.
Dr. Sambamurthy currently serves on the Editorial Board of Management
Science and is the Editor-in-Chief of Information Systems Research. He has
previously served as Senior Editor for MIS Quarterly, Department Editor for the
IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT., and Americas Editor
for the Journal of Strategic Information Systems.