CINCINNATI UNIVERSITY, SEPTEMBER CLASS, CIS...

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

RAPID advances in technology have enabled more andmore 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.

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.

624 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 35, NO. 5, SEPTEMBER/OCTOBER 2009

. N. Nan is with the Price College of Business, University of Oklahoma, 307 West Brooks, Norman, OK 73019. E-mail: [email protected].

. D.E. Harter is with the Whitman School of Management, Syracuse University, 721 University Avenue, Syracuse, NY 13244. E-mail: [email protected].

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: [email protected], 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 Published by the IEEE Computer Society

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

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

NAN AND HARTER: IMPACT OF BUDGET AND SCHEDULE PRESSURE ON SOFTWARE DEVELOPMENT CYCLE TIME AND EFFORT 625

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

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

626 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 35, NO. 5, SEPTEMBER/OCTOBER 2009

TABLE 1 Summary of the Software Literature

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

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

NAN AND HARTER: IMPACT OF BUDGET AND SCHEDULE PRESSURE ON SOFTWARE DEVELOPMENT CYCLE TIME AND EFFORT 627

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

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.

628 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 35, NO. 5, SEPTEMBER/OCTOBER 2009

TABLE 2 Budget and Schedule Pressure Hypotheses

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

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; quality; budget pressureÞ;

ðaÞ

Effort ¼ fðprocess maturity; size; complexity; quality; budget pressureÞ;

ðbÞ

CycleTime ¼ fðprocess maturity; size; complexity; quality; schedule pressureÞ;

ðcÞ

Effort ¼ fðprocess maturity; size; complexity; quality; schedule pressureÞ:

ðdÞ

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

NAN AND HARTER: IMPACT OF BUDGET AND SCHEDULE PRESSURE ON SOFTWARE DEVELOPMENT CYCLE TIME AND EFFORT 629

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,

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 TimeÞ¼ �01 þ�11 ln ðprocess maturityÞ þ�21 ln ðproduct sizeÞþ�31 ln ðcomplexityÞ þ�41 ln ðconformance qualityÞ þ�51 ðbudget pressureÞþ�61 ðbudget pressureÞ2;

ð1Þ

ln ðEffortÞ¼ �02 þ�12 ln ðprocess maturityÞ þ�22 ln ðproduct sizeÞþ�32 ln ðcomplexityÞ þ�42 ln ðconformance qualityÞ þ�52 ðbudget pressureÞþ�62 ðbudget pressureÞ2:

ð2Þ

The statistical models for schedule pressure analysis are the following:

ln ðCycle TimeÞ¼ �03 þ�13 lnðprocess maturityÞ þ�23 ln ðproduct sizeÞþ�33 ln ðcomplexityÞ þ�43 lnðconformance qualityÞ þ�53ðschedule pressureÞþ�63ðschedule pressureÞ2;

ð3Þ

ln ðEffortÞ¼ �04 þ�14 ln ðprocess maturityÞ þ�24 ln ðproduct sizeÞþ�34 ln ðcomplexityÞ þ�44 ln ðconformance qualityÞ þ�54ðschedule pressureÞþ�64ðschedule pressureÞ2:

ð4Þ

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

630 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 35, NO. 5, SEPTEMBER/OCTOBER 2009

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

NAN AND HARTER: IMPACT OF BUDGET AND SCHEDULE PRESSURE ON SOFTWARE DEVELOPMENT CYCLE TIME AND EFFORT 631

TABLE 4 Descriptive Statistics

TABLE 3 Bias Reduction Strategies

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

632 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 35, NO. 5, SEPTEMBER/OCTOBER 2009

TABLE 5 Parameter Estimates of the Budget 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

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

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

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

634 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 35, NO. 5, SEPTEMBER/OCTOBER 2009

Fig. 1. Linear and squared component effects of budget pressure on

log(cycle time).

Fig. 2. Linear and squared component effects of budget pressure on

log(effort).

Fig. 3. Effect of budget pressure on cycle time.

Fig. 4. Effect of budget pressure on effort.

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

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

NAN AND HARTER: IMPACT OF BUDGET AND SCHEDULE PRESSURE ON SOFTWARE DEVELOPMENT CYCLE TIME AND EFFORT 635

Fig. 5. Project with beneficial pressure. Fig. 6. Project with high pressure.

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.

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.

636 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 35, NO. 5, SEPTEMBER/OCTOBER 2009

[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.

[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.

NAN AND HARTER: IMPACT OF BUDGET AND SCHEDULE PRESSURE ON SOFTWARE DEVELOPMENT CYCLE TIME AND EFFORT 637