The effects of development process modeling and task
uncertainty on development quality performance
Arun Rai
a,*, Hindi Al-Hindi
baElectronic Commerce Institute, Robinson College of Business, Georgia State University, Atlanta, GA 30303, USA bDepartment of Quantitative methods, College of Business and Economics, King Saud University-Al Quasseem Branch,
Al Melaida P.O. Box 6033, Saudi Arabia
Received 24 March 1999; accepted 19 September 1999
Abstract
We examine the impact of development process modeling on outcomes in software development projects, limiting our attention to process and product quality. Modeling the software development process requires a careful determination of tasks and their logical relationships. Essentially, the modeling is undertaken to establish a management framework of the project. We de®ne and interrelate development process modeling, task uncertainty, and development outcomes, as assessed by product and process quality. A survey-based research design was used to collect data to prove our model. The results suggest that development process modeling is positively related to both product and process quality, while task uncertainty is negatively related to them. Development process modeling reduces the negative impact of task uncertainty on quality-oriented development outcomes. Development projects operating with high levels of task uncertainty should consider de®ning development process models that provide a framework for management of the project by establishing tasks and their logical interrelationships. Such a model should promote shared understanding of the work process among development constituents and enhance resource utilization ef®ciency.#2000 Elsevier Science B.V. All rights reserved.
Keywords:Management information systems; Systems development methodologies; Process quality; Product quality
1. Introduction
The demand for many new and different informa-tion system (IS) applicainforma-tions has increased the scope and complexity of the development process. Despite advances in the tools available for development, pro-ductivity is still low [4], development costs remain high, and it continues to be a challenge to develop quality products [42,46]. Even after signi®cant
resources are poured into software development pro-jects, many end up failing [23].
While poor performance and outright failures can be attributed to a number of factors, the management approach applied to development projects is seen as being a major cause of these pitfalls. Researchers in the area recognize that carefully conceived manage-ment practices should reduce developmanage-ment costs and improve development outcomes [26,50]. Technology-focused solutions have been faulted for these pro-blems, while limited attention has been paid to examining how these problems can be alleviated by rethinking management approaches being used [1]. Recent work by Ravichandran and Rai [41] *Corresponding author. Tel.:1-404-651-4011;
fax:1-404-651-3498.
E-mail addresses: [email protected] (A. Rai), [email protected] (H. Al-Hindi)
emphasizes the importance of developing an organi-zational systems perspective for the management of systems development [41].
The domain of our investigation is software devel-opment projects. Their management approach is usually based on the experience of the project manager [16]. In fact, many software projects are carried out in an ad hoc fashion without a well-established manage-ment framework. Old methods, such as the waterfall model and rapid prototyping, were proposed as frame-works to guide the management of the development process. However, each project is embedded in a speci®c context and has its unique set of information requirements, technological issues, resource con-straints, and other contextual factors. While generic frameworks are useful, they have to be modi®ed, adapted, and then instantiated in their context. They may be inadequate if organizations do not apply them to create process models that could enforce discipline within tasks, establish standardized interfaces between tasks, and improve the predictability asso-ciated with resource requirements.
Projects differ signi®cantly. The requirements for some may be fuzzy, for others volatile, and for yet others predictable and stable. The management litera-ture suggests that the selection and use of management practices should be informed by key contingencies underlying a given domain [29]. This requires speci-®cation of constructs de®ning alternate management practices, key task characteristics, and measures of performance outcome. A second step is to develop the interrelationships between these identi®ed constructs. The following question then seems reasonable to pose: what important contingencies should be con-sidered when studying the impact of development process modeling? Information processing theory sug-gests that an organization should be designed to manage uncertainty so as to achieve acceptable levels of predictability for the work system. A number of factors can affect the tasks and some of these factors are dif®cult to predict with a reasonable amount of certainty [17]. For example, user±developer relation-ships, user participation, business domain character-istics, technology and operating system platforms on which the software applications will operate can all impact the degree of task uncertainty.
In summary, our research is directed to increase our understanding of the interrelationships between
opment process modeling, task uncertainty in devel-opment projects, and quality-oriented develdevel-opment outcomes. The speci®c research question is:
What are the relationships between development process modeling, task uncertainty, and quality-oriented development outcomes?
2. Research model and hypotheses
2.1. Research model
There are behavioral, economical and attitudinal outcomes associated with development projects. For reasons of scope, we limit our attention to quality outcomes. Cooprider and Henderson [12] suggest that examining product and process outcomes together can reveal differential impacts of them on quality. Past research has identi®ed some attributes of development quality, such as effective coordination [35], project completion within schedule and budget [37], and overall quality of the development efforts [2]. We de®ne development process quality as the degree to which the process is designed to promote consensus among people participating in the development pro-cess, operate within established resource parameters, and reduce waste and redundancy. We de®ne software product quality as the overall evaluation of the ®nal product produced by the development process. We consider objective criteria, such as reliability and maintainability of the product, and subjective criteria, such as user acceptance and satisfaction, as part of the overall assessment.
modeling and task uncertainty. Our research model is schematically represented in Fig. 1.
2.2. Development process modeling and quality-oriented development outcomes
A software development process is a collection of interrelated activities performed in a logical order to produce an application system. A common under-standing of the software development process among participants, including developers, managers, and users, can be very useful for planning and controlling devel-opment activities [9,13,32]. However, many projects are carried out without adequate planning, with a poor explication of the overall development process, and the absence of a well-conceived managerial frame-work. Inadequate planning is one of the reasons for the high failure rates [6,7]. The task interfaces are ill-de®ned, deadlines are vague and unrealistic, resources required have not been rationalized, and scheduling and resource allocation models are not poorly developed.
Development process modeling can be an important step in building the management infrastructure neces-sary to manage the process [28,34]. Detailed devel-opment tasks determined during process modeling represent milestones that can be used for planning, scheduling and control.
Development and implementation of a process model is increasingly important as development units need to shift their focus from the traditional view of focusing on quality of the ®nal product to a more comprehensive view of improvement by focusing on both product and process quality [18]. Continuous improvement of the development process is consid-ered essential for producing high quality applications [36]. Process modeling can be used to analyze, under-stand and improve the design of the current develop-ment process. The concept of `quality at the source' suggests that deliverables at each stage should be
examined and inspected before being transferred to subsequent stages. This leads to the following hypoth-eses:
H1: The degree to which a process model has been established for a development project is positively related to process quality.
H2: The degree to which a process model has been established for a development project is positively related to product quality.
2.3. Development process modeling and task uncertainty
Process models can lead to a number of bene®ts, including disciplining the process and reducing uncer-tainty [20]. Modeling detailed development tasks in a formal fashion is an effective way to reduce role ambiguity among participants. Lack of this model is likely to have negative consequences on development outcomes [30]. Process models can also reduce uncer-tainty by clearly de®ning details of development tasks; then the association of tasks with process variations can focus the attention of development units on early identi®cation of problems.
Individuals performing a particular development task interpret task requirements according to their own views [51]. Furthermore, lack of communication among participants is a major cause of failure [14]. Formal and impersonal coordination, such as plans, schedules and documents allow effective coordination with positive impact on software development in terms of client satisfaction, quality, and productivity. As noted by Charette [10], a well-de®ned development process can help software developers in their inter-pretation of their tasks, and should reduce uncertainty in software development [5]. This leads to the hypo-thesis:
H3: The degree to which a process model has been established for a development project is negatively related to the degree of task uncertainty.
2.4. Task uncertainty and quality-oriented development outcomes
Generally speaking, high levels of task uncertainty are associated with software development [33]
exacerbated by hard-to-predict factors impacting different stages in the development process. Ongoing changes in user requirements contribute to the high levels of uncertainty associated [11,26]. Application development teams often include people with limited knowledge about the problem domain and detailed knowledge is often provided too late to help [39]. Inadequate information can result in decisions to delay certain steps or to execute the development process in a trial and error fashion [15]. This leads to the hypotheses:
H4: The degree of task uncertainty in a development project is negatively related to development process quality.
H5: The degree of task uncertainty in a development project is negatively related to development product quality.
2.5. Development process modeling-task uncertainty interaction
The interaction relationships were proposed to show how development process modeling impacts the relationship between task uncertainty and development quality: the assumption being that organization performance is dependent on the orga-nization's ability to handle uncertainty through its information processing capability [43,47]. To achieve a maximum level of performance, compromise must occur between an organization's information proces-sing capability and the level of uncertainty that it faces.
Several mechanisms have been suggested to increase the information processing capability of the development subunit. These include coordina-tion [38], standardizacoordina-tion, rethinking the decision making structure, and modern development practices. Accordingly, development process modeling should be more important in projects characterized by higher levels of task uncertainty. This leads to the hypotheses:
H6: The interaction between modeling and task uncertainty in¯uences development process quality.
H7: The interaction between modeling and task uncertainty in¯uences development product quality.
3. The empirical study
3.1. Data collection
To obtain data for this study, a survey instrument was designed, pre-tested and sent to 1050 senior IS executives located across the United States. The names of these executives and their companies were randomly selected from theDirectory of Top Compu-ter Executives. This random selection process was used as we wanted to test our hypotheses using data about projects emanating from diverse organizational and industrial contexts. The questionnaire clearly stated that our target was a recently completed soft-ware development project within the ®rm (Appendix A). An accompanying letter explained this and requested the senior IS executive to forward all mate-rials to the project manager or a well-informed mem-ber of the project team who participated in the development process. This is consistent with Huber and Powell's [25] recommendation that the person(s) most knowledgeable should be chosen as respondents. A reminder letter along with a follow-up questionnaire was sent 4 weeks after the initial mailing. A total of 131 responses were received; 36 organizations indi-cated that they did not develop software in-house. The remaining 95 completed the questionnaire, represent-ing a response rate of 12.4%. This is normal for such surveys.
responses can be pooled without any loss of general-izability.
We also tested to see if our sample was biased with respect to key characteristics, such as size of devel-opment team, project duration, and project budget. Overall, the 95 projects showed a good dispersion of project context characteristics. An examination of the distribution of the dependent variables, product qual-ity and process qualqual-ity, did not reveal any biases as their means and medians were similar, skewness was less than two, and kurtosis was less than ®ve [21]. Thus, while our response rate is low, the series of tests did not reveal any signi®cant threats to the general-izability of ®ndings to the population of inhouse developed software development projects. A pro®le of the projects is summarized in Table 1, while Table 2 provides a summary of the development tools used in these development projects.
3.2. Instrument development
The questionnaire for this study, which is part of a larger research effort on software development management practices, was developed through an extensive review of the literature. The ®rst section of the questionnaire asked respondents about general characteristics of their IS organization and the speci®c development project. The second solicited
informa-tion about their management practices and the nature of the development task. A 7-point Likert-type scale that ranged fromstrongly disagreetostrongly agree-was used for each of the items. The third section listed items to evaluate development outcomes. The respondents were asked to indicate their project per-formance on a 7-point Likert type scale. The ques-tionnaire was critiqued by three researchers who have worked extensively in the area of IS development and by two individuals with signi®cant practical experi-ence in the management of development projects. Their comments were addressed prior to our data collection.
3.3. Measures for independent variables
3.3.1. Development process modeling
To the best of our knowledge, an operational mea-sure has not been developed to assess the degree to which process models have been established for a development project. We recognize that several tech-niques, including Petri nets, state transition, and quan-titative models can be used to model processes [13]. Regardless of the technique used, process models should be effective tools. Our focus here is not on the speci®c modeling technique used. We developed a 6-item scale to assess the degree to which a process model has been established. These items include de®nition of key tasks: level of detail of tasks, relation-ships between development tasks, use of a process, and the extent to which the organization enforces the use of a software process model.
Stewart [45] suggested that Bartlett's test of spheri-city and the Kaiser-Meyer-Olin measure of sampling adequacy be examined to assess whether or not a set of variables are appropriate for factor analysis. The test assesses whether the correlation matrix comes from a
Table 1
Profile of development projects
Characteristics Mean Standard Deviation Minimum Maximum
Size of development team 8.24 11.17 1 75
Number of distinct user department involved 3.45 2.35 1 11
Project duration (months) 10.7 8.65 1 36
Project budget (thousands $) 571.77 907.8 4 5000
Number of distinct computer programs developed 112.7 208 2 1000 Number of full-time employees in the IS department 34.3 61.2 1 350
Table 2
Profile of development tools used in the projects
Tools Percentage of projectsa
CASE Tools 15.7
Data base management systems 67.4 Fourth generation languages 34.8
Other tools 46.1
population of variables that are independent. Measure of sampling adequacy (MSA) provides a measure of the extent to which variables belong together. Kaiser and Rice [31] provided a calibration of the MSA measure with regard to the degree of appropriateness of using factor analysis on a set of measurement items. They classi®ed a value of 0.80 as `meritorious' values between 0.6 and 0.8 as `mediocre', and values below 0.50 as `unacceptable.'
For the measurement items being considered for the development process modeling construct, Bartlett's test of sphericity led to a rejection of the null hypoth-esis of variable independence at a level of signi®cance of 0.000. The measure of sampling adequacy was computed to be 0.83 and suggested that the items were appropriate for factor analysis. Principal com-ponent analysis followed by a varimax rotation resulted in a two-factor solution. Five items used to de®ne the development process modeling scale loaded on the ®rst factor, each with loadings greater than 0.7 (Table 3). These items re¯ect the degree of process modeling performed for the development project. The second factor, with one item loading signi®cantly on it, suggests that awareness of the organization about the importance of process modeling is a separate construct. Thus, we limit our measure of development process modeling to the ®ve items that loaded on the ®rst factor. There were no sudden drops in the item-total correlation, and a Cronbach's alpha value of 0.89 suggests a high level of internal consistency among measurement items.
3.3.2. Task uncertainty
A 3-item instrument was used to measure uncertainty. These items re¯ect ¯uctuation in users'
requirements, information available to perform the tasks, and the extent to which the project was subject to uncertain events. These items were adapted from Goodhue and Thompson [22] and Van de Ven, et al. [48]. As expected, Bartlett's test of sphericity led to a rejection of the null hypothesis of variable inde-pendence at a level of signi®cance of 0.000. The measure of sampling adequacy was computed to be 0.60. Not surprisingly, the principal component ana-lysis resulted in all three items loading on one factor, with two of the items having loadings greater than 0.80 and one item having a loading of 0.63 (Table 4). There were no sudden drops in the item-total correla-tion and a Cronbach's alpha value of 0.63 suggests a reasonable level of internal consistency among mea-surement items.
3.4. Dependent variables: measures for development quality
3.4.1. Product quality
A 5-item scale was used to measure software pro-duct quality: reliability, ¯exibility, maintainability,
Table 3
Factor analysis of development process modeling measurement items
Measurement items First factor analysis Second factor analysis
Factor 1 Factor 2 Factor 1
Definition of software development tasks 0.88 ÿ0.32 0.90 Definition of the relationships between development tasks 0.90 ÿ0.23 0.91 Level of details used in defining the development tasks 0.86 0.11 0.85 Adequate time spent on defining the development tasks 0.88 ÿ0.11 0.88 Use of a predetermined software development model 0.70 28 0.68 Organization requires the use of a software process model 0.33 0.89 Deleted
Eigenvalue 3.70 1.07 3.61
% of variance extracted 61.64 17.81 72.73
Table 4
Factor analysis of task uncertainty measurement items
Measurement items Factor
Fluctuation in users' requirements 0.84 Availability of information to perform the task 0.63 Development project subject to uncertain events 0.80
Eigenvalue 1.75
system acceptance, and satisfaction. The instrument used was adapted from Alavi [2], Henderson and Lee [24], and Shin and Lee [44]. As expected, the null hypothesis of variable independence of these was rejected at a level of signi®cance of 0.000. Our MSA measure was 0.83 and suggested that the ®ve items were appropriate for factor analysis. Principal component analysis resulted in a one-factor solution (see Table 5). Factor analysis results for the develop-ment product quality construct showed that the ®ve items loaded on one factor, each with loadings greater than 0.70. The item-total correlations indicated no sudden drops providing evidence of homogeneity among the items and a Cronbach's alpha value of 0.89 reveals a high level of internal consistency among measurement items.
3.4.2. Process quality
A 5-item scale was used to assess the quality of the development process. These items re¯ect some desir-able characteristics of the process such as the degree to which the project was completed on schedule, the degree to which the project met cost targets, and the degree of agreement among participants. The items used were adapted from Alavi [2], Henderson and Lee [24] and Mahmood [37]. Batlett's test of sphericity led to a rejection of the null hypothesis of variable inde-pendence at a level of signi®cance of 0.000. The measure of sampling adequacy was computed to be 0.74 and suggested that the items were appropriate for factor analysis. Principal component analysis resulted in a one-factor solution (Table 6). However, one item has a loading of 0.37, and was deleted. The remaining items were used to determine a measure for process quality. There were no sudden drops in the item-total correlation, and a Cronbach's alpha value of 0.78
suggests a high level of internal consistency among the four measurement items.
3.5. Convergent and discriminant validity
Convergent validity is achieved if items that mea-sure the same construct are highly correlated. One-tailedt-test was used to assess the signi®cance of inter-item correlations: the test revealed that are signi®cant at a level of signi®cance of 1%. Examination of the correlation between an item and each of the constructs was used to assess discriminant validity. Items of a particular construct have discriminant validity when they have higher correlations with their construct than with other constructs. The item-construct correlations showed that all measurement items have higher cor-relations with their construct than with others. Based on these results, our constructs and their measures have acceptable levels of convergent and discriminant validity.
3.6. Summary of psychometric properties
Venkatraman and Grant [49] recommended that survey instruments used for empirical research should use scales (1) with multiple higher level items rather than single, nominal items, (2) that are intern-ally consistent, and (3) that are valid. The measures for task uncertainty, product and process quality were adapted from previous IS research on the measure-ment of these constructs. The process modeling construct was developed for this study and subjected to pretest. Factor analysis of the measurement items resulted in factor structures providing evidence of
Table 5
Factor analysis of product quality measurement items
Measurement items Factor
Application developed is reliable 0.84 Application developed is easy to maintain 0.76 Users accepted the application developed 0.89 Users are satisfied with the application developed 0.86 Overall quality of the application 0.85
Eigenvalue 3.57
% of variance extracted 71.32
Table 6
Factor analysis of process quality measurement items
Measurement items Factor
Duplication of efforts during the development process (reverse coded)
0.37
Degree of agreement among participants in the development process
0.51
System was completed within budget 0.84 System was completed within schedule 0.87 Overall quality of the development efforts 0.82
Eigenvalue 2.46
measurement validity. Three of the constructs have reliabilities greater than 0.80 and one of the con-structs, task uncertainty, has a reliability of 0.63. These values are acceptable for exploratory theory testing research in the behavioral and social sciences. The scale reliabilities along with some descriptive statistics of each of the constructs are given in the Table 7. Correlation analysis between constructs and between items and constructs suggest adequate levels of convergent and discriminant validity of the measures.
4. Results and discussion
4.1. Direct relationships
The correlation coef®cient between software pro-cess modeling and propro-cess quality was positive and signi®cant (p<0.005), which gives support for hypoth-esis H1. The correlation coef®cient between software process modeling and development product quality is positive and signi®cant (p<0.0001), which gives
support to hypothesis H2 and signi®cant (p<0.0001), which gives support to hypothesis H3. The correlation coef®cient between development task uncertainty and process quality was negative and signi®cant (p<0.005), which supports hypothesis H4. Also, the correlation coef®cient between task uncertainty and process quality was negative and signi®cant (p<0.005), which supports hypothesis H5.
4.2. Interaction relationships
The interaction relationships proposed pertain to the impact of the interaction between software process modeling and task uncertainty on quality-oriented development outcomes. The ®rst interaction pertains to the impact of process modeling on the relationship between task uncertainty and product quality; the second pertains to the effect of process modeling on the relationship between task uncertainty and devel-opment process quality. When dealing with an inter-action relationship, the selection of the functional form that represents the relationship is of a signi®cant importance. In case the outcome variable is better
Table 7
Correlation coefficients, reliabilities and descriptive statistics
Variable 1 2 3 4 Cronbach's
alpha
Mean Standard deviation
1 Product quality 1.0 0.89 5.57 0.96
2 Process quality 0.77 1.0 0.78 4.65 1.18
3 Development process modeling 0.43 0.37 1.0 0.89 5.04 1.2
4. Task uncertainty ÿ0.35 ÿ0.30 ÿ0.54 1.0 0.63 4.86 1.67
Table 8
Regression analysis: process modeling and task uncertainty on process quality
Independent variable Interaction modela Main effect modelb
b t p b t p
Process modeling (s) 1.45 3.15 0.002 0.28 2.48 0.015
Task uncertainty (t) 0.98 2.11 0.03 ÿ0.19 ÿ1.43 0.15
Process modelingtask uncertainty (st) ÿ0.22 ÿ2.62 0.01
ModelR2 0.22 0.16
AdjustedR2 0.19 0.14
F-value 8.38 8.58
P< 0.0001 0.0004
ay
1b0b1sb2tb3st, wherey1is development process quality. by
explained by the presence of the two interacting variables than by only one, as suggested by hypotheses H6 and H7, the multiplicative form of interaction may be more appropriate [3].
To test the interaction relationship of H6, an equa-tion with a multiplicative interacequa-tion term was esti-mated. Table 8 shows the results of the regression analysis for the interaction model and the main effect model for these variables: the interaction term was negative and signi®cant. Also, the improvement of goodness of ®t resulting from the interaction term (incremental r2) is also signi®cant (Dr20.06, F-value7.0,p<0.01). These results support hypoth-esis H6. The negative sign of the interaction term means that task uncertainty has a lesser negative impact on process quality at higher levels of process modeling.
Similarly, a multiplicative interaction equation was estimated to test the impact of the interaction between process modeling and task uncertainty on deve-lopment product quality (H7). The results of the regression analysis (Table 9) show that the interaction term is negative and signi®cant. Also, the incremental r2 resulting from including the interaction term in the regression equation is signi®cant (Dr20.07, F-value8.73,p<0.01). These results support H7.
Task uncertainty and development process model-ing exhibit an interaction effect on development qual-ity supporting the contingency relationship between the two variables as suggested by our theoretical model. Therefore, higher levels of process modeling not only improve development quality directly but
also reduce the negative impacts of task uncertainty in development projects.
5. Conclusions
We used a contingency framework based on infor-mation processing theory to formulate our theoretical model. Findings support seven research hypotheses that were formulated.
Our results suggest that process modeling has a positive association with development outcome qual-ity. Also, it has an indirect impact by reducing the negative impact of development task uncertainty on development quality; process modeling can appar-ently be used to de®ne the information processing structure and capability of the project so to better manage uncertainty. Consequently, the negative impact of development task uncertainty is likely to be offset by process modeling.
It is useful to model the development process before starting development efforts: this can provide a useful managerial framework.
The correlation coef®cient between enforcing the use of process models and the level of process model-ing was positive and signi®cant. This suggests that the organization represented by its top management can positively impact development process modeling by emphasizing the conceptualization and use of process models. Project managers and development personnel could conceivably be empowered to develop process models for their respective projects.
Table 9
Regression analysis: process modeling and task uncertainty on product quality
Independent variable Interaction modela Main effect modelb
b t p b T p
Process modeling (s) 1.24 3.44 0.0009 0.27 3.04 0.003
Task uncertainty (t) 0.81 2.22 0.028 ÿ0.16 ÿ1.56 0.12
Process modelingtask uncertainty (st) ÿ0.18 ÿ2.78 0.0067
ModelR2 0.27 0.20
AdjustedR2 0.25 0.18
F-value 11.12 11.96
P< 0.0001 0.0001
ay
2b0b1sb2tb3st,wherey2is software product quality. by
References
[1] T.M. Abdel-Hamid, S.E. Madnick, Lessons learned from modeling the dynamics of software development, Commu-nications of the ACM 32 (12), 1989, pp. 1426±1438. [2] M. Alavi, An assessment of the prototyping approach to
information system development, Communications of the ACM 27 (6), 1984, pp. 556±563.
[3] P.D. Allison, Testing for interaction in multiple regression, American Journal of Sociology 83, 1977, pp. 144±153.
[4] U. Apte, S.C. Sankar, M. Takur, E.J. Turner, Reusability-based strategy for development of information systems, MIS Quarterly 14 (4), 1990, pp. 421±433.
[5] H. Barki, S. Rivard, J. Talbot, Toward an assessment of software development risk, Journal of Management Informa-tion Systems 10 (2), 1993, pp. 203±225.
[6] B.W. Boehm, R. Ross, Theory-W software project manage-ment: principles and examples, IEEE Transactions on Soft-ware Engineering 15 (7), 1989, pp. 902±916.
[7] B.W. Boehm, Software Engineering Economics, Prentice-Hall, Englewood Cliffs, NJ, 1981.
Appendix A.
[8] S. Bretschneider, D. Wittmer, Organizational adoption of microcomputer technology: the role of sector, Information Systems Research 4 (1), 1993, pp. 88±108.
[9] D. Budgen, Software Design, Addison-Wesley, Reading, MA, 1993.
[10] R.N. Charette, Software Engineering Environment Concepts And Technology, McGraw Hill, New York, 1986.
[11] J. Cooper, Software development management planning, IEEE Transactions on Software Engineering 10 (1), 1984, pp. 22±26. [12] J.G. Cooprider, J.C. Henderson, Technology-process fit: perspectives on achieving prototyping effectiveness, Journal of management Information Systems 7 (3), 1991, pp. 67±87. [13] B. Curtis, M.I. Kellner, J. Over, Process modeling,
Commu-nications of the ACM 35 (9), 1992, pp. 75±90.
[14] B. Curtis, H. Krasner, N. Iscoe, A field study of the software design process for large systems, Communications of the ACM 31 (11), 1988, pp. 1268±1287.
[15] B. De Brabander, G. Thiers, Successful information systems development in relation to situational factors which affect effective communication between MIS-users and EDP-specialists, Management Science 30 (2), 1984, pp. 137±155. [16] M.S. Deutsch, An exploratory analysis relating the software project management process to project success, IEEE Transactions on Engineering Management 38 (4), 1991, pp. 365±375.
[17] L.M. Duvall, A study of software management: the state of practice in the United States and Japan, Journal of Systems and Software 31 (2), 1995, pp. 109±124.
[18] J.R. Evans, W.M. Lindsay, The Management And Control Of Quality, West Publishing, 1993.
[19] F.J. Fowler, Jr., Survey Research Methods, 2nd Edition, Sage, Newbury Park, CA, 1993.
[20] P.K. Garg, P. Mi, T. Pham, W. Scacchi, G. Thunquest, The SMART approach for software process engineering, in: Proceedings of the 16th International Conference on Software Engineering, IEEE Computer Society, Washington, DC, 1994, pp. 341±350.
[21] E.E. Ghiselli, J.P. Campbell, S. Zedeck, Measurement Theory for the Behavioral Sciences, W.H. Freeman, San Francisco, CA, 1981.
[22] D.L. Goodhue, R.L. Thompson, Task-technology fit and individual performance, MIS Quarterly 19 (2), 1995, pp. 213± 236.
[23] S.R. Hawk, B.L. Dos Santos, Successful system development: the effect of situational factors on alternate user roles, IEEE Transactions on Engineering Management 38 (4), 1991, pp. 316±327.
[24] J.C. Henderson, S. Lee, Managing I/S design teams: a control theories perspective, Management Science 38 (6), 1992, pp. 757±777.
[25] G.P. Huber, D.J. Powell, Retrospective reports of strategic-level managers: guidelines for increasing their accuracy, Strategic Management Journal 6 (2), 1985, pp. 171±180. [26] W.S. Humphrey, Managing the Software Process,
Addison-Wesley, Reading, MA, 1989.
[27] W.S. Humphrey, B. Curtis, Comments on a critical look, IEEE Software 8 (4), 1991, pp. 42±46.
[28] W.S. Humphrey, M.I., Kellner, Software process modeling: principles of entity process models, in: Proceedings of the 11th International Conference on Software Engineering, 1989, IEEE Computer Society, Washington DC, pp. 331±342. [29] L.R. James, A.B. Jones, Organizational structure: a review of structural dimensions and their conceptual relationships with individual attitudes and behavior, Organizational Behavior and Human Performance 16, 1976, pp. 74±113.
[30] K. Joshi, Role conflict and role ambiguity in information systems design, Omega 17 (4), 1989, pp. 369±380. [31] H.F. Kaiser, J. Rice, Little jiffy Mark IV, Educational and
Psychological Measurement 34 (2), 1974, pp. 111±117. [32] M.I. Kellner, G.A., Hansen, Software process modeling: a
case study, Proceeding of the 22th Annual Hawaii Interna-tional Conference on System Sciences, 1989, Vol. II, Software Track, IEEE Computer Society, Washington DC, pp. 175±188.
[33] K.K. Kim, N.S. Umanath, Structure and perceived effective-ness of software development subunits: a task contingency analysis, Journal of Management Information Systems 9 (3), 1993, pp. 157±181.
[34] H. Krasner, J. Terrel, A. Linehan, P. Arnold, W.H. Ett, Lessons learned from a software process modeling system, Communications of the ACM 35 (9), 1992, pp. 91±100. [35] R.E. Kraut, L.A. Streeter, Coordination in software
develop-ment, Communications of the ACM 38 (3), 1995, pp. 69±81. [36] N.H. Madhavji, The process cycle, IEEE/BCS Software
Engineering 6 (5), 1991, pp. 234±242.
[37] M.A. Mahmood, System development methods Ð A comparative investigation, MIS Quarterly 11 (3), 1987, pp. 293±311.
[38] S.R. Nidumolu, The effect of coordination and uncertainty on software project performance: residual performance risk as an intervening variable, Information Systems Research 6 (3), 1995, pp. 191±219.
[39] D.L. Parnas, P.C. Clements, A rational design process: how and why to fake it, IEEE Transactions on Software Engineering 12 (2), 1986, pp. 251±257.
[40] A. Rai, D.S. Bajwa, An empirical investigation into factors relating to the adoption of executive information systems: an analysis of EIS for collaboration and decision support, Decision Sciences 28 (4), 1997, pp. 939±974.
[41] T. Ravichandran, A. Rai, Quality management in systems development: an organizational system perspective, MIS Quarterly (in press).
[42] F.J. Redmill, Considering quality in the management of software-based development projects, Information and Soft-ware Technology 32 (1), 1990, pp. 18±22.
[43] C. Schoonhoven, Problem with contingency theory: testing assumptions hidden within the language of contingency, Administrative Science Quarterly 26 (3), 1981, pp. 349±377. [44] H. Shin, J. Lee, A process model of application software package acquisition and implementation, Journal of Systems and Software 32 (1), 1996, pp. 57±64.
[46] R.H. Thayer, A. Pyster, The challenge of software engineer-ing project management, Computer 13 (8), 1980, pp. 51±58. [47] M. Tushman, D. Nadler, Information processing as an integrating concept in organizational design, Academy of Management Review 3 (3), 1978, pp. 613±624.
[48] A.H. Van de Ven, A.L. Delbecq, R. Koenig Jr., Determinants of coordination modes within organizations, American Sociological Review 41, 1976, pp. 322±338.
[49] N. Venkatraman, J.H. Grant, Construct measurement in organizational strategy research: a critique and proposal, Academy of Management Review 11 (1), 1986, pp. 71±87. [50] Whitten, N., Managing Software Development Projects,
Wiley New York, 1995.
[51] R.W. Zmud, Management of large software development efforts, MIS Quarterly 4 (2), 1980, pp. 45±55.
Arun Raiis an Associate Professor in the Electronic Commerce Institute, Ro-binson College of Business, Georgia State University. His research interests include the diffusion, infusion and impacts of information technology,
emergenteBusiness models, supply chain management, knowledge management, and management of unstructured processes, such as innovation, product development, and systems development. Arun's research has been published in journals such asAnnals of Operations Research, Accounting, Management and Information Technologies, Communications of the ACM, Decision Sciences, Decision Support Systems, European Journal of Information Systems, Information Systems Journal, Journal of Management Information Systems, Omegaand several others. He is an associate editor of MIS Quarterly, e-Services Quarterly, Information Resources Management Journal and a departmental editor of DATA BASE for Advances in Information Systems. Leading corporations, such as A.T. Kearney, Bozell Worldwide, Chrysler, Comdisco, IBM, and Scientific Atlanta, among others, have sponsored his recent research work.
