624 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 35, NO.

5, SEPTEMBER/OCTOBER 2009

Impact of Budget and Schedule Pressure on

Software Development Cycle Time and Effort
Ning Nan and Donald E. Harter, Member, IEEE

Abstract—As excessive budget and schedule compression becomes the norm in today’s software industry, an understanding of its
impact on software development performance is crucial for effective management strategies. Previous software engineering research
has implied a nonlinear impact of schedule pressure on software development outcomes. Borrowing insights from organizational
studies, we formalize the effects of budget and schedule pressure on software cycle time and effort as U-shaped functions. The
research models were empirically tested with data from a $25 billion/year international technology firm, where estimation bias is
consciously minimized and potential confounding variables are properly tracked. We found that controlling for software process, size,
complexity, and conformance quality, budget pressure, a less researched construct, has significant U-shaped relationships with
development cycle time and development effort. On the other hand, contrary to our prediction, schedule pressure did not display
significant nonlinear impact on development outcomes. A further exploration of the sampled projects revealed that the involvement of
clients in the software development might have “eroded” the potential benefits of schedule pressure. This study indicates the
importance of budget pressure in software development. Meanwhile, it implies that achieving the potential positive effect of schedule
pressure requires cooperation between clients and software development teams.

Index Terms—Cost estimation, time estimation, schedule and organizational issues, systems development.

1 INTRODUCTION

R APID advances in technology have enabled more and

