net/publication/3076915
CITATIONS READS
82 766
2 authors:
Some of the authors of this publication are also working on these related projects:
All content following this page was uploaded by Samer Faraj on 04 November 2014.
Abstract—How best to lead an information systems project or the IRS system update [8] seem to indicate that IS project
team continues to be an open issue. For three decades, the re- problems are increasingly in the public eye and can cost hun-
search literature has contrasted between the leadership of the dreds if not billions of dollars. Therefore, improving the pro-
“chief programmer” led team to that of the “egoless” software
team with little clarity as to what is appropriate leadership and ductivity and quality of IS projects is important. While early ap-
under what circumstances. Software project teams, like other proaches were focused on the discovery of better methodologies
knowledge teams, are characterized by distributed expertise, the and tools (JAD, client-server, object orientation, CASE tools,
reliance on methodologies, high levels of collaboration, as well as etc.), there is a growing realization that IS projects are charac-
the need to meet the expectations of a diverse set of stakeholders. terized by challenges in communication, coordination, learning,
We propose a theoretical model of information systems project
team leadership that focuses on empowering and directive lead-
and negotiation [9]–[11]. Therefore, examinations of the effec-
ership practices and investigate whether this leadership is more tiveness of IS projects must include an understanding of the de-
effective than the use of traditional coordination mechanisms; velopment process and “peopleware” [12]–[15].
we also test whether these relationships are moderated by fac- Teams are the fundamental organizational unit through which
tors such as task uncertainty or professional experience. We test IS projects are executed. A team structure brings together busi-
this model using data from 69 software development teams. Our
ness and process knowledge and the requisite design and pro-
results indicate that empowering leadership has an important
impact on team performance but only under conditions of high gramming skills. However, three challenges characterize the ef-
task uncertainty or team expertise. fectiveness of IS project teams. First, knowledge required for
Index Terms—Project management, software development,
the completion of IS project tasks is distributed across team
team leadership. 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-
I. INTRODUCTION quire a portfolio of control strategies, including a combination
of formal and informal modes of control [17]. Expertise is re-
and hierarchical in nature, because they delineate clear lines of B. Traditional IS Project Team Organizing
leadership control, might not be very effective in such contexts
[46]. Studies are needed about the exercise of leadership in such An IS project team has the following characteristics: 1) it is
work contexts. Finally, with the growing salience of IS projects, cross functional; 2) its members bring multidisciplinary knowl-
specific studies of leadership are needed in this important do- edge; 3) its work is characterized by time pressures; and 4) out-
main of practical interest and economic value creation. comes must be adaptive to changing stakeholder expectations
The goal of this paper is to answer two core research ques- and business and technology conditions. The team must find
tions: 1) What types of team leadership behaviors influence IS ways of integrating distributed expertise. Membership is fluid,
project team performance? and 2) Under what circumstances and new members are integrated into the software development
are specific leadership behaviors more effective? We propose task, as needed. The team members perform highly interdepen-
a model to investigate the effects of alternative leadership be- dent and often concurrent tasks. Due to their highly intellective
haviors on the performance of project teams. In particular, we tasks and the enormous amount of coordination that must take
test whether their impacts are moderated by task uncertainty and place, particularly for the sharing and integration of knowledge,
professional experience. The next section of this paper presents IS project teams are unique and different from other teams in
a review of the literature of IS development and develops a action in organizations [16], [29].
conceptual framework. Then, we describe the methodology for How best to lead a software team has remained an evolving
the study. Finally, we present our findings and discuss their issue. Traditionally, software teams were structured based on
implications. seniority and experience, with a senior programmer serving as
leader. Authority and lines of responsibility were clear and easy
II. THEORY to understand. Each junior programmer was evaluated by a su-
perior. Competition among team members was seen as a nat-
A. Research on IS Development Processes ural occurrence and is believed to motivate individuals to work
A variety of theoretical approaches have framed investiga- harder. A widely used traditional form is that of the chief pro-
tions about the performance of IS development teams. Early re- grammer-led team. A chief programmer produces the critical
search efforts identified individual level human factors that af- core of the system and specifies, evaluates, and integrates all
fect outcomes, such as how individuals generate, understand, other programming tasks for the system [30]. As team leader,
and debug small programming problems. Utilizing laboratory- the chief programmer has the highest level of expertise and thus
based investigations of how people generate, understand, and is better able to divide the work, assign roles, and help the other
debug small programs, this research has formed the basis for team members. The leader is basically responsible for all posi-
the human side of software engineering (see [20] and [21] for a tive and negative outcomes but also has significant power to con-
review of this literature). The key finding of these studies was trol and direct the team as needed. Brooks draws a positive par-
that large differences (up to a factor of 100) in performance can allel between a software team thus structured and a surgical team
occur between individual programmers working with the same with the chief programmer playing the role of surgeon [12].
An alternative to the chief programmer approach is the ego-
task. As a result, some have concluded that the most effective
less programming team. It reflects a more egalitarian philosophy
way to improve IS project performance is to simply use individ-
of programming proposed by Weinberg [31] in order to remedy
uals with superior programming abilities [22], [23].
the deficiencies of traditional team governance. The team is de-
Field studies of IS development have emphasized team
centralized and programmers communicate freely with others
processes. Robey et al. [24] showed that participation and in-
on difficult tasks [32]. Expertise is distributed, collaboration is
fluence are linked to increased conflict and conflict resolution.
encouraged, and task assignments are negotiated by the whole
Other studies have shown that user-developer problems have
team.
their bases in interdepartmental political conflict [25], [26]. A Clearly, each of these team governance structures leads to dif-
number of studies have targeted team control and found that ferent emergent roles among team members and a different set
outcome measurability and a combination of high-managerial of interrelations. A chief programmer structure assumes low in-
outcome control and high team behavioral controls lead to better terdependence, coordination through the hierarchy, and does not
team outcomes [11], [17], [27]. Other IS development studies reward teamwork. The centralization of decision making and
have demonstrated the importance of within-team knowledge communication leaves the team vulnerable to leader saturation
acquisition and sharing processes [9], [28]. More recently, (e.g., [33]). It may not be appropriate for complex tasks as it
Guinan et al. [14] found that task-related group processes assumes that a leader’s technical skill goes hand in hand with
were significantly more important in predicting IS project team effective communication ability [32]. Conversely, an egoless de-
performance than either team factors or usage of automated velopment team is likely to engage in a richer set of lateral co-
tools. These findings were confirmed by a study of 69 software ordination patterns. Basic management activities such as task
teams where expertise coordination processes were linked to assignments, goal direction, and decision making are likely to
stakeholder ratings of performance [16]. In conclusion, though be more diffuse and take longer [21].
a number of field studies have demonstrated the importance of Most firms have tried different forms of organizing that cover
team processes, few researchers have specifically focused on variations of the archetypal team structures mentioned above.
the role of the leader in creating or sustaining these important However, the question of how to organize and lead an IS project
team processes. team remains unanswered. Research is needed about the impact
240 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 53, NO. 2, MAY 2006
of team leadership on performance. One reason for this dearth do. The leader may also buffer the team from user demands by
of knowledge is that the process of leading a team on a long du- managing team boundaries. Typically, a team leader tends to be
ration, high-complexity, and interdependent task cannot be re- more experienced than other team members in how to control
duced to a simple categorization of leadership acts. Rather, the and coordinate the activities of the team members, manage re-
type of project task, the resource constraints, and the nature of sources, and may have already demonstrated technical excel-
membership on the team all matter and affect the kind of ac- lence or a deep understanding of user domain. A recent study
tivities and behaviors that a leader chooses to engage in. Recent of 66 medium-sized software development projects found that
advances in the managerial leadership literature offer promising leaders’ active involvement in managing team members is posi-
new conceptualizations. tively associated with higher team performance [14]. The role of
the leader is essential because team members have to overcome
C. Directive and Empowering Leadership an often fluid set of requirements, interface with each others’
work and expertise, and integrate their various efforts into a co-
Team leadership has emerged as a significant element in-
herent whole. Thus, we propose the following.
fluencing team effectiveness in today’s environments that re-
quire fast decision making based on sometimes inaccurate, un- Hypothesis 1a (H1a): Directive leadership is positively
available, or equivocal information [34], [35]. Leaders of IS related to team performance.
project teams can impact team outcomes in a number of ways.
Alternatively, IS project teams may also benefit from an
First, a leader can encourage high levels of individual perfor-
empowering leader. An empowering leader consults with
mance from the team members [36]. Second, a leader can en-
and makes joint decisions with team members and delegates
courage teamwork in order to promote expertise coordination responsibilities to team members. Manz and Sims [36], [47]
among members, an important predictor of team performance have proposed empowering leadership as a participative and
[16]. Third, a leader can challenge team members intellectu- self-management focused form of leadership. The empowering
ally and stimulate them intellectually to develop new ways of leader encourages team members’ active participation and
looking at problems and thus speed up the development process self-leadership. The roots of empowering leadership are based
[37]. Finally, involving team members in goal setting is likely to on theoretical perspectives such as the supportive leadership
generate increased commitment, acceptance of team goals, and behavior of path-goal theory [44], [45], the decision procedures
the activation of higher order needs [36], [38]. identified in the participative leadership framework [42], [43],
Since software teams rely on distributed expertise and they social cognitive theory [48], and the participative aspects of
work on tasks that are highly interdependent and require close goal setting theory (e.g., [49]). An empowering leader encour-
coordination, their team leaders require unique skills and ages followers to actively provide input, participate in team
a potentially high degree of technical involvement. Thus, a decisions, and display initiative. An implication of empowering
premium is placed on leader behaviors rather than appeals to leadership is that much of the decisions and control processes
emotion and values (e.g., as in transformational leadership). that traditionally had been the prerogative of the team leader are
Empowering leadership and directive leadership form the now shared with the team. An empowered team will actually
opposite ends of this activity-focused continuum. Empowering share in team leadership. Since team empowerment can be
leaders encourage an active participation from followers or more time consuming, it is best applied to knowledge teams
team members. In contrast, directive leaders typically do not engaged in complex work where tasks are highly interdepen-
expect or allow team members to take initiative but provide dent or require high levels of creativity [35], [37]. Empowered
expertise, control, and guidance. leadership can enhance team performance by allowing mem-
Directive leaders centralize decision making and personally bers room for creativity while encouraging coordination and
direct team activities. They expect team members to follow their sharing of expertise. Such leadership allows team members to
commands and directions [39]–[41]. These behaviors are called collectively take responsibility for team performance. In the
“directive.” Theoretically, this type of leadership is similar to type of knowledge work that characterizes software develop-
the autocratic leadership identified in Vroom and Jago’s partic- ment, empowered leadership might provide the balanced levels
ipative leadership framework [42], [43] and directive leadership of autonomy and control necessary for effective performance.
in path-goal theory [44], [45]. A directive leader corresponds Therefore, we propose the following.
to the image of the traditional boss who relies on a position of
Hypothesis 1b (H1b): Empowering leadership is posi-
power to autocratically lead and sometimes sanction subordi-
tively related to team performance.
nates. Such a leader uses direction, command, assigned goals,
instruction, and reprimand as the primary mechanisms to influ-
D. Moderating Role of Professional Experience and Task
ence subordinate behavior. Directive leadership has been advo-
Uncertainty
cated in knowledge work because it offers needed structure for
intrinsically unstructured work [46]. Software development teams experience different levels of
A directive leader may benefit an IS project team by man- task uncertainty and bring together varying levels of profes-
aging coordination and control. A directive leader assigns tasks, sional expertise to their tasks. Since software development is
controls the budget, manages the schedule, and coordinates in- knowledge intensive, highly interdependent, and requires a high
dividual output integration, all of which are demanding tasks degree of coordination, variations in the levels of task uncer-
that a typical team member may not have time or expertise to tainty or professional experience might impact the degree to
FARAJ AND SAMBAMURTHY: LEADERSHIP OF INFORMATION SYSTEMS DEVELOPMENT PROJECTS 241
which the teams experience pressures for effective communi- high levels of task uncertainty, they have to make sense of
cation, collaboration, and problem solving. As a result of these their tasks, improvise their work processes, and adjust how
varying pressures, we propose that the effects of leadership on they make progress toward agreed upon goals for the software
performance might be moderated by task uncertainty and pro- project. Under such conditions, the ability and willingness
fessional experience. of the team members to engage in cumulative sense-making
Leadership research has identified a number of situational as- and collaboration is important. An empowering leadership
pects (e.g., task environment and organizational characteristics) approach will be more effective because it solicits ideas and
and team characteristics (e.g., skills and professionalism) that inputs from team members and allows them to participate in
moderate the effects of managerial leadership [50], [51]. Vroom the management of the teams’ activities. However, when task
[43] emphasizes forceful action in situations where timing of uncertainty is low, a well-structured and routinized approach
decisions is critical. Under such circumstances, a leader should toward the management of the team’s activities will be ap-
make decisions that at other times would be delegated to team propriate [43]. Consequently, a directive leadership approach
members. The path–goal theory of leadership (e.g., [32]) sug- will be suitable. Hence, we anticipate that task uncertainty will
gests that directive leadership is less useful when followers are moderate the impact of the alternative leadership approaches
more experienced. Finally, Vroom’s normative decision making on performance.
theory [42] also suggests that subordinate participation is more
Hypothesis 3a (H3a): Empowering leadership will make
appropriate when subordinates possess the information required
a greater contribution to team performance when task un-
to complete the task. Thus, a contingency perspective on lead-
certainty is high than when it is low.
ership of software teams appears warranted.
In her study of how software development teams utilize Hypothesis 3b (H3b): Directive leadership will make a
control strategies to monitor and direct their work, Kirsch greater contribution to team performance when task un-
[11] found that knowledge of the IS development process and certainty is low than when it is high.
tasks is a critical factor. Knowledgeable teams are able to
define their activities, structure their work, monitor their task E. Traditional Sources of Influence of IS Project Team
accomplishment, and manage key stakeholders (see also, [17]). Performance
In other words, when team members have significant levels of Although our focus is on leadership, we recognize that other
professional experience with software development, they are team and task characteristics are certainly important. Team size
more likely to possess relevant expertise and valuable experi- could be an obstacle to team performance, a finding that has con-
ence on how to manage their project activities. For such teams, sistently appeared in the software development literature due to
an empowering leadership approach might be more appropriate the diseconomies of scale, exploding complexity, and exponen-
since members may need less direct control and coordination tially increasing project interactions that characterize software
and possibly possess as much relevant task expertise as the development [4], [12], [54]. Therefore, we use team size as a
team leader. In contrast, when teams have low professional control variable.
experience, a directive leadership might be more appropriate A second influential factor is administrative coordination, de-
because the members look to the leader to provide needed fined as processes that manage resource interdependences. Ad-
directions and guidance about their work processes. Therefore, ministrative coordination has been shown in previous research
we expect that the level of professional experience will mod- to affect performance [53], [55]. Following Faraj and Sproull
erate the effects of both directive and empowering leadership [16], we define administrative coordination as formal or pre-
on performance. Therefore, we propose the following. specified mechanisms used to assign tasks, allocate physical and
economic resources, manage resource dependencies, and inte-
Hypothesis 2a (H2a): Empowering leadership will make grate outputs. These mechanisms include budgets, staffing ta-
a greater contribution to team performance when profes- bles, critical path analysis, milestones, inspections, and review
sional experience is high than when it is low. meetings, etc. The use of administrative coordination mecha-
Hypothesis 2b (H2b): Directive leadership will make nisms may be independent of leadership practice and thus could
a greater contribution to team performance when profes- impact team performance by improving work processes.
sional experience is low than when it is high. Fig. 1 provides a graphical representation of our theoretical
model.
Similarly, IS project teams face different levels of uncertainty
about their tasks. Sometimes, software teams face tasks of low III. METHOD
analyzability (that is, few objective procedures are available
to resolve problems) and high variety (occurrence of new and A. Sample
unexpected events during the task completion process). Task Data on IS projects were collected from the applications de-
uncertainties refer to challenges faced by the team about how velopment division of a large high-technology firm specializing
to structure their activities, coordinate actions of the different in software development. This very large division develops ap-
members, and apply the appropriate control strategies [22], plication software for some internal clients but primarily for
[23], [52], [53]. Faraj et al. [18] found that task uncertainty is a commercial clients. Senior management approved the study, and
significant barrier to the effectiveness of software development all key regions and divisions of the firm participated. We se-
teams, especially if it is not managed well. When teams face lected IS project teams from a variety of industries and types of
242 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 53, NO. 2, MAY 2006
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
Fig. 1. Theoretical model. 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-
application. We selected teams from across the country to max- imately 11 thousand person-hours. Regional analysis indicated
imize geographic diversity but chose those involved in business no performance difference between the regions.
applications development to keep the task comparable. We also
limited ourselves to teams ranging from 4 to 15 full-time mem- D. Measures
bers in order to control for the different dynamics and processes Leadership: Measures related to directive and empowering
that characterize very small or large teams. Finally, we chose leadership were adapted from Pearce and Sims [57], who built
teams that had completed their requirements definition stage in upon previously validated measures (e.g., [58]) and developed
order to eliminate teams that were still in formation or struggling multicontext validated measures of leadership types. Direc-
to define their task. We did not include teams that had completed tive leadership is made up of three interrelated dimensions:
their projects in order to avoid retrospection bias. 1) instruction and command (three items); 2) reprimand (three
items); and 3) assigned goals (three items). Empowering leader-
B. Respondents ship is made up of three interrelated dimensions: 1) encourage
Two complementary approaches were used for gathering the self-development (five items); 2) encourage teamwork (five
data. First, data were gathered directly from the team members. items); and 3) participative goal setting (three items). Minor
These data pertained to all of the independent, moderator, and modifications were made to the original scales. Assessments
control variables in our model. Each team member was pro- about the exercise of these behaviors were gathered from the
vided with a survey instrument along with a stamped envelope team members and subsequently aggregated to the team level.
to return the survey directly to the researchers. The instrument’s Team Size: Team leaders were asked to indicate the number
cover page prominently guaranteed individual and team level of members on the team. Since the projects were all selected
confidentiality. Further, data on team performance were gath- based on a relatively similar duration (12–15 months), this vari-
ered through a survey of two project stakeholders, one from the able mean s.d. is deemed a good proxy of project
IS and the other from the client organization. These respondents size.
provided an overall and exogenous view of team performance. Professional Experience: Years of work experience is one
These stakeholders were senior managers who were knowledge- of the most useful proxies for domain knowledge and technical
able about the team and its work and were both affected by capability [12], [23]. Each respondent was asked about his or her
the outcome of the project and were capable of affecting the total number years of experience in the software development
team’s performance. Previous research has shown that subjec- field mean s.d. . The responses were gathered
tive assessments of effectiveness provided by knowledgeable from individual team members and aggregated to create a team
managers have a high level of convergence with other objective level variable.
measures of performance [56]. The stakeholders were identified Task Uncertainty: The instrument developed by Whithey et
by the team and assessed for appropriateness by the manager in al. [59] has been used in a large number of studies, and its reli-
charge of the study. ability and validity have been confirmed. We used the four-item
Responses were received from 13 different sites in the U.S., version customized and validated by Nidumolu [52] specifically
including all the organization’s key regions and several indepen- for the software development environment. The four-items in-
dent sites. A total of 333 respondents from 69 teams participated strument has shown a high degree of reliability in a similar soft-
in the study. In addition, we collected ratings of these teams ware development setting. Measures were gathered from indi-
from 135 stakeholder respondents. Nine out of 78 teams in the vidual team members and aggregated to the team level.
sample did not participate or complete the study (the projects Administrative Coordination: Administrative coordination
were cancelled or the managers changed during the study pe- refers to the formal mechanisms to manage schedules, doc-
riod), for a team-level response rate of 88%. The data collection uments, and communication that the team engages in order
from team members took place during the coding phase (after 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
TABLE III
REGRESSION RESULTS FOR LEADERSHIP MODEL OF TEAM PERFORMANCE
passed the AVE and confirmatory factor analysis tests, and ables (see model 2). Hypotheses 2a and 2b proposed a mod-
because the measures are conceptually distinct, we do not con- eration effect by professional experience, whereas hypotheses
sider this level of correlation a threat to validity. H3a and 3b proposed a moderating effect by task uncertainty on
the link between leadership and team performance. The results
B. Hypothesis Testing Results (models 3 and 5, respectively) show that the moderation effect is
Analysis Strategy: A structural equation modeling frame- operating for both professional experience ( % for
work could not be used due to two reasons. First, the sample size ) and task uncertainty ( %
is relatively small; second, the aggregation necessary for ). However, we found no support for
for group level analysis makes it impossible to take advantage the moderation of the directive leadership–team performance
of the measurement advantages of programs such as Lisrel or link by either experience or task uncertainty. Finally, we found
PLS. In particular, the limited degrees of freedom for testing in- strong support for the moderation by experience
teraction effects through Lisrel or PLS constrained our ability to and task uncertainty of the empow-
do path analysis. Thus, while we were able to take advantage of ering leadership–team performance link, thus providing partial
Lisrel’s capabilities for measurement analysis, we applied hier- support for our hypothesized relationships.
archical regression analysis on team-level aggregated scores for The results of model 6 provide support for the joint effect
hypothesis testing. of expertise and task uncertainty. The dual impact model has
Since our theoretical propositions require the testing of both the highest adjusted (21.7%), and both moderators are sig-
the direct effects of leadership on team performance, as well as nificant (experience ; task uncertainty
the moderating effects of team expertise and task uncertainty, ).
variables were mean centered in order to reduce the potential In order to facilitate interpretation of interaction terms, we
problem of multicollinearity [77]. Table III presents the results present further analysis of the two moderator effects by plotting
of our analysis. Model 1 shows the results for the control the moderating effects of professional experience and task
variables (administrative coordination and team size). Next, we uncertainty on the relationship between empowering leader-
enter the main leadership variables as well as the moderator ship and team performance. Following Aiken and West [77],
variables (models 2 and 4). In a final step, we enter the interac- the above reported interaction effects are graphically plotted
tion terms (models 3 and 5). Finally, we test the joint effect of in a series of figures. Fig. 2(a) indicates that when the team
the moderator variables by entering them jointly in model 6. has low levels of professional experience, team performance
Results: Hypothesis 1a proposed a direct link between di- deteriorates if the leader is empowering. However, when the
rective leadership and IS project team performance. The path is team is experienced, empowering leadership is strongly linked
not significant, indicating that directive leadership has no im- to higher team performance. Fig. 2(b) indicates a similar effect
pact on IS project team outcomes. Hypothesis 1b suggested a for task uncertainty: when the task is not uncertain, empow-
direct link between empowering leadership and team perfor- ered teams perform worse. When the task is highly uncertain,
mance. We found no significant link between those two vari- empowered teams perform better.
246 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 53, NO. 2, MAY 2006
systems software) to validate our findings. One intriguing aspect Empowering Leadership: Encourage Self Development
of our taking a knowledge perspective on team leadership and (1–5 scale, range: definitely not true to definitely true)
team performance is that our results have relevance to a broader My team leader encourages me to learn new things.
segment of teams engaged in knowledge work. Recent research My team leader encourages me to seek out opportunities to
on software teams [16], [29] that has taken a knowledge team learn.
perspective has similarly stressed the relevance of their findings My team leader encourages me to develop my skills and
to teams such as consulting, legal, and fast response settings abilities.
where knowledge is distributed and the task uncertain. My team leader encourages me to learn by extending my-
self.
VI. CONCLUSION My team leader encourages me to develop myself.
Researchers have long called for more research on manage- Empowering Leadership: Encourage Team Work
rial aspects of software development [22], [78], software project (1–5 scale, range: definitely not true to definitely true)
management [19], software team coordination [16], and soft- My team leader encourages me to work together with other
ware team control [17]. Leadership of software development individuals who are part of the team.
teams has seen little attention since the pioneering investiga- My team leader encourages cooperation among members
tions of Weinberg [31] and Mantei [32] well over two decades of the team.
ago. The research reported here focuses on team leadership as My team leader urges me to work as a team with other
an important factor in IS project teams and is an answer to these individuals who are part of the team.
calls. The results support the contention of early IS researchers My team leader emphasizes the importance of working to-
regarding the importance of studying leadership as a core factor gether for a common goal.
affecting all aspects of teamwork and performance [32]. My team leader advises me to coordinate my efforts with
This research improves our understanding of the importance other individuals who are part of the team.
of leadership, especially empowering leadership, for team per- Empowering Leadership: Participative Goal Setting
formance. It provides an explanation for the inconclusive find- (1–5 scale, range: definitely not true to definitely true)
ings that have left practitioners with little guidance as to what My team leader and I sit down together and reach agree-
leadership type is more effective in software development. By ment on my performance goals.
demonstrating the importance of leadership over and above the My team leader works with me to develop my performance
impact of administrative coordination mechanisms as well as goals.
specifying the contingent nature of empowering leadership, this My team leader and I work together to decide what my
research has contributed by extending early conceptualizations performance goals should be.
of software team leadership and shed light on previously contra- Administrative Coordination. Rate the coordination mech-
dictory findings on how best to manage software teams. Future anisms listed below according to the extent of their use on the
studies of IS project teams may benefit from a deeper investiga- project.
tion of the leadership factors uncovered in this research. (5 point scale; range: to a small extent—to a great extent)
formal policies and procedures for coordinating the team’s
work;
APPENDIX project milestones and delivery schedules;
CONSTRUCT DESCRIPTION project documents and memos;
Directive Leadership: Instruction and Command regularly scheduled team meetings;
(1–5 scale, range: definitely not true to definitely true) requirements/design review meetings;
When it comes to my work, my team leader gives me in- design inspections.
structions on how to carry it out. Team Performance. Compared to other software teams you
My team leader gives me instructions about how to do my are familiar with:
work. (1–5 scale; range: well below average—well above average;
My team leader provides commands in regard to my work. given only to stakeholders)
Directive Leadership: Reprimand the team’s adherence to schedules;
(1–5 scale, range: definitely not true to definitely true) the team’s adherence to budgets;
My team leader reprimands me when my performance is extent to which the system meets the design objectives.
not up to par.
When my work is not up to par, my team leader points it REFERENCES
out to me. [1] C. Benko and F. W. McFarlan, Connecting the Dots: Aligning Projects
My team leader lets me know about it when I perform With Objectives in Unpredictable Times. Boston, MA: Harvard Bus.
poorly. School Press, 2003.
[2] PMI Project Management Factbook, 2nd ed. Newton Square, PA:
Directive Leadership: Assigned Goals Project Manage. Inst., Inc., 2001.
(1–5 scale, range: definitely not true to definitely true) [3] W. W. Gibbs, “Software’s chronic crisis,” Sci. Amer., pp. 86–95, 1994.
My team leader establishes my performance goals. [4] C. Jones, Applied Software Measurement. New York: McGraw-Hill,
1996.
My team leader sets the goals for my performance. [5] K. H. Moller and D. J. Paulish, Software Metrics. London, U.K.:
My team leader establishes the goals for my work. Chapman & Hall, 1993.
248 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 53, NO. 2, MAY 2006
[6] E. Oz, “When professional standards are lax: The CONFIRM failure [39] S. S. Kahai, J. J. Sosik, and B. J. Avolio, “Effects of leadership style
and its lessons,” Commun. ACM, vol. 37, pp. 29–36, 1994. and problem structure on work group process and outcomes in an elec-
[7] J. S. Bozman, “United to simplify Denver’s troubled baggage project,” tronic meeting system environment,” Personnel Psychol., vol. 50, pp.
Computerworld, p. 76, 1994. 121–146, 1997.
[8] D. C. Johnston, At I.R.S., a system update gone awry. New York: New [40] H. P. J. Sims and C. C. Manz, Company of Heroes: Unleashing the
York Times, 2003. Power of Self-Leadership. New York: Wiley, 1996.
[9] B. Curtis, H. Krasner, and N. Iscoe, “A field study of the software [41] C. C. Durham, D. Knight, and E. A. Locke, “Effects of leader role,
design process for large systems,” Commun. ACM, vol. 31, pp. team-set goal difficulty, efficacy, and tactics on team effectiveness,”
1268–1287, 1998. Organizational Behavior Human Decision Processes, vol. 72, pp.
[10] S. Faraj and R. Geter, “Understanding software project failures,” in 203–231, 1997.
Proc. Amer. Inf. Syst. (AIS) Annu. Conf., 1998. [42] V. H. Vroom and A. G. Jago, The New Leadership: Managing Partici-
[11] L. J. Kirsch, “The management of complex tasks in organizations: Con- pation in Organizations. Englewood Cliffs, NJ: Prentice–Hall, 1988.
trolling the systems development process,” Org. Sci., vol. 7, pp. 1–21, [43] V. H. Vroom, “Leadership and the decision-making process,” Org. Dy-
1996. namics, vol. 28, pp. 82–94, 2000.
[12] F. P. Brooks, The Mythical Man-Month. Reading, MA: Addison- [44] R. J. House, “Path-goal theory of leadership: Lessons, legacy, and a
Wesley, 1975. reformulated theory,” Leadership Quart., vol. 7, pp. 323–352, 1996.
[13] T. DeMarco and T. Lister, Peopleware. New York: Dorset, 1987. [45] R. J. House and T. R. Mitchell, “Path-goal theories of leadership,” Con-
[14] P. J. Guinan, J. G. Cooprider, and S. Faraj, “Enabling software temporary Bus., vol. 3, pp. 81–98, 1974.
development team performance during requirements definition: A [46] C. A. Schriesheim, R. J. House, and S. Kerr, “Leader initiating struc-
behavioral versus technical approach,” Inf. Syst. Res., vol. 9, pp. ture: A reconciliation of discrepant research results and some empirical
101–125, 1998. tests,” Org. Behav. Human Performance, vol. 15, pp. 197–221, 1976.
[15] L. Wallace, M. Keil, and A. Rai, “How software project risk affects [47] C. C. Manz and H. P. Sims, Superleadership: Leading Others to Lead
project performance: An investigation of the dimensions of risk and an Themselves. Englewood Cliffs, NJ: Prentice–Hall, 1989.
exploratory model,” Decision Sci., vol. 35, pp. 289–321, 2004. [48] A. Bandura, Social Foundations of Thought and Action: A Social Cog-
[16] S. Faraj and L. Sproull, “Coordinating expertise in software develop- nitive Theory. Englewood Cliffs, NJ: Prentice-Hall, 1986.
ment teams,” Manage. Sci., vol. 46, pp. 1554–1568, 2000. [49] E. A. Locke and G. P. Latham, A Theory of Goal Setting and Task
[17] L. J. Kirsch, V. Sambamurthy, D.-G. Ko, and R. L. Purvis, “Controlling Performance. Englewood Cliffs, NJ: Prentice-Hall, 1990.
information systems development projects: The view from the client,” [50] S. Kerr and J. M. Jermier, “Substitutes for leadership: Their meaning
Manage. Sci., vol. 48, pp. 484–498, 2002. and measurement,” Organizational Behavior Human Performance, vol.
[18] S. Faraj, V. Sambamurthy, and P. J. Guinan, “Control strategies and 22, pp. 375–403, 1978.
performance of software development teams: The mediating role of [51] J.-P. Howell, P. W. Dorfman, and S. Kerr, “Moderator variables in lead-
experienced ambiguity,” Working Paper, 2005. ership research,” Acad. Manage. Rev., vol. 11, pp. 88–102, 1986.
[19] L. J. Kirsch, Software Project Management: An Integrated Perspective [52] S. Nidumolu, “The effect of coordination and uncertainty on software
for an Emerging Paradigm, R. W. Zmud, Ed. Cincinnati, OH: Pin- project performance: Residual performance risk as an intervening vari-
naflex Educational Resources, 2000, pp. 285–304. able,” Information Syst. Res., vol. 6, pp. 191–219, 1995.
[20] B. Curtis, Tutorial: Human Factors in Software Development. Los [53] R. E. Kraut and L. A. Streeter, “Coordination in software develop-
Angeles, CA: IEEE Computer Soc. Press, 1985. ment,” Commun. ACM, vol. 38, pp. 69–81, 1995.
[21] B. Schneiderman, Software Psychology. Cambridge, MA: Winthrop, [54] S. Conte, H. Dunsmore, and V. Shen, Software Engineering Metrics
1980. and Models. Readings, MA: Benjamin/Cummings, 1986.
[22] S. P. J. Brooks, “No silver bullet: Essence and accidents of software [55] A. H. Van de Ven, A. L. Delbecq, and R. Koenig, “Determinants of
engineering,” Computer, vol. 20, pp. 10–19, 1987. coordination mode within organizations,” Amer. Sociological Rev., vol.
[23] B. W. Boehm, “Improving software productivity,” Computer, pp. 41, pp. 322–338, 1976.
43–57, Sep. 1994. [56] N. Venkatraman and V. Ramanujan, “Planning system success: A con-
[24] D. Robey, D. L. Farrow, and C. R. Franz, “Group process and conflict ceptualization and an operational model,” Manage. Sci., vol. 33, pp.
in system development,” Manage. Sci., vol. 35, pp. 1172–1191, 1987. 687–705, 1987.
[25] M. L. Markus, “Power, politics and MIS implementation,” Commun. [57] C. L. Pearce and H. P. J. Sims, “Vertical versus shared leadership as
ACM, vol. 26, pp. 430–444, 1983. predictors of the effectiveness of change management teams: An ex-
[26] C. R. Franz and D. Robey, “An investigation of user-led system de- amination of aversive, directive, transactional, transformational, and
sign: Rational and political perspectives,” Commun. ACM, vol. 27, pp. empowering leader behaviors,” Group Dynamics, vol. 6, pp. 172–197,
1202–1209, 1984. 2002.
[27] J. C. Henderson and S. Lee, “Managing I/S design teams: A control [58] J. F. Cox and H. P. J. Sims, “Leadership and team citizenship be-
theories perspective,” Manage. Sci., vol. 38, pp. 757–777, 1992. havior: A model and measures,” Advances Interdisciplinary Studies
[28] D. B. Walz, J. J. Elam, and B. Curtis, “Inside a software design team: Work Teams, vol. 3, pp. 1–41, 1996.
Knowledge acquisition, sharing, and integration,” Commun. ACM, vol. [59] M. Withey, R. Daft, and W. Cooper, “Measures of Perrow’s work unit
36, pp. 63–77, 1993. technology: An empirical assessment and a new scale,” Acad. Manage.
[29] M. Hoegl and H. G. Gemuenden, “Teamwork quality and the success J., vol. 26, pp. 45–63, 1983.
of innovative projects: A theoretical concept and empirical evidence,” [60] C. F. Kemerer, “An agenda for research in the managerial evaluation
Org. Sci., vol. 12, pp. 435–449, 2001. of computer-aided software engineering tools impact,” in Proc. 22nd
[30] F. T. Baker, “Chief programmer team management of production pro- Annu. Hawaii Int. Conf. Syst. Sci., 1989, pp. 219–228.
gramming,” IBM Syst. J., vol. 11, pp. 56–73, 1972. [61] A. C. Edmondson, “Psychological safety and learning behavior in work
[31] G. M. Weinberg, The Psychology of Computer Programming. New teams,” Admin. Sci. Quart., vol. 44, pp. 350–383, 1999.
York: Van Nostrand Reinhold, 1971. [62] J. Cohen, Statistical Power Analysis for the Behavioral Sciences.
[32] M. Mantei, “The effect of programming team structures on program- Hillsdale, NJ: Lawrence Erlbaum, 1988.
ming tasks,” Commun. ACM, vol. 24, pp. 106–113, 1981. [63] D. G. Ancona and D. F. Caldwell, “Bridging the boundary: External ac-
[33] M. E. Shaw, Group Dynamics. New York: McGraw-Hill, 1981. tivities and performance in organizational teams,” Admin. Sci. Quart.,
[34] J. R. Hackman, Leading Teams. Boston, MA: Harv. Bus. School vol. 37, pp. 634–665, 1992.
Press, 2002. [64] K. J. Klein and S. W. J. Kozlowski, Multilevel Theory, Research, and
[35] C. L. Pearce and J. A. Conger, Shared Leadership: Reframing the Methods in Organizations. San Francisco, CA: Jossey-Bass, 2000.
How’s & Why’s of Leadership. Thousand Oaks, CA: Sage, 2003. [65] L. R. James, R. G. Demaree, and G. Wolf, “Estimating within-group
[36] C. C. Manz and H. P. Sims, “Leading teams to lead themselves: The interrater reliability with and without response bias,” J. Appl. Psychol.,
external leadership of self-managing work teams,” Admin. Sci. Quart., vol. 69, pp. 85–98, 1984.
vol. 32, pp. 106–128, 1987. [66] K. G. Jöreskog and D. Sörbom, LISREL8: Structural Equation Mod-
[37] C. L. Pearce, “The future of leadership: Combining vertical and shared eling With SIMPLIS Command Language, 2nd ed. Chicago, IL: Sci-
leadership to transform knowledge work,” Acad. Manage. Executive, entific Software, 1993.
vol. 18, pp. 47–59, 2004. [67] A. C. Edmondson, “Learning from mistakes is easier said than done:
[38] G. Yukl, Leadership in Organizations, 5th ed. Upper Saddle River, Group and organizational influences on the detection and correction of
NJ: Prentice-Hall, 2002. human error,” J. Appl. Behav. Sci., vol. 32, pp. 5–24, 1996.
FARAJ AND SAMBAMURTHY: LEADERSHIP OF INFORMATION SYSTEMS DEVELOPMENT PROJECTS 249
[68] R. P. Bagozzi, Y. Yi, and L. W. Phillips, “Assessing construct validity the development of online knowledge communities, and the impact of IT on
in organizational research,” Admin. Sci. Quart., vol. 36, pp. 421–458, organizations. His work has appeared or is forthcoming in journals such as In-
1991. formation Systems Research, Management Science, MIS Quarterly, Journal of
[69] C. Fornell and D. F. Larcker, “Evaluating structural equations models Applied Psychology, Journal of Strategic Information Systems, and Information
with unobservable variables and measurement error,” J. Marketing Technology & People.
Res., vol. 18, pp. 39–50, 1981. Dr. Faraj received a Fulbright Award. He is an Associate Editor of Informa-
[70] N. Venkatraman, “The concept of fit in strategy research: Toward tion Systems Research and serves on the Editorial Board of Organization Sci-
verbal and statistical correspondence,” Acad. Manage. Rev., vol. 14, ence and Information and Organization. In addition, he is currently co-editing
pp. 423–444, 1989. the Special Issue of Organization Science on IT and Organizational Form and
[71] S. Yun, S. Faraj, and H. P. J. Sims, “Contingent leadership and effective- Function.
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. V. Sambamurthy received the Ph.D. degree from the
[73] C. L. Pearce, H. P. J. Sims, J. F. Cox, G. Ball, E. Schnell, K. A. University of Minnesota, Minneapolis, in 1989.
Smith, and L. K. Trevino, “Transactors, transformers and beyond: A He is the Eli Broad Professor of Information
multi-method development of a theoretical typology of leadership,” J. Technology and Executive Director of the Center for
Manage. Development, vol. 22, pp. 273–307, 2003. Leadership of the Digital Enterprise at the Eli Broad
[74] R. T. Keller, “Transformational leadership and the performance of Graduate School of Management, Michigan State
research and development project groups,” J. Manage., vol. 18, pp. University, East Lansing. He has researched issues
489–501, 1992. related to the impacts of CIO and top management
[75] B. M. Bass, Leadership and Performance Beyond Expectations. New team characteristics on firms’ success with IT
York: Free Press, 1985. assimilation, the impacts of institutional forces on
[76] P. Kennedy, A Guide to Econometrics. Cambridge, MA: MIT Press, organizational IT assimilation, and the capabilities
1985. associated with strategic leverage of IT. His work has been published in journals
[77] L. S. Aiken and S. G. West, Multiple Regression: Testing and Inter- such as MIS Quarterly, Information Systems Research, Management Science,
preting Interactions. Newbury Park, CA: Sage, 1991. Organization Science, Decision Sciences, and the IEEE TRANSACTIONS ON
[78] V. B. Basili and J. Musa, “The future engineering of software: A man- ENGINEERING MANAGEMENT.
agement perspective,” IEEE Comput., vol. 24, no. 1, pp. 90–96, 1991. 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
Samer Faraj received the M.S. degree in technology for the Journal of Strategic Information Systems.
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,