more individuals and companies to compete in the
global marketplace [1], [2], [3]. To succeed, companies must
constantly look for new ways to act faster and incur less cost
than other players in the business. Software companies are
not exceptions. Globalization, outsourcing and open-source
movements have intensified the competition in the software
industry [4], [5], [6], [7]. To succeed, software companies
strive to get their jobs done faster for less money.
Consequently, schedule and budget compression has
become the norm in today’s software industry [8].
In this study, we attempt to understand how the pressure
created by budget and schedule compression affects the
actual cycle time and cost of software development.
Particularly, we intend to see whether improved software
schedule and cost can be achieved with proper management
of the budget and schedule pressure. An understanding of
when and how budget and schedule pressure will positively
(or negatively) affect cycle time and cost of software
development projects enables managers to rationalize their
budget and schedule setting policies. More importantly,
software management can leverage the beneficial effect of
budget or schedule pressure on software development to
gain more competitive advantage in the global market.
. N. Nan is with the Price College of Business, University of Oklahoma,
307 West Brooks, Norman, OK 73019. E-mail: nnan@ou.edu.
. D.E. Harter is with the Whitman School of Management, Syracuse
University, 721 University Avenue, Syracuse, NY 13244.
E-mail: dharter@syr.edu.
Manuscript received 28 July 2007; revised 3 July 2008; accepted 17 Feb. 2009;
published online 20 Mar. 2009.
Recommended for acceptance by D. Rombach.
For information on obtaining reprints of this article, please send e-mail to:
tse@computer.org, and reference IEEECS Log Number TSE-2007-07-0229.
Digital Object Identifier no. 10.1109/TSE.2009.18.
0098-5589/09/$25.00 ß 2009 IEEE
Authorized licensed use limited to: Sreenidhi Institute of Science & Technology. Downloaded on November 5, 2009 at 04:49 from IEEE Xplore. Restrictions apply.
In activities such as sales or sawmill operation, organiza-
tion researchers have long recognized a potential positive
effect of job-related pressure on task performance [9], [10],
[11], [12], [13], [14]. Compared with work examined by
organizational studies, software development is different in
that it tends to have higher level of uncertainty and
variability [15]. The distinct characteristics may confound
the effect of pressure on performance. For example, knowing
that management might reduce a software development
team’s estimate, a team could increase its estimate by a safety
factor (i.e., “padding”) [8]. Such practice is enabled, and
maybe encouraged, by the uncertainty of software develop-
ment. The estimation bias diminishes effects of schedule or
budget pressure because it creates artificial resource com-
pression without actually increasing the task demand. In
addition, product size, process maturity, and software
complexity may vary substantially across different projects.
The variability of software development has caused incon-
sistent results about the effect of schedule pressure on project
cost (e.g., among [16], [17], [18], [19]). Given the special
characteristics of software development, a study with proper
control of the confounding variables is needed to evaluate
the applicability of the positive effect of pressure identified in
the organizational studies to software management.
Furthermore, our concern with effects of pressure is
motivated by the uneven research attention paid to schedule
versus budget pressure. Compared with the literature on
schedule pressure, budget pressure has received little
attention. Extant studies often view budget as a fixed value
(e.g., [20] and [21]). However, it’s very likely for software
clients to reduce a vendor’s estimated budget during contract
negotiation. This warrants a study looking at effects of
budget pressure to identify the beneficial or excessive range
of budget compression.
Published by the IEEE Computer Society
NAN AND HARTER: IMPACT OF BUDGET AND SCHEDULE PRESSURE ON SOFTWARE DEVELOPMENT CYCLE TIME AND EFFORT
By borrowing insights from organizational studies, we
propose nonlinear relationships between budget and
schedule pressure and development outcomes. With data
collected on software projects from a $25 billion/year
international technology firm, this study empirically tests
the relationship between budget and schedule pressure and
project performance. The data set had adequate information
to control for several critical confounding variables, such as
the estimation bias, product size, process maturity, software
complexity, and conformance quality.
The scope of the current study is described by the
following concepts and research questions. Budget and
schedule pressure is defined by the discrepancy between
budget and schedule estimated by the development team
and those negotiated with the client. Software development
refers to all the stages starting from initial design through
final product acceptance testing. Based on the tradition of
software engineering research, the cost of software devel-
opment is measured by the total number of person months
logged by the development team [22] and is referred to as
development effort throughout this paper. Cycle time, or
project duration, is measured by the calendar months
elapsed from the first day of design to final customer
acceptance of the product. Our research question is: What is
the impact of budget and schedule pressure on software
development cycle time and effort controlling for software
process, size, complexity, and conformance quality?
The rest of the paper is organized as follows: In the next
section, we review the software engineering literature about
the pressure-performance relationship. In Section 3, we
develop the theoretical foundation and hypotheses of this
study. Section 4 describes our research method. Section 5
presents the statistical analysis and results. Section 6
examines the results. In the last section, we discuss
conclusions of the study.
2 LITERATURE REVIEW
In the software engineering literature, researchers have long
recognized the critical impact of resource constraints (e.g.,
project schedule or budget) on software development
outcomes. Particularly, with respect to project schedule, a
stream of research has shed light on its effects on
development cycle time or effort. For example, in The
Mythical Man-Month, Brooks pointed out that schedule and
manpower were not interchangeable because software
developer productivity may deviate significantly from a
constant rate as complexity of software projects increases.
He stated the viewpoint as Brooks’ Law: “adding man-
power to a late software project makes it later” [19]. With
Brooks’ Law as the underlying assumption, Putnam
proposed a trade-off function between time and effort in
the Rayleigh curve model [17]. The function indicates that
any compression of schedule has to be compensated by an
increase of effort to maintain the same project cost.
Similarly, the COnstructive COst MOdel (COCOMO) [18]
predicted that there existed an optimal schedule value; any
compression or lengthening from the optimum would lead
to higher cost. Together, Brook’s Law, Putnam’s Rayleigh
curve model, and COCOMO represent the early “trade-off”
view about impacts of project schedule. As summarized by
Authorized licensed use limited to: Sreenidhi Institute of Science & Technology. Downloaded on November 5, 2009 at 04:49 from IEEE Xplore. Restrictions apply.
625
Jeffery [16], these early studies concerned the sensitivity of
project cost to variation in overall elapsed development
time (including both schedule compression and expansion).
Although they disagreed on the effect of schedule expan-
sion on project cost, all three studies predicted “increased
total effort when the manager’s constraint on elapsed time
available for development is compressed below the ‘opti-
mum’” [16, p. 852].
Subsequent studies in the literature offered more insights
into the effect of schedule compression on software develop-
ment. For example, Jeffery [16] questioned the general-
izability of the negative effect of schedule compression
predicted by earlier studies. By analyzing data from
commercial software projects in Australia, he found that a
compressed schedule could lead to either increased or
decreased development effort. Following Jeffery’s work,
Kitchenham [23] found similar results by analyzing another
data set from a European software project. Moreover, by
reanalyzing the data set behind COCOMO, she found that
there were schedule-compressed projects that were also
effort compressed, although COCOMO predicted a negative
relationship between the two. These studies attributed the
contradictory findings to difference among research sites,
variation among measures of schedule pressure, and missing
control variables in the relationship between schedule
pressure and development effort [16], [23]. In general, these
subsequent studies enriched our understanding of the
relationship between schedule pressure and development
outcomes. Empirically, we see that reduced schedule is not
always achieved at the expense of increased effort; a proper
level of schedule pressure may have beneficial effects on
project outcomes.
In recent years, a few studies have tried to explain the
underlying mechanisms of the impact of schedule pressure.
For example, Austin [24] employed an agency framework to
characterize the strategic behavior of software developers
under schedule pressure. He reduced the concern of soft-
ware developers to two main aspects: 1) being singled out as
the only one who cannot finish task on time and 2) being
penalized for taking quality compromising shortcuts.
Results derived from the mathematical model indicate that
contrary to casual intuition, schedule pressure could
maintain or even improve software project performance.
The underlying mechanism was that software developers
took quality impairing shortcuts to avoid being singled out
as the only few who could not meet deadlines. Very tight
schedules made it impossible for anyone to meet deadlines.
When software developers did not worry about being
singled out, they would be less likely to take shortcuts and
concern more about quality improvement. Higher quality
incurred less rework, and thereby, reduced development
cycle time and effort [25], [26], [27].
Using a system dynamics model, Abdel-Hamid et al.
[28], [29], [30], [31] proposed multiple causal pathways
between schedule pressure and software development
outcomes. They recognized that schedule pressure not only
had a direct impact on productivity by driving developers
to work long hours but also produced an indirect impact by
affecting the error generation rate of a project. Results from
the system dynamics model suggested that contrary to
626
Brooks’ Law, adding more people to a late project did not
always make it completed later; only aggressive compres-
sion of schedule could cause higher development effort and
longer cycle time.
Compared with studies about schedule pressure, re-
search on budget pressure is rather scanty in the software
literature. Budget constraint is usually discussed as a given
condition (e.g., [20] and [21]) or a value to be minimized
subject to certain outcomes (e.g., [32]). The few exceptions
only provide brief arguments about possible impacts of
budget compression without performing any formal ana-
lysis. For example, the gap between original estimate and
current budget is discussed as one of the questions for
software feasibility review [33]. In addition, budget
compression is briefly mentioned as a potential cause of
higher development cost [34].
The software literature is summarized in Table 1. Taken
together, the literature has three important implications.
First, the impact of schedule constraint on project outcomes
is nonlinear. Particularly, depending on the degree of
schedule compression, schedule pressure may have either
positive or negative effect on development cycle time and
Authorized licensed use limited to: Sreenidhi Institute of Science & Technology. Downloaded on November 5, 2009 at 04:49 from IEEE Xplore. Restrictions apply.
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 35, NO. 5, SEPTEMBER/OCTOBER 2009
TABLE 1
Summary of the Software Literature
effort. Second, due to difference in research sites and
measures, empirical findings alone may be inconclusive
(see the discussion in [16]). Thus, theoretical explanation of
the underlying mechanisms is warranted to improve the
generalizability of previous findings. Although the recent
studies have offered some theoretical insights, there is a
need for more fine-grained understanding about the
fundamental forces beneath the nonlinear relationship
between pressure and job performance. Third, there is a
knowledge gap regarding the impact of budget pressure on
software development outcomes. While clients commonly
reduce a development team’s proposed budget during
project negotiation, the impact of budget pressure has not
been sufficiently addressed in the literature.
To formally characterize the nonlinear impact of schedule
pressure and explore the effect of budget pressure, we borrow
insights from organizational studies. Researchers have
identified fundamental forces underlying the relationship
between job-related pressure and employee performance
[35]. The fundamental forces are an employee’s natural
responses to stress such as budget or schedule pressure. The
aggregation of the fundamental forces can generate a
NAN AND HARTER: IMPACT OF BUDGET AND SCHEDULE PRESSURE ON SOFTWARE DEVELOPMENT CYCLE TIME AND EFFORT
nonlinear relationship between pressure and performance
[9], [10], [11], [36], [37], [38], [39], [40], [41], [42], [43].
3 THEORETICAL DEVELOPMENT
Nearly a century ago, researchers found that performance
could increase with intensity of task demand, but only to a
certain point [9]. When intensity of task demand became too
high, performance would decrease. Overall, optimal per-
formance tended to occur at an intermediate level of task
demand while very low or very high level of task demand
often led to poor performance. This nonlinear relationship
between task demand and performance is often referred to
as Yerkes-Dodson Law.
Organization researchers have shown the generalizabil-
ity of Yerkes-Dodson Law to the relationship between job-
related pressure (e.g., budget or schedule pressure) and
employee performance [35]. For example, drawing on the
theoretical framework of Yerkes-Dodson law, Singh [35]
hypothesized curvilinear impacts of role stressors (i.e., role
conflict, ambiguity, and overload) on salespeople job
outcomes such as performance, job tension, and satisfac-
tion. Empirical data from a range of small and large firms
supported the curvilinear effect of role stressors on
salespeople job tension. Meanwhile, in a field experiment
about sawmill workers, researchers found that both work
underload (e.g., mechanically controlled work pact, repeti-
tion of short-cycle operations) and overload (e.g., piece-
rate rush and high demands of attention) could cause long-
term negative effects on workers’ well-being, health, and
job satisfaction. Once workers were given control of the
pace and methods of their work, they experienced a
moderate level of pressure and showed significantly better
health and job satisfaction results. Moreover, in a labora-
tory experiment, researchers varied the level of goal
difficulty in a perceptual speed test. They found that the
relationship between performance and goal difficulty
changed from positive to negative as researchers raised
the goal difficulty level [44].
In general, the applicability of Yerkes-Dodson law is
based on the understanding of the mechanisms behind the
nonlinear relationship between pressure and performance.
Researchers have realized that employees’ fundamental ego-
needs, such as challenge and pride in their work, mediate the
pressure-performance relationship [14]. They see that a low
level of job-related pressure often means a lack of challenge.
When employees (e.g., software developers) cannot fulfill
their fundamental need for challenge, they tend to be
inattentive and bored and, thus, do not perform well [45],
[46]. On the other hand, a high level of pressure often creates
too much challenge for employees to handle. Their pride in
work may be threatened [14]. Consequently, they tend to feel
anxious and frustrated and, hence, perform poorly. Only
under an intermediate level of pressure, employees are more
likely to fulfill both needs for challenge and pride in work.
Optimal performance usually follows the fulfillment of
fundamental ego-needs.
Goal setting theory (see [47] for a review) implies another
mechanism for the nonlinear relationship between pressure
and job performance. A goal is the object or aim of a job
(e.g., to complete a software product) with a specified
Authorized licensed use limited to: Sreenidhi Institute of Science & Technology. Downloaded on November 5, 2009 at 04:49 from IEEE Xplore. Restrictions apply.
627
amount of resources (e.g., time and budget) [47]. Higher
budget or schedule pressure means more difficult goals
[48], [49]. A major implication of the goal setting theory is
that goal acceptance interacts with goal difficulty and leads
to a nonlinear relationship between goal difficulty and job
performance [44]. Specifically, goal acceptance is negatively
related to goal difficulty, with the transition from accep-
tance to rejection usually occurring at an intermediate level
of goal difficulty. Goal difficulty has a positive effect on
performance for accepted goals and a negative effect on
performance for rejected goals. Overall, performance first
increases with goal difficulty and then levels off or
decreases when goals are too difficult to be accepted.
Optimal job performance usually occurs under an inter-
mediate level of pressure.
Previous research has extended the pressure perspec-
tives from an individual level to a team level. For example,
numerous studies have shown that individual-level goal
setting effects can be generalized to teams [47], [50], [51],
[52]. The resemblance between individual and team-level
pressure effects is most evident when teams are temporarily
assembled and each member’s expected and actual con-
tribution is identifiable. Temporarily assembled teams are
exempted from confounding effects of a number of team
contextual variables such as team history or team culture
[51]. Meanwhile, visibility of individual member’s expected
and actual contribution prevents social loafing [53], which
may cause deviation in a team’s reaction to pressure due to
the individual members’ lack of effort [51].
In this study, we extend the nonlinear relationship
between pressure and performance from an individual level
to a team level. This extension is based on two premises. First,
in the software industry, an essential strategy of project
management is the contracting of IS professionals on a
temporary basis [54]. This strategy helps organizations to
remain responsive to economic and technological changes by
reducing the fixed cost of permanent staff [55], [56]. It makes
temporarily assembled software development teams very
common in the software industry. As discussed above,
temporary teams are less affected by team contextual
variables and, therefore, are more likely to show a nonlinear
pressure-performance relationship similar to that on an
individual level. Second, the basic methodology of software
programming is divide-and-conquer, that is, dividing the
overall task into parts and working on each part individually
[57]. The divide-and-conquer method makes each team
member’s expected and actual contribution identifiable.
Thus, the confounding effect of social loafing on the
pressure-performance relationship is minimized.
In summary, the organizational studies provide fine-
grained understanding of mechanisms underlying the
nonlinear relationship between pressure and performance.
They have indicated the generalizability of the nonlinear
relationship to studies about effects of continuous task
demand, such as budget or schedule pressure, on project
team performance.
3.1 Hypotheses
In the software development context, better performance is
indicated by shorter cycle time and less development effort.
Based on the nonlinear view, shortest cycle time and lowest
628
development effort tend to occur under an intermediate
level of budget or schedule pressure while longer cycle time
and higher development effort are associated with very low
or very high level of pressure. Overall, we propose
U-shaped relationships between budget/schedule pressure
and software development cycle time and effort. With the
U-shaped view between pressure and software develop-
ment performance outcomes, we hypothesized the follow-
ing answers to our research question regarding impacts of
budget or schedule pressure on software development cycle
time and development effort (see Table 2).
4 RESEARCH METHODOLOGY
4.1 Construct Measures
4.1.1 Budget and Schedule Pressure
In the scope of this study, we see three requirements for
effective measures of budget and schedule pressure. First,
according to their definition, proper measures should
indicate the discrepancy between development team-esti-
mated budget or schedule and the customer-negotiated
budget or schedule. Second, the literature on the pressure
effect implies that people have to first perceive the pressure
and then respond to it through their performance. As
Robert pointed out that “Software’s problems . . . are about
expectations established at the outset of a project much
more than they are about trouble that happens along the
way” [58, p. 19]. Therefore, measures should be taken at the
onset of a project rather than at the completion of it. Third,
they should be quantitatively comparable across projects
and teams. This requires a formula that can standardize and
quantify the pressure level of a development team.
The literature has not established a consistent measure
for budget or schedule pressure. Budget pressure, often
referred to as “budget constraint” or “cost constraint,” is
usually measured as the total amount of capital available to
a project (e.g., [18]). This measure does not reflect the
discrepancy between team-estimated budget and customer-
negotiated budget. Moreover, it is difficult to compare
budget constraints across projects.
Schedule pressure has been assessed by the elapsed time
of a project (e.g., [17], [18]), the ratio between actual elapsed
time and estimated elapsed time (e.g., [16]), the ratio
between scheduled completion date and forecasted com-
pletion date [30], or self-reported values by software
Authorized licensed use limited to: Sreenidhi Institute of Science & Technology. Downloaded on November 5, 2009 at 04:49 from IEEE Xplore. Restrictions apply.
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 35, NO. 5, SEPTEMBER/OCTOBER 2009
TABLE 2
Budget and Schedule Pressure Hypotheses
developers and managers [35]. None of these measures
fulfills the three requirements discussed above. The metrics
based on actual elapsed time [16], [17], [18] are post hoc
rather than ex ante. They do not indicate the pressure level
prior to performance. The self-reported values [35] depend
on people’s subjective opinions. It is difficult to compare
personal assessments across development teams.
Due to a lack of established measures of budget or
schedule pressure, we developed an ex ante measure of
pressure:
Budget Pressure ¼
Team-Estimated Budget  Customer-Negotiated Budget
;
Team-Estimated Budget
Schedule Pressure ¼
Team-Estimated Time  Customer-Negotiated Time
:
Team-Estimated Time
Budget refers to the number of person months of effort
allocated for a development project. Cycle time (or project
duration) is the number of calendar months elapsed from
the first day of design to final customer acceptance of the
product. At the research site, development teams first
proposed their estimated budget and cycle time with the
assistance of an estimation tool. During the negotiation
between the corporation and clients, the customer usually
reduced team-estimated budget, with an average reduction
of 9.5 percent but never an increase in the budget. The
customer was more flexible in negotiations on schedule.
The average schedule reduction was 11.6 percent, but with
both expansion and compression of schedules occurring in
negotiations. The customer-reduced budget and modified
cycle time are recorded in the final contracts after the
completion of negotiation with the client. The ratio of the
change to the budget or schedule to the original budget or
schedule is the measure of pressure. For example, if a team-
estimated budget is $10;000 but the negotiation reduces the
budget to $8;000, the budget pressure is 20 percent
(($10;000  $8;000Þ=$10;000 ¼ 0:2 or 20 percent). The nu-
merators of the two measures reflect the discrepancy
between team estimates and customer-negotiated budget
or cycle time. We use team-estimated budget or cycle time
as the denominator because taking the ratio between the
discrepancy and the initial team estimates can quantify and
standardize pressure levels across projects and teams.
NAN AND HARTER: IMPACT OF BUDGET AND SCHEDULE PRESSURE ON SOFTWARE DEVELOPMENT CYCLE TIME AND EFFORT
Precisely speaking, our measures of budget and
schedule pressure only capture the postestimation budget
and schedule compression. They do not account for budget
and schedule pressure that arises and evolves during a
software development project. Expectations established at
the beginning of a project can be a significant source of
variations in software development teams’ performance
during a project [58]. In this paper, we focus on the
postestimation budget and schedule compression while
acknowledging that the pressure occurring during a project
can provide a different perspective of the relationship
between pressure and performance.
4.1.2 Cycle Time
Cycle time is one dimension of the project performance. It is
the time to develop the software product, i.e., the number of
calendar months elapsed from the first day of design to
final customer acceptance of the product.
4.1.3 Development Effort
Development effort is another dimension of project perfor-
mance. In this study, the total number of person months
logged by the development team from initial design
through final product acceptance testing constitutes the
development effort.
4.1.4 Control Variables
Software conformance quality is defined as the extent to
which a software product meets quality standard and initial
customer specifications. Prior studies have found that
software conformance quality, usually measured by the
number of defects, affects the amount of rework. Subse-
quently, the amount of rework has a significant impact on
development cycle time and effort [25], [26]. Given the
importance of conformance quality in development perfor-
mance, we controlled for its effect in the data analysis. Here,
conformance quality is measured as the number of lines of
source code in the product divided by the sum of defects
found in system testing. Three stages of system testing using
a formal test plan were contractually mandated for all
products: vendor’s system testing, client system testing with
a sample database, and client stress testing with a production
database. Vendor testing was performed by a test group
independent of the development team. Client testing was
performed by the client’s technical and user community,
supported by a contractor with expertise in testing complex
systems. This measure of quality is the inverse of the defect
density [59] used in many previous quality studies. This
paper adopts the inverse defect density because it offers a
more intuitive understanding of the conformance quality
values: Higher values mean better conformance quality.
Product size has been recognized as a significant factor
in cycle time [60], [61] and development effort [62], [63]. In
this study, product size is measured by thousand lines of
source code in a product. All projects in this study used the
same language, ensuring comparability.
Past research indicated that process maturity [64], [65]
and product complexity [66], [67] have significant impacts
on software development performance. Process maturity is
measured by the SEI’s CMM level of maturity. The CMM
framework includes 18 key process areas such as quality
Authorized licensed use limited to: Sreenidhi Institute of Science & Technology. Downloaded on November 5, 2009 at 04:49 from IEEE Xplore. Restrictions apply.
629
assurance, defect prevention, peer review, and training [68].
The more CMM process areas that are adopted, the higher
the maturity level is.
Product complexity captures three important dimensions
of complexity: domain, data, and decision complexity [66]
(see the Appendix, which can be found on the Computer
Society Digital Library at http://doi.ieeecomputersociety.
org/10.1109/TSE.2009.18, for details). Domain complexity is
the level of functional complexity as determined by engineer-
ing from the user requirements specification. Data complex-
ity refers to the anticipated level of difficulty in developing
the system because of complicated data structures and
database relationships. Decision complexity measures the
degree of difficulty in the decision paths and structures
within the product. Software teams assessed the three
dimensions of product complexity using the criteria specified
in the Appendix, which can be found on the Computer
Society Digital Library at http://doi.ieeecomputersociety.
org/10.1109/TSE.2009.18. Each software product manager
was trained in the assessment of complexity by senior
management used in the estimation model [66]. The three
dimensions of complexity were assessed ex ante by the
software product manager, monitored by quality assurance
to ensure compliance with the estimation process, verified by
senior management for consistency with other projects, and
validated by an independent assessment of the client’s
technical staff and managers. The three scales of complexity
showed high intercorrelation. Scores of the product complex-
ity were computed by taking an average of the three
complexity scales.
4.2 Regression Models
We developed four research models to test the effects of
budget or schedule pressure on development cycle time
and effort of software projects. Their function forms are
the following:
CycleTime ¼ fðprocess maturity; size; complexity;
ðaÞ
quality; budget pressureÞ;
Effort ¼ fðprocess maturity; size; complexity;
ðbÞ
quality; budget pressureÞ;
CycleTime ¼ fðprocess maturity; size; complexity;
ðcÞ
quality; schedule pressureÞ;
Effort ¼ fðprocess maturity; size; complexity;
ðdÞ
quality; schedule pressureÞ:
4.3 Data Collection
To test the hypotheses, we collected cross-sectional data on
software projects performed by a $25 billion/year interna-
tional technology firm. The company contracts commercial,
international, and government clients. The software pro-
jects in our data set were developed for a material
requirements planning information system to manage spare
parts acquisition.
In the technology firm, assessment of process maturity
was performed by government auditors and corporate
630
personnel in divisions outside of systems integration. These
independent groups used the SEI’s CMM [68] to assess the
maturity of the firm’s software development and support-
ing activities. We collected process maturity data from these
independent groups.
Other data were collected by the technology firm and
were audited by the clients to ensure accuracy and
accountability. Cycle time data were retrieved from the
project management scheduling system. Effort data were
tracked by the corporate time reporting system. Software
defect data were extracted from the Configuration Manage-
ment (CM) database. Information related to the estimated,
budgeted, and actual duration and cost of software
development was manually coded from the electronic and
paper files maintained by the firm.
The technology firm provided an ideal site for this
research because its estimation method and management
strategies can help us eliminate alternative explanations of
the impacts of budget or schedule pressure on development
performance. First, by using the Software Productivity
Quality and Reliability (SPQR20) automated tool, the firm
minimized the “padding” effect. In software industry,
development teams often extend their “rational” estimates
of cycle time or cost by a safety factor to counteract the high
levels of pressure [8]. The magnitude of this padding effect
varies across project teams and is hard to assess. As a result,
many earlier research findings were confounded by the
padding effect. At our research site, development teams
estimated function point counts and complexity based on
user task requirement specification. These estimates were
validated by the client to ensure accurate interpretation of
the requirements. The function point counts, complexity,
and environmental variables were submitted to SPQR20 for
budget and schedule projection. SPQR20 provides a
consistent methodology for estimation of budget and
schedule, preventing distortion of the estimates.
To ensure estimation accuracy with SPQR20, develop-
ment teams used historical data to calibrate budget and
schedule projections. Senior management examined the
accuracy of the methodology annually prior to estimation
of the next year’s product development. Historically, the
estimation tool underestimated budget by 6.2 percent, i.e.,
the teams averaged 6.2 percent budget overruns compared
to estimates. The calibration of SPQR20 with the organiza-
tion’s historical data ensured that development team
productivity was accurately reflected in the model estimates.
Furthermore, the technology firm implemented a series
of management practices to prevent bias in software
schedule and cost estimates. These practices corresponded
to the bias reduction strategies identified by Peeters and
Dewey [69]. Each of these practices was performed in the
estimation of schedule and budget by the firm during the
time frame of the study. Table 3 summarizes the strategies
recommended by Peeters and Dewey [69] and how the
technology firm implemented the corresponding practices.
We found 66 projects with suitable data for the study of
budget and schedule pressure (see Table 4 for the descriptive
statistics, and the Appendix, which can be found on the
Computer Society Digital Library at http://doi.ieeecompu-
tersociety.org/10.1109/TSE.2009.18, for the correlation ma-
trix). The sample size of our study is comparable to previous
studies about software development. In a recent study,
Authorized licensed use limited to: Sreenidhi Institute of Science & Technology. Downloaded on November 5, 2009 at 04:49 from IEEE Xplore. Restrictions apply.
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 35, NO. 5, SEPTEMBER/OCTOBER 2009
Agrawal and Chari [67] reviewed 18 published software
studies and found a median sample size of 37 (see the study
for more detail).
5 ANALYSIS AND RESULTS
To test the existence of the U-shaped pressure-performance
relationship, we included quadratic terms of budget or
schedule pressure as independent variables in the statistical
models. This method has been proved effective by previous
studies (e.g., [70]). Researchers have found economies and
diseconomies of scale [61] in software development. As a
result, a log-log relationship has generally been used to study
software effort and cycle time. The appropriateness of a log-
log model to our data set is further supported by the
Davidson and MacKinnon’s specification test for non-nested
models (J-test) [71]. The J-test result shows that a log-log
model is preferred over semilog and linear models. In the log-
log model, we did not take log-transformation of the pressure
terms because it is possible for budget or schedule pressure
values to be 0 or negative. Moreover, since our models focus
on the U-shaped relationship between pressure, effort and
cycle time, we operationally define the U-shaped function
using a quadratic term. In this formulation, taking the
logarithm of a quadratic would simply reduce it to twice
the linear term. The specific regression models for budget
pressure analysis are the following:
ln ðCycle T imeÞ ¼ 01 þ 11 ln ðprocess maturityÞ
þ 21 ln ðproduct sizeÞ þ 31 ln ðcomplexityÞ
ð1Þ
þ 41 ln ðconformance qualityÞ
þ 51 ðbudget pressureÞ þ 61 ðbudget pressureÞ2 ;
ln ðEffortÞ ¼ 02 þ 12 ln ðprocess maturityÞ
þ 22 ln ðproduct sizeÞ þ 32 ln ðcomplexityÞ
ð2Þ
þ 42 ln ðconformance qualityÞ
þ 52 ðbudget pressureÞ þ 62 ðbudget pressureÞ2 :
The statistical models for schedule pressure analysis are
the following:
ln ðCycle T imeÞ ¼ 03 þ 13 lnðprocess maturityÞ
þ 23 ln ðproduct sizeÞ þ 33 ln ðcomplexityÞ
ð3Þ
þ 43 lnðconformance qualityÞ
þ 53 ðschedule pressureÞ þ 63 ðschedule pressureÞ2 ;
ln ðEffortÞ ¼ 04 þ 14 ln ðprocess maturityÞ
þ 24 ln ðproduct sizeÞ þ 34 ln ðcomplexityÞ
ð4Þ
þ 44 ln ðconformance qualityÞ
þ 54 ðschedule pressureÞ þ 64 ðschedule pressureÞ2 :
The models were initially tested with ordinary least
squares (OLS). However, because data in this study are all
from the same company, it may be possible that the error
terms are correlated as a result of some common effect. A
Breusch-Pagan test of independence indicated that the error
terms are significantly correlated for both the budget pressure
equations ((1) and (2)) (2 ¼ 5:29; p ¼ 0:02) and the schedule
NAN AND HARTER: IMPACT OF BUDGET AND SCHEDULE PRESSURE ON SOFTWARE DEVELOPMENT CYCLE TIME AND EFFORT 631

TABLE 3
Bias Reduction Strategies

TABLE 4
Descriptive Statistics

pressure equations ((3) and (4)) (2 ¼ 14:96; p ¼ 0:00).
Therefore, we estimated the seemingly unrelated regres-
sion (SURE) parameters using a feasible generalized least
squares (FGLS). Tables 5 and 6 display SURE estimates for
the budget pressure models ((1) and (2)) and the schedule
pressure models ((3) and (4)), respectively.
We performed Cook’s Distance test [72] with 1 as the
threshold to look for outliers and influential points in both
budget and schedule pressure data samples. The results
indicated that no outlier existed in the schedule pressure
data and four outliers existed in the budget pressure data.
To ensure the validity of the test results, we removed the
outliers and performed statistical tests on the budget and
schedule pressure data sample. The normality assumption
was not rejected using the Kolmogorov-Smirnov test [73].
No evidence was found of heteroskedasticity using White’s
[74] test. Multicollinearity of explanatory variables was
tested using the condition index and variance inflation

Authorized licensed use limited to: Sreenidhi Institute of Science & Technology. Downloaded on November 5, 2009 at 04:49 from IEEE Xplore. Restrictions apply.
632 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 35, NO. 5, SEPTEMBER/OCTOBER 2009

TABLE 5
Parameter Estimates of the Budget Pressure Models

factor. All condition indexes and variance inflation factors
were within acceptable ranges.
The results suggest strong support for our hypothesized
U-shaped relationship between budget pressure and devel-
opment cycle time. As shown in Table 5, there is a positive
and significant coefficient (61 ¼ 11:38; p ¼ 0:05) for the
quadratic term and a negative and significant coefficient
(51 ¼ 3:80; p ¼ 0:02) for the linear term of budget pres-
sure in the cycle time equation (1). The statistical results
indicate that budget pressure has a significant U-shaped
effect on development cycle time. Thus, H1 is supported.
Statistical results also show strong support for our
hypothesized U-shaped relationship between budget pres-
sure and development effort. In Table 5, the coefficient for
the quadratic term in the effort equation (2) was positive and
statistically significant (62 ¼ 31:39; p ¼ 0:01). Meanwhile,
the coefficient for the linear budget pressure term in the
same equation was negative and significant (52 ¼ 12:23;
p ¼ 0:00). These results suggest that budget pressure has a
significant U-shaped effect on development effort. Hence,
H2 is supported.
The results do not support the U-shaped effect of
schedule pressure on development cycle time. Although
the coefficient of the linear schedule pressure term in (3) is
negative and significant (53 ¼ 0:43; p ¼ 0:01), the coeffi-
cient of the quadratic term in the cycle time equation (3) is
not significant (63 ¼ 0:25; p ¼ 0:40) (Table 6). The results
do not support H3 that predicts schedule pressure has a
significant U-shaped effect on software development cycle
time.
Finally, we did not find statistical support to the
hypothesized U-shaped relationship between schedule
pressure and development effort. As shown in Table 6,
the coefficient of the quadratic term in the effort equation
(4) is negative but not significant (64 ¼ 0:87; p ¼ 0:06).
Also, the linear pressure term in (4) is negative and not
significant (54 ¼ 0:43; p ¼ 0:07). The results do not sup-
port the U-shaped curve for H4.
In summary, we see that budget pressure has sig-
nificant U-shaped relationships with software develop-
ment cycle time and development effort, controlling for
software process, complexity, and conformance quality. In
contrast, schedule pressure does not show a significant

Authorized licensed use limited to: Sreenidhi Institute of Science & Technology. Downloaded on November 5, 2009 at 04:49 from IEEE Xplore. Restrictions apply.
NAN AND HARTER: IMPACT OF BUDGET AND SCHEDULE PRESSURE ON SOFTWARE DEVELOPMENT CYCLE TIME AND EFFORT 633

TABLE 6
Parameter Estimates of the Schedule Pressure Models

U-shaped relationship with development cycle time or
development effort.
6 DISCUSSION
To gain intuition of the nonlinear effect of budget pressure,
we plot the components of the linear and squared budget
pressure terms and their combined effect on log-trans-
formed cycle time and effort (see Figs. 1 and 2). The linear
representations of cycle time and effort appear in Figs. 3 and
4. As indicated in the figures, the negative linear term
initially reduces the cycle time and cost; the positive squared
pressure term eventually offsets any time and cost reduction
due to the linear term. The most significant improvement
due to budget pressure occurs in the range of 0-10 percent
pressure, identified as beneficial range in the figures. The
combined curves tend to flatten and become shallow over
10 percent, noted in the limited difference range. Excessive
budget compression results in rapidly increasing cycle time
and costs, shown as the excessive compression range.
The nonsignificant effect of schedule pressure is some-
what surprising. To further interpret the result, we examined
the estimates, contracts, and detailed activity schedules of
the sampled projects. An interesting finding is that user
involvement in the software development process might
have attenuated the improvement of development cycle time
in response to schedule pressure. Specifically, the clients of
the projects were involved in the development process by
conducting periodic reviews of the deliverables (e.g., design
specifications, test plans, and user manuals), formal life cycle
phase reviews (design, detailed design, code development,
and testing), and audits. This review and audit time ranged
from 10 to 20 percent of the product development schedule.
When comparing the client review time specified in the
estimates with the actual length shown in the schedule
charts, we noticed that clients never shortened their review
time even when the projects were under schedule pressure.
In addition, the client reviews generally appeared on the
critical path for the product schedules. The lack of elasticity
of client review time reduced the variability of the develop-
ment cycle time in response to schedule pressure. This
implies that achieving the potential positive effect of
schedule pressure requires cooperation between clients and
software development teams.
In contrast, the lack of effect of schedule pressure on
effort can be attributed to other causes. Specifically, when

Authorized licensed use limited to: Sreenidhi Institute of Science & Technology. Downloaded on November 5, 2009 at 04:49 from IEEE Xplore. Restrictions apply.
634
Fig. 1. Linear and squared component effects of budget pressure on
log(cycle time).
schedule pressure was not accompanied by significant
budget pressure, the project manager had the flexibility of
increasing manpower over a shorter period of time without
affecting the budget. For example, a project planned for five
months with four software developers, when shortened to
four months, could increase staff to five software devel-
opers, maintaining 20 person months of effort. The benefit
of schedule pressure on effort was negated by the increase
in staff by management.
Investigation into whether the performance of the
estimation tool affected the results reveals an interesting
pattern. For all projects, the estimation tool underestimated
projects, i.e., the average project resulted in a 6.2 percent
budget overrun compared to the original estimate. How-
ever, for projects with beneficial pressure, those with less
than 10 percent budget pressure, projects, on average,
experienced a 7.7 percent budget underrun. Projects with
more than 10 percent budget pressure had average budget
overruns of 18.8 percent.
Furthermore, to deepen our understanding of the
mechanisms underlying the observed pressure effects, we
examined development teams’ reaction to extremely high-
and low levels of budget and schedule reductions. At the
research site, management used the Earned Value approach
to track performance against the project baseline during a
software development project. The baseline is the planned
schedule and budget of the project from final negotiations.
The actual schedule and cost performance were monitored
Fig. 2. Linear and squared component effects of budget pressure on
log(effort).
Authorized licensed use limited to: Sreenidhi Institute of Science & Technology. Downloaded on November 5, 2009 at 04:49 from IEEE Xplore. Restrictions apply.
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 35, NO. 5, SEPTEMBER/OCTOBER 2009
Fig. 3. Effect of budget pressure on cycle time.
monthly against this baseline to determine if the project was
tracking to the planned schedule and budget. We utilize the
earned value charts generated during this management
process as the lens to open up development teams’ reaction
to budget and schedule compression.
Figs. 5 and 6 are the earned value charts for low- and
high- pressure projects, respectively. In the figures, planned
value (PV) is the dollar value of work scheduled. Earned
value (EV) is the actual value of work completed; actual cost
(AC) is the dollar expenditure that was used to accomplish
the work to date. The latest revised estimate (LRE) reflects
management projection of an underrun or overrun. The
contract line represents what was negotiated in the contract;
adjustments to the contract can occur when functionality is
changed, altering the contract value.
Fig. 5 is an earned value chart for a project with budget
pressure in the 0-10 percent range. Under the lower
pressure scenario, the AC exceeded the PV in the first
month, but the development team appeared to be motivated
by this cost overrun and able to recover in the second
month. In the sixth month, the EV lagged the PV, indicating
schedule slippage. Again, the team was able to correct
before the end of the project. The latest revised estimate was
stable, a sign that the development team was able to react
positively to any temporary schedule or cost slippage and
make adjustments throughout the life of a project to
accommodate low levels of pressure.
Under a higher pressure scenario, as seen in Fig. 6, the
effect of pressure on budget and schedule resulted in cost
and schedule overruns. In the figure, it appears that there
Fig. 4. Effect of budget pressure on effort.
NAN AND HARTER: IMPACT OF BUDGET AND SCHEDULE PRESSURE ON SOFTWARE DEVELOPMENT CYCLE TIME AND EFFORT
Fig. 5. Project with beneficial pressure.
were several points in time when the development team
recognized that schedule and budget goals were too
challenging to achieve, as indicated in changes in the
LRE line: after the first few months and again approxi-
mately 50 percent through completion of the project. The
problems were exacerbated by functional changes to the
product baseline late in the life cycle at months 13 and 14,
resulting in a final spiking of the LRE in month 14. Overall,
in this high pressure scenario, the development team’s
attempt to catch up with schedule or budget goals was
overwhelmed by the accumulated schedule and cost
overruns, which further discouraged the team’s effort to
make adjustment. Meanwhile, adding personnel late in the
project simply increased the cost overrun and further
delayed the schedule, consistent with Brook’s Law.
The statistical analysis and the follow-up investigation
offered several important implications to research and
practice. First, the finding about the development team’s
reaction to extremely low/high pressure implies the
generalizability of the theoretical development of this study
(i.e., the Yerkes-Dodson Law and its underlying mechan-
isms) to the software development context. For example, the
development team’s reaction to low levels of pressure
conforms to the goal setting theory [44] that, for acceptable
goals, goal difficulty has a positive effect on performance.
Meanwhile, high levels of pressure generate a negative
reaction because they create too much challenge for the
development team [14]. The finding about the development
team’s reaction also helps us gain deeper understanding of
previous studies on schedule pressure. For example,
Putnam’s Rayleigh curve model [17] might have captured
the negative reaction of management to high levels of
schedule pressure. At the same time, the seemingly contra-
dictory findings from Jeffery’s study [16] may be attributed
to the development team’s positive reaction to low levels of
schedule pressure. To practitioners, knowing that different
levels of budget or schedule pressure can generate dis-
tinctive reactions can help them anticipate and interpret
development team performance.
Second, the strong statistical support for the U-shaped
relationships between budget pressure and development
cycle time and effort suggests that in a software development
context, budget pressure may be a more robust indicator of
the impact of job-related pressure on performance. Schedule
pressure did not exhibit similar effect because its effect on
cycle time was reduced by the inelasticity of customer
review activities; the effect on manpower was offset by
Authorized licensed use limited to: Sreenidhi Institute of Science & Technology. Downloaded on November 5, 2009 at 04:49 from IEEE Xplore. Restrictions apply.
635
Fig. 6. Project with high pressure.
management’s ability to increase staffing when schedules
were reduced.
Furthermore, when previous studies imply a nonlinear
impact of resource constraints on software development
outcomes, results of this study suggest that such nonlinear
impacts can be formalized as a U-shaped function. Our data
analysis indicates that budget pressure has a positive
impact on software development performance when it is
within a beneficial range of 0-10 percent. Beyond this
beneficial range, there is a range of limited difference in the
effect of pressure as the cycle time and effort curves flatten.
The detrimental effects of extremely high levels of pressure
are evident when pressure continues to increase beyond
this range. To software management, the U-shaped view
and the beneficial or excessive range associated with it
provide valuable guidance for feasible budget and deadline
setting policies. Our results suggest that, with a properly
tightened budget, software management can save time and
manpower simultaneously. The reduced cycle time under
budget pressure is not offset by an increased workforce.
Management can use historical data to estimate the
beneficial range of budget pressure. With the knowledge
of beneficial pressure range, software management can be
more effective in contract negotiations.
The lack of support for the hypotheses regarding the
effect of schedule pressure reveals a unique requirement for
software projects to harvest positive effects of schedule
pressure: the cooperation between clients and software
development teams. Observation from our research site
indicates that clients may not sympathize with develop-
ment teams in schedule pressure. The behavior of clients
can diminish the effect of schedule pressure found in
previous studies. For future research about software
development schedule, this study implies the importance
of examining client involvement as a significant factor in
development cycle time. Meanwhile, for software manage-
ment, it is critical to motivate the clients to share schedule
pressure and cooperate with development teams in redu-
cing development cycle time.
When interpreting the results, we were aware of several
caveats. First, the results are based on data from a single
organization. This could affect the generalizability of the
findings, particularly the beneficial/excessive budget or
schedule ranges. However, pooling data from multiple
organizations could introduce confounding effects of
different estimation methods and different measures of
key variables. Moreover, structural and environmental
636 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,
variations of different organizations could confound the
relationship between pressure and software development
performance. Future research that pools data from multiple
organizations can seek to validate and extend the results of
this study by adequately controlling the confounding
variables discussed earlier. Second, the pressure measures
only capture the postestimation budget and schedule
compression rather than pressure arising during a project.
That prevented us from examining the dynamic impacts of
schedule and budget pressure throughout a project. In
future work, budget and schedule pressure can be
evaluated at several points during a development project.
An interesting question to examine is whether the effect of
pressure found in this study can be applied to later phases
of a project.
7 CONCLUSION
In this paper, we formalize the nonlinear effect of manage-
ment pressures on project performance as U-shaped
relationships. The relationships are tested with data from
a research site, where estimation bias is consciously
minimized and information about the potential confound-
ing effects such as software process, complexity, and
conformance quality is properly tracked. The data analysis
supports the U-shaped relationships between budget
pressure and software development cycle time and devel-
opment effort. On the other hand, hypotheses about the
U-shaped impacts of schedule pressure on development
cycle time and effort are rejected.
In the highly competitive software engineering industry,
companies are looking for ways to make software produc-
tion more efficient. The main contribution of this study is to
rigorously assess the possibility of achieving improved
cycle time and effort with proper management of pressure
in software development. The analysis suggests that there
exists a beneficial range of budget pressure. Such beneficial
effects may also be realized from schedule pressure if
software clients cooperate with development teams in
dealing with schedule compression. In addition to the
empirical findings, this study sheds light on the funda-
mental mechanisms underlying the U-shaped relationships
between development pressure and software performance.
By connecting software development with organizational
studies, this study not only helps to improve the general-
izability of related findings from the software literature
(e.g., [16], [17], [19], [23]) but also enriches the organiza-
tional literature by extending its theories to the software
context. For software management, the theoretical under-
standing as well as the empirical findings from this study
can help them attain more effective negotiation strategies,
deadline, and budget setting policies, which ultimately
adds to the competitive advantage of a software company.
ACKNOWLEDGMENTS
The authors would like to thank Dr. Dieter Rombach and
the three anonymous reviewers for their insightful com-
ments. They would also like to thank Tara Thomas for her
assistance in data collection.
Authorized licensed use limited to: Sreenidhi Institute of Science & Technology. Downloaded on November 5, 2009 at 04:49 from IEEE Xplore. Restrictions apply.
VOL. 35, NO. 5, SEPTEMBER/OCTOBER 2009
REFERENCES
[1] D. Burdick, “Celestica Transforms Competitiveness with
C-Commerce,” Gartner Case Study, Jan. 2000.
[2] D. Chatterjee, R. Grewal, and V. Sambamurthy, “Shaping Up for
E-Commerce: Institutional Enablers of the Organizational Assim-
ilation of Web Technologies,” MIS Quarterly, vol. 26, no. 2, pp. 65-
90, 2002.
[3] T.L. Friedman, The World Is Flat: A Brief History of the Twenty-First
Century. Farrar, Straus and Giroux, 2006.
[4] B. Fitzgerald, “The Transformation of Open Source Software,”
MIS Quarterly, vol. 30, no. 3, pp. 587-598, 2006.
[5] B. Ives and S.L. Jarvenpaa, “Applications of Global Information
Technology: Key Issues for Management,” MIS Quarterly, vol. 15,
no. 1, pp. 33-50, 1991.
[6] N. Levina and J.W. Ross, “From the Vendor’s Perspective:
Exploring the Value Proposition in Information Technology
Outsourcing,” MIS Quarterly, vol. 27, no. 3, pp. 331-364, 2003.
[7] K.J. Stewart and S. Gosain, “The Impact of Ideology on
Effectiveness in Open Source Software Development Teams,”
MIS Quarterly, vol. 30, no. 2, pp. 291-314, 2006.
[8] E. Yourdon, Death March: The Complete Software Developer’s Guide to
Surviving “Mission Impossible” Projects. Prentice Hall PTR, 1997.
[9] R.M. Yerkes and J.D. Dodson, “The Relation of Strength of
Stimulus to Rapidity of Habit Formation,” J. Comparative and
Neurological Psychology, vol. 18, pp. 459-482, 1908.
[10] W.E. Scott, “Activation Theory and Task Design,” Organizational
Behavior and Human Performance, vol. 1, pp. 3-30, 1966.
[11] R.A. Dienstbier, “Arousal and Physiological Toughness: Implica-
tions for Mental and Physical Health,” Psychological Rev., vol. 96,
no. 1, pp. 84-100, 1989.
[12] H. Anisman and Y. LaPierre, “Neurochemical Aspects of Stress
and Depression: Formulations and Caveats,” Psychological Stress
and Psychology, R.W. Neufeld, ed., McGraw-Hill, 1982.
[13] J. Schaubroeck and D.C. Ganster, “Chronic Demands and
Responsivity to Challenge,” J. Applied Psychology, vol. 78, no. 1,
pp. 73-85, 1993.
[14] M. Frankenhaeuser and B. Gardell, “Underload and Overload in
Working Life: Outline of a Multidisciplinary Approach,” J. Human
Stress, vol. 2, no. 3, pp. 35-46, 1976.
[15] R.W. Zmud, “Management of Large Software Development
Efforts,” MIS Quarterly, vol. 4, no. 2, pp. 45-55, 1980.
[16] D.R. Jeffery, “Time-Sensitive Cost Models in the Commercial MIS
Environment,” IEEE Trans. Software Eng., vol. 13, no. 7, pp. 852-
859, July 1987.
[17] L.H. Putnam, “A General Empirical Solution to the Macro
Software Sizing and Estimating Problem,” IEEE Trans. Software
Eng., vol. 4, no. 4, pp. 345-360, July 1978.
[18] B.W. Boehm, Software Engineering Economics. Prentice-Hall, 1981.
[19] F.P. Brooks, The Mythical Man Month: Essays on Software Engineer-
ing. Addison-Wesley, 1974.
[20] C.S. Raghavendra and S. Hariri, “Reliability Optimization in the
Design of Distributed Systems,” IEEE Trans. Software Eng., vol. 11,
no. 10, pp. 1184-1193, Oct. 1985.
[21] G. Ruhe and M.O. Saliu, “The Art and Science of Software Release
Planning,” IEEE Software, vol. 22, no. 6, pp. 47-53, Nov./Dec. 2005.
[22] Q. Hu, R.T. Plant, and D.B. Hertz, “Software Cost Estimation
Using Economic Production Models,” J. Management Information
Systems, vol. 15, no. 1, pp. 143-163, 1998.
[23] B.A. Kitchenham, “Empirical Studies of Assumptions That
Underlie Software Cost-Estimation Models,” Information and
Software Technology, vol. 34, no. 4, pp. 211-219, 1992.
[24] R.D. Austin, “The Effects of Time Pressure on Quality in Software
Development: An Agency Model,” Information Systems Research,
vol. 12, no. 2, pp. 195-207, 2001.
[25] K.T. Abdel-Hamid and E.S. Madnick, “Lessons Learned from
Modeling the Dynamics of Software Development,” Comm. ACM,
vol. 32, no. 12, pp. 1426-1455, 1989.
[26] W.S. Humphrey, A Discipline for Software Engineering. Addison-
Wesley, 1995.
[27] R.D. Banker, G.B. Davis, and S.A. Slaughter, “Software Develop-
ment Practices, Software Complexity, and Software Maintenance
Performance: A Field Study,” Management Science, vol. 44, no. 4,
pp. 433-451, 1998.
[28] K.T. Abdel-Hamid, “The Economics of Software Quality Assur-
ance: A Simulation-Based Case Study,” MIS Quarterly, vol. 12,
no. 3, pp. 395-411, 1988.
NAN AND HARTER: IMPACT OF BUDGET AND SCHEDULE PRESSURE ON SOFTWARE DEVELOPMENT CYCLE TIME AND EFFORT
[29] K.T. Abdel-Hamid, “The Dynamics of Software Projects Staffing:
A System Dynamics Based Simulation Approach,” IEEE Trans.
Software Eng., vol. 15, no. 2, pp. 109-119, Feb. 1989.
[30] K.T. Abdel-Hamid, K. Sengupta, and D. Ronan, “Software Project
Control: An Experimental Investigation of Judgment with Fallible
Information,” IEEE Trans. Software Eng., vol. 19, no. 6, pp. 603-612,
June 1993.
[31] K.T. Abdel-Hamid, K. Sengupta, and C. Swett, “The Impact of
Goals on Software Project Management: An Experimental
Investigation,” MIS Quarterly, vol. 23, no. 4, pp. 531-555, 1999.
[32] M.E. Helander, Z. Ming, and N. Ohlsson, “Planning Models for
Software Reliability and Cost,” IEEE Trans. Software Eng., vol. 24,
no. 6, pp. 420-434, June 1998.
[33] S. McConnell, “Feasibility Studies,” IEEE Software, vol. 15, no. 3,
pp. 119-120, May/June 1998.
[34] K. Srinivasan and D. Fisher, “Machine Learning Approaches to
Estimating Software Development Effort,” IEEE Trans. Software
Eng., vol. 21, no. 2, pp. 126-137, Feb. 1995.
[35] J. Singh, “Striking a Balance in Boundary-Spanning Position: An
Investigation of Some Unconventional Influences of Role Stressors
and Job Characteristics on Job Outcomes of Salespeople,”
J. Marketing, vol. 62, no. 3, pp. 69-86, 1998.
[36] M.G. Weinberg, The Psychology of Computer Programming. Van
Nostrand Reinhold Company, 1971.
[37] H. Selye, The Stress of Life. McGraw-Hill, 1956.
[38] R.G. Stennett, “The Relationship of Performance Level to Level of
Arousal,” J. Experimental Psychology, vol. 54, no. 1, pp. 54-62, 1957.
[39] R.N. Berry, “Skin Conductance Levels and Verbal Recall,”
J. Experimental Psychology, vol. 63, pp. 275-286, 1962.
[40] E. Duffy, Activation and Behavior. Wiley, 1962.
[41] J.E. McGrath, “Stress and Behavior in Organization,” Handbook of
Industrial and Organizational Psychology, M.D. Dunnette, ed.,
pp. 1351-1395, John Wiley, 1976.
[42] H. Sjoberg, “Interaction of Task Difficulty, Activation and Work
Load,” J. Human Stress, vol. 3, no. 1, pp. 33-38, 1977.
[43] J.R.P. French Jr., R.D. Caplan, and W. Harrison, The Mechanisms of
Job Stress and Strain. John Wiley, 1982.
[44] M. Erez and I. Zidon, “Effects of Goal Acceptance on the
Relationship of Goal Setting and Task Performance,” J. Applied
Psychology, vol. 69, no. 1, pp. 69-78, 1984.
[45] M. Csikszentmihalyi, “Play and Intrinsic Rewards,” J. Humanistic
Psychology, vol. 15, no. 3, pp. 41-63, 1975.
[46] M. Csikszentmihalyi, Beyond Boredom and Anxiety. Jossey-Bass,
1977.
[47] E.A. Locke and G.P. Latham, “Building a Practically Useful
Theory of Goal Setting and Task Motivation,” Am. Psychologist,
vol. 57, no. 9, pp. 705-717, 2004.
[48] C.N. Parkinson, Parkinson’s Law and Other Studies in Administra-
tion. Random House, 1957.
[49] G. Gutierrez and P. Kouvelis, “Parkinson’s Law and Its Implica-
tions for Project Management,” Management Science, vol. 37, no. 8,
pp. 990-1001, Aug. 1991.
[50] R. Rodgers and J. Hunter, “Impact of Management by Objectives
on Organizational Productivity,” J. Applied Psychology, vol. 76,
no. 2, pp. 322-336, 1991.
[51] A. O’Leary-Kelly, J. Martocchio, and D. Frink, “A Review of the
Influence of Group Goals on Group Performance,” Academy of
Management J., vol. 37, no. 5, pp. 1285-1301, 1994.
[52] R. Baum, E. Locke, and K. Smith, “A Multi-Dimensional Model of
Venture Growth,” Academy of Management J., vol. 44, no. 2, pp. 292-
303, 2001.
[53] K.H. Price, “Decision Responsibility, Task Responsibility, Iden-
tifiability, and Social Loafing,” Organizational Behavior and Human
Decision Processes, vol. 40, no. 3, pp. 330-345, 1987.
[54] S. Ang and S.A. Slaughter, “Work Outcomes and Job Design for
Contract versus Permanent Information Systems Professionals on
Software Development Teams,” MIS Quarterly, vol. 25, no. 3,
pp. 321-350, 2001.
[55] S. Nollen and H. Axel, Managing Contingent Workers. Am.
Management Assoc., 1996.
[56] J. Pfeffer and J. Baron, “Taking the Workers Back Out: Recent
Trends in the Structuring of Employment,” Research in Organiza-
tional Behavior, B. Staw and L.L. Cummings, eds., JAI Press, 1988.
[57] D.P. Darcy, C.F. Kemerer, S.A. Slaughter, and J.E. Tomayko, “The
Structural Complexity of Software: Testing the Interaction of
Coupling and Cohesion,” IEEE Trans. Software Eng., vol. 31, no. 11,
pp. 982-995, Nov. 2005.
Authorized licensed use limited to: Sreenidhi Institute of Science & Technology. Downloaded on November 5, 2009 at 04:49 from IEEE Xplore. Restrictions apply.
637
[58] L.G. Robert, “Evolving a New Theory of Project Success,” Comm.
ACM, vol. 42, no. 11, pp. 17-19, 1999.
[59] N.E. Fenton and S.L. Pfleeger, Software Metrics: A Rigorous and
Practical Approach. Int’l Thompson Computer Press, 1997.
[60] R.D. Banker, H. Chang, and C. Kemerer, “Evidence on Economies
of Scale in Software Development,” Information Software Technol-
ogy, vol. 36, no. 5, pp. 275-282, 1994.
[61] R.D. Banker and S.A. Slaughter, “A Field Study of Scale
Economies in Software Maintenance,” Management Science,
vol. 43, no. 12, pp. 1709-1725, 1997.
[62] A.J. Albrecht and J.E. Gaffney, “Software Function, Source Lines
of Code, and Development Effort Prediction: A Software Science
Validation,” IEEE Trans. Software Eng., vol. 9, no. 6, pp. 639-648,
Nov. 1983.
[63] C.F. Kemerer, Software Project Management Readings and Cases.
McGraw-Hill, 1997.
[64] M.S. Krishnan, C.H. Kriebel, S. Kekre, and T. Mukhopadhyay,
“An Empirical Analysis of Productivity and Quality in Software
Products,” Management Science, vol. 46, no. 6, pp. 745-759, 2000.
[65] D.E. Harter, M.S. Krishnan, and S.A. Slaughter, “Effects of Process
Maturity on Quality, Cycle Time, and Effort in Software Product
Development,” Management Science, vol. 46, no. 4, pp. 451-466,
Apr. 2000.
[66] C. Jones, Applied Software Measurement: Assessing Productivity and
Quality. McGraw-Hill, 1996.
[67] M. Agrawal and K. Chari, “Software Effort, Quality, and Cycle
Time: A Study of CMM Level 5 Projects,” IEEE Trans. Software
Eng., vol. 33, no. 3, pp. 145-156, Mar. 2007.
[68] M.C. Paulk, C.V. Weber, B. Curtis, and M.B. Chrissis, The
Capability Maturity Model: Guidelines for Improving the Software
Process. Addison-Wesley, 1995.
[69] G. Peeters and G. Dewey, “Reducing Bias in Software Project
Estimates,” CrossTalk—The J. Defense Software Eng., pp. 20-24, Apr.
2000.
[70] R.D. Banker and C.F. Kemerer, “Scale Economies in New Software
Development,” IEEE Trans. Software Eng., vol. 15, no. 10, pp. 416-
429, Oct. 1989.
[71] R. Davidson and J. MacKinnon, “Several Tests for Model
Specifications in the Presence of Multiple Alternatives,” Econome-
trica, vol. 49, no. 3, pp. 781-793, 1995.
[72] R.D. Cook and S. Weisberg, Applied Regression Including Computing
and Graphics. John Wiley and Sons, 1999.
[73] N. Smirnov, “On the Estimation of the Discrepancy between
Empirical Curves of Distribution for Two Independent Samples,”
Bull. Math. Univ. of Moscow, vol. 2, no. 1, pp. 3-16, 1939.
[74] H. White, “Heteroskedasticity-Consistent Covariance Matrix
Estimator and a Direct Test for Heteroskedasticity,” Econometrica,
vol. 48, no. 5, pp. 817-838, 1980.
Ning Nan received the PhD degree in business
information technology from the Ross School of
Business at the University of Michigan in 2006.
She is currently an assistant professor in the
Price College of Business at the University of
Oklahoma. Her research interests include man-
agement of software development projects, in-
group behaviors and time zone effect on global
software development teams, and postadoptive
information technology use behaviors.
Donald E. Harter received the MSc and PhD
degrees in management information systems
from Carnegie Mellon University in 1996 and
2000, respectively. He is currently an assistant
professor in the Whitman School of Manage-
ment at Syracuse University. His research
interests include measurement of the effect
of software processes on software develop-
ment costs, schedules, quality, support activ-
ities, and software personnel compensation.
He is a member of the IEEE.
. For more information on this or any other computing topic,
please visit our Digital Library at www.computer.org/publications/dlib.