Why is Software Late? An Empirical Study of Reasons For Delav in Software Development

Transcription

1 582 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 17, NO. 6, JUNE 1991 Why is Software Late? An Empirica Study of Reasons For Deav in Software Deveopment Michie van Genuchten Abstract-This paper describes a study of the reasons for deay in software deveopment that was carried out in 1988 and 1989 in a Software Engineering Department. The aim of the study was to gain an insight into the reasons for differences between pans and reaity in deveopment activities in order to be abe to take actions for improvement. A cassification was used to determine the reasons. One hundred and sixty activities, comprising over hours of work, have been anayzed. Actions have been taken in the Department as a resut of the study. These actions shoud enabe future projects to foow the pan more cosey. The actions for improvement incude the introduction of maintenance weeks. Simiar studies in other software deveopment departments have shown that the reasons varied widey from one department to another. It is recommended that every department shoud gain an insight into its reasons for deay in software deveopment so as to be abe to take appropriate actions for improvement. Index Terms- Anaysis of software deveopment, empirica study, improvement, measurement, metrics, project management, reasons for deay, software deveopment, software engineering management. T I. INTRODUCTION here is frequenty a difference between the panned and actua progress of a software project. Why projects do not run according to pan is ess cear. This paper describes a study which was carried out in 1988 and 1989 in a Software Deveopment Department. The aim of the study was to obtain information about the differences between pans and reaity in software deveopment. The study ed to actions for improvement in the department concerned, which shoud enabe future projects to foow the pan more cosey. The aim of this paper is to add to the present knowedge concerning the reasons for overrun and deays in software deveopment. The paper consists of the foowing sections: Section II describes a number of surveys on deays and reasons for deays, as described in the iterature. Section III expains the definition and panning of the study. The resuts of the study are given in Section IV. The resuts were interpreted by the project eaders participating in the study. The interpretation of the resuts is described in Section V. Finay, the concusions of the study are presented. Manuscript received February 15, 1990; revised January 10, Recommended by M. S. Deutsch. The author is with the Department of Management Information Systems and Automation, Facuty of Industria Engineering, Pavijoen D3, Eindhoven University of Technoogy, P.O. Box 513, 5600 MB Eindhoven, The Netherands. IEEE Log Number PERCENTAGE OF PROJECT5 40, mm-m / PERCENTAGE OF EFFORT OVERRUN Fig. 1. Distribution of reative effort overruns [7]. II. SURVEYS ON THE OVERRUN OF DEVELOPMENT PROJECTS Three empirica studies concerning the overrun of deveopment projects wi be discussed in this section. These studies wi be referred to as surveys. The definition of the surveys and their resuts wi then be compared with the study described in Sections III through V of this paper. A. Survey by Jenkins, Naumann, and Whetherbe [7] Jenkins et a. [7] interviewed the deveopers of 72 information system deveopment projects in 23 major U.S. corporations. The aim of the survey was to coect empirica data on the systems deveopment process in organizations. The average duration of the projects was 10.5 months. Over 70% of the projects took ess than 1000 person days to finish. The users of the deveoped systems stated that they were satisfied to very satisfied with the resut in 72% of the projects. The reative effort overruns are given in Fig. 1. The average effort overrun was 36%. Fig. 1 shows that 38% of the projects had an overrun of between 0 and 50%. Nine percent of the projects had an underrun of between 0 and 50 %. The reative schedue overruns are given in Fig. 2. The average schedue overrun was 22%. Fig. 2 shows that 40% of the projects had an overrun of between 0 and 50%. One concusion of Jenkins et a. was that the cost and schedue overruns seem to be uniformy distributed among arge, medium, and sma projects. They did not ook into the reasons for deays and overruns. B. Survey by Phan, Voge, and Nunamaker (91, [IO] Researchers at the University of Arizona attempted to 009%5589/91/ $ IEEE

2 VAN GENUCHTEN: WHY IS SOFTWARE LATE? 583 PERCENTAGE 50 OF PROJECTS 40 - SOMETIMES 50 % RARELY 15 % ot / Fig. 4. Prevaence of ate deiveries [o].,-i PERCENTAGE OF SCHEDULE OVERRUN Fig. 2. Distribution of reative schedue overruns [7]. L were usuay a reason for 33 and 36% of the respondents, respectivey. The ack of software deveopment toos was ony mentioned by 17% as a usua reason. The four actions most frequenty taken to regain contro over deayed projects were: 1) Upgrading the priority of the project 2) Shifting part of the responsibiity and obigations to other groups 3) Renegotiating the pan and schedue 4) Postponing features and upgrades tb the next version. SCMETIMES 42 Fig. 3. Prevaence of cost overruns [9]. determine why the panned ead times and costs of information system deveopment projects were overrun [9], [o]. Questionnaires were sent to 827 members of the American Institution of Certification of Computer Professionas. The survey yieded 191 responses. The respondents were invoved in projects with an average duration of 102 person months. On average, the ead time was 14 months and 17 peope worked on a project. The average cost overrun was 33%, simiar to the 36% overrun reported by Jenkins et a. [7]. The survey was comprised of 100 questions. In 72 of these the respondents were asked to reca the frequency with which the events occurred as: (a) aways; (b) usuay; (c) sometimes; (d) sedom/rarey; or (e) never. Over 70% of the respondents caimed that user requirements and expectations were usuay met. Fig. 3 shows the prevaence of cost overruns. Ony 16% of the respondents answered that they never or rarey had cost overruns. Cost overruns were usua for 37% of them. Fig. 4 shows the prevaence of schedue overruns. Fig. 4 shows that more than 80% of the respondents stated that their projects were sometimes or usuay ate. The survey aso addressed the reasons for cost overruns and ate deiveries. According to 51% of the respondents, over-optimistic estimation was usuay a reason for a cost overrun. Amost 50% stated that frequent changes in design and impementation were usuay a reason for a cost overrun. Nine percent stated that these were aways a reason. The survey aso investigated why the product ead times were overrun. Over-optimistic panning was a reason to which 44% usuay attribute the deay. Minor and major changes C. Survey by Thambain and Wiemon [.?] The aim of a fied study by Thambain and Wiemon [12] was to investigate the practices of project managers regarding their project contro experiences. The scope of the survey was not confined to software engineering projects; the eaders of eectronics, petrochemica, construction, and pharmaceutica projects were interviewed. Data was coected from 304 participants in project management workshops or seminars. Those questioned had an average of five years experience in technica project management. The average ead time for the projects was one year, and on average eight peope worked on a project. Among other things, the survey investigated what the project eaders and their superiors (such as senior functiona managers or genera managers) beieved to be the reasons for cost and ead time overruns. The reasons for overruns were arranged in order of importance by project eaders and genera managers. The resuts are given in Tabe I. It is striking to note that the project eaders and genera managers do not agree on the importance of 9 of the 15 reasons. According to the researchers, the practica impication of this finding is that senior management expects proper project panning, organization, and tracking from project eaders. They further beieve that the externa criteria, such as customer changes and project compexities, impact project performance ony if the project had not been defined propery and sound management practices were ignored. On the other hand, management thinks that some of the subte probems, such as sinking team spirit, priority shifts, and staffing are of esser importance [ 121. The researchers aso investigated the reasons which caused the probems referenced in Tabe I. These ess obvious reasons were caed subte reasons, which can be cassified into five categories:

3 584 IEEE TRANSACTIONS ON SOFIWARE ENGINEERING, VOL. 17, NO, 6, JUNE 1991 TABLE I DIRECI-LY OBSERVED REASONS FOR SCHEDULE SLIPS AND COST OVERRUNS RANK BY Genera managers Project managers PROBLEM ment between genera and project management 1 10 Insufficient front-end panning 2 3 Unreaistic project pan 3 8 Project scope underestimated 4 1 Customer/management changes 5 14 Insufficient contingency panning 6 13 Inabiity to track progress 7 5 Inabiity to track probems eary 8 9 Insufficient number of checkpoints 9 4 Staffing probems 10 2 Technica compexity 11 6 Priority shifts No commitment by personne to pan Uncooperative support groups 14 7 Sinking team spirit Unquaified project personne Strongy agree Probems with organizing the project team Weak project eadership Communication probems Confict and confusion Insufficient upper management invovement. Obviousy, the subte reasons cited by the project eaders and genera managers were not technica reasons, but reated to organizationa, manageria, and human aspects. Motivation Object Purpose Perspective Domain Scope TABLE II THE DEFINITION OF THE STUDY To increase insight into the reasons for dea Software engineering activities To evauate reasons for deay Project eader Project Six-projects in one deveopment department III. DEFINITION AND PLANNING OF THE STUDY A. Definition of the Study The framework of experimentation, as proposed by Basii et a. [] wi be used to define the study which is described in this paper. According to this framework, a definition consists of six parts: motivation, object, purpose, perspective, domain, and scope. The motivation of this study was to gain an insight into the reasons for deay in order to be abe to improve the contro of future deveopment projects. This new insight shoud Iead to actions for improvement designed to enabe future projects to foow their pan more cosey. The object of the study was defined as the primary entity examined []. The object in this case was software deveopment activities. Projects can be anayzed on various eves of detai; namey, as a whoe (as done by Jenkins et a. [7]), at phase eve, or at activity eve. Data was coected and anayzed at the activity eve in this study, because experience has shown that a project generay does not overrun because of one or two main probems, but rather because of a arge number of minor probems. According to Brooks [3]: How does a project get one year ate? One day at a time. These sma probems coud amost certainy be overooked if data were coected at the project eve. In this study an activity was defined as a unit of work that is identified in a pan and can be tracked during its execution. A typica activity may be the specification of a subsystem, the design of a modue, or the integration of some modues. The purpose of the study was to evauate the reasons for deay. This was done from the perspective of the project eader. The domain studied was software projects. The scope of the study covered six deveopment projects in one software deveopment department. The definition of the study is summarized in Tabe II. B. Panning the Study The motivation of the study was to gain an insight into the reasons for deay in software deveopment. The kind of questions the study aimed to answer were: What are the predominant reasons for deay? What-is the distribution of the reasons for deay? How is the deay distributed over the phases of a project? Which actions for improvement can prevent deay in future projects? The foowing basic principes were used for data coection: 1) The contro of a project refers to the contro of quaity, effort, and ead time. The study was based on the assumption that an activity is ony competed when the (sub)product deveoped fufis the specifications. In other words, if the quaity of the product deveoped is adequate. In the department concerned this was monitored by reviews and testing. This assumption aowed attention to be focused on the coection of data reating to time and effort.

4 VAN GENLJCHTEN: WHY IS SOFIWARE LA? 58.5 TABLE III DATA DETERMINED FOR EACH Acrrv~r~ PLANNED ACTUAL DIFFERENCE REASON EFFORT STARTING DATE ENDING DATE DURATION ) Data coection focused on the differences between a pan and reaity. A panning data were obtained from the most recenty approved pan. If a project was officiay repanned, the new pan was taken as the starting point for the comparison between the pan and reaity. The consequences of a repan wi therefore not show up in the measurements. Six projects were studied: one of them was not repanned, four were repanned once, and one was repanned twice during the study. It might be argued that the differences between pan and reaity were greater than the measurements wi show. 3) The third principe was that data coection shoud not take the project eaders much time. This was a condition stated by the deveopment department. The definition of the study and the above principes resuted in a one-page data coection form. This consisted of a tabe with the data to be coected for each activity and a cassification of reasons for deays. The tabe is shown in Tabe III. The panned and actua efforts were expressed in hours. The starting and ending dates were given in weeks. The duration of an activity was defined as the caendar period between the starting and ending dates. A panning data were obtained from the most recenty approved pan. The difference coumn indicated if there was any difference between the pan and reaity. The reasons for the three types of differences were distinguished in the fina coumn: The reason for a difference between the panned and actua effort The reason for a difference between the panned and actua starting date The reason for a difference between the panned and actua duration. A reason for the difference between the panned and actua ending date was not mentioned, because this difference can be expained by the difference in the starting date and the difference in duration. Obviousy, much of the data in Tabe III was not ony kept for the purpose of this study: the panned and actua hours and duration were aso required for norma project contro purposes. A recent survey [] showed that in practice, data of this kind are not kept as a matter of course; as many as 50% of the respondents caimed that they did not record progress data during the course of their projects. In this study the project pans provided the panned effort, starting date, and ending date. The cerica office provided the actua data, which were coected on the basis of time sheets. The actua data were Group of reasons capacity-reated personne-reated input-reated product-reated organization-reated toos-reated other TABLE IV GROUPS OF REASONS Description Reason reating to the avaiabiity of the deveopers the experience of the deveopers conditions which must be fufied the software product to be deveoped the organization in which the deveopment takes pace the toos used to deveop the software none of the previous categories vaidated in interviews with the participating project eaders every other week. The fina coumn was fied in speciay for this study. This was performed by the project eader who, in consutation with the researcher, determined the reasons for differences between panning and reaity. A cassification was used, for two purposes, to determine a reason: first, the cassification gave structure to the reasons identified and aowed resuts to be compared; and secondy, the cassification saved time for thinking up reasons. Six groups of possibe reasons for differences were identified in the cassification. The division into six groups was based on a discussion with the project eaders concerned and on a previous study [6]. The groups are isted in Tabe IV. The division into six groups has proved to be vaid for severa (software) deveopment departments. In fact, simiar studies using the same groups of reasons were appied in a number of departments. About 30 reasons for deay were found within the groups. A first cassification of reasons was identified after a discussion with the participating project eaders. A definite cassification of reasons was identified after a piot study. Simiar studies in other departments showed that the reasons were specific to the engineering environment in question because of differences among the software engineers, the type of software deveoped, and the organization of the department. This confirms the measurement principe, which states that metrics must be taiored to their environment, as formuated in [2]. The cassification of reasons, as used in this study, is dispayed in Tabe V. A reason abeed other was incuded in each category, because it was not exacty cear at the start of the study what reasons coud be expected. During the study, however, it was found that the reason other ony needed to be used rarey.

5 586 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 17, NO. 6, JUNE 1991 TABLE V THE CLASSIFICA~ON OF REASONS AS USED IN THIS STUDY CAPACITY-RELATED REASONS 11 capacity not avaiabe because of overun in previous activity 12 capacity not avaiabe because of overrun in other activity 13 capacity not kaiabe because of unpanned maintenance 14 capacity not avaiabe because of unpanned demonstration 15 capacity not avaiabe because of other unpanned activities 16 capacity not avaiabe because of other causes 19 other PERSONNEL-RELATED REASONS 21 too itte experience with deveopment environment 22 more inexperienced peope in team than expected 29 other INPUT-REQUIREMENTS NOT FULFILLED 31 requirements ate 32 requirements of insufficient quaity 33 (specs of) deivered software ate 34 (specs of) deivered software of insufficient quaity 35 (specs of) hardware ate 36 (specs of) deivered hardware of insufficient quaity 39 other PRODUCT-RELATED REASONS 41 changing requirements during activity 42 changing of the interfaces during the activity 43 compexity of appication underestimated 44 more probems than expected with performance requirements or memory constraints 45 product of insufficient quaity deveoped (redesign necessary) 49 other ORGANIZATON-RELATED REASONS 51 ess continuity in project staffing than expected 52 more interruptions than expected 53 infuence of software Quaity Assurance 54 bureaucracy 59 other TOOLS-RELATED REASONS 61 deveopment toos too ate or inadequatey avaiabe 62 test toos too ate or inadequatey avaiabe 69 other OTHER If the actua hours, starting dates, and ending dates were recorded, itte time was needed to determine the reason for any difference. In practice, determining the actua hours and starting and ending dates was found in practice to take a great dea more time than determining the reasons. This was done in an interview once every other week with the project eader in question. It was important to anayze the data during the project, because it woud have been difficut to coect accurate data after the project had finished, and vaidating the data woud have been amost impossibe. Severa reasons coud be given for each difference, with a maximum of four; in practice, it was found that the difference coud usuay be ascribed to one reason. C. Comparison of the Study and Surveys The study definition which was just described wi be compared with the surveys, as in Section II. They wi be compared with respect to their motivation, object, scope, and the data coection technique used. The motivation of the survey by Jenkins et a. [7] was to conduct empirica research on the information systems deveopment process in organizations. The survey by Phan et a. [o] aimed to coect factua data with regard to the management and contro of software projects. Thambain and Wiemon [12] investigated the practices of project managers in reation to their project contro experience. The motivation of the study described in this paper was to gain an insight into reasons for deay. The object of the three surveys was projects-jenkins et a. [7] and Phan et a. [o] took information systems deveopment projects as their object, whie Thambain and Wiemon s [12] survey was concerned with engineering projects. The object of the study described in this paper is the activities performed within a project. The scope of the surveys covered mutipe projects in mutipe organizations. This study is imited to six deveopment projects within one department. The ast and

6 VAN GENUCHTEN: WHY IS SOFWARE LATE? 587 most obvious difference between the surveys and the study described in this paper is the data coection technique. Jenkins et a. conducted interviews on 72 competed projects. Phan et a. sent out a questionnaire and received 143 quaified responses. Thambain and Wiemon coected questionnaires from 304 participants in workshops and seminars. In the study described here, data were coected and vaidated during the execution of the projects on the basis of a number of interviews with the project eaders and the avaiabe project data. Because of the differences mentioned, the study and surveys were compementary, rather than simiar. 35 PERCENTAGE OF ACTIVITIES IV. RESULTS The study took pace in a Software Deveopment Department in the second haf of 1988 through the first haf of The Department was concerned with the deveopment and integration of system software in the operating system and data communication fieds. The Department empoyed 175 software engineers and covered a range of 300 products. Six representative projects in the Department were seected for the study. A tota of 160 activities in the projects were studied. The data in Tabe III were determined for each activity; these were the panned and actua hours and the starting and ending dates. The average duration of an activity was 4 weeks, and the average effort was cose to 100 person hours. When determining the actua effort and actua starting and ending dates, the existing registration was found to be of imited vaue, because some of the data on the actua impementation of the project were not avaiabe in a usabe form. Recording starting and ending dates was no probem, because management emphasized the contro of duration. Starting and ending dates were reported at the progress meetings. The number of hours spent on each activity was difficut to determine in the first part of the study for two reasons: first, the ack of reiabiity of the recorded hours. The vaidation of the data by project eaders showed that the difference between the recorded hours and the impression of the project eader was sometimes too arge to be credibe. Second, it was found that the numbering of the activities by the project eaders was found not to be unique in every case. This meant that the hours recorded coud not be reated to activities. The actua hours were not recorded if the effort coud not be reated to activities or the vaidation indicated that something was wrong. As a resut, the panned and actua efforts coud ony be compared for 97 of the 160 activities. The most important resuts of the study are presented in the form of four figures. Fig. 5 shows the frequency distribution of the difference between the panned and actua durations of the activities. Fig. 5 shows that over 30% of the activities were finished according to pan. Nine percent show a one week underrun; 17% show a one-week overrun. Fig. 6 shows the reative difference between the panned and actua efforts for 97 activities. This figure reates to ony 97 activities due to the probems which occurred in the recording of hours for each activity. Fig. 6 shows that about 50% of the activities overran their pan by more than 10%. About 30% underran their pan by REAL - PLANNED LEAD TIME in weeks Fig. 5. Frequency distribution of the difference between the panned and actua durations (iv=160). PERCENTAGE 30 I m 10-5 n Fig. 6. OF ACTIVITIES (REAL - PLANNED) I REAL EFFORT Frequency distribution of the reative difference between and actua efforts (N=97). 1.2 the panned more than 10%. The comparison of the panned and actua figures yieded some usefu insights. It showed, for instance, that the reative differences between panned and actua efforts increased for the subsequent phases of the project; the deays and overruns increased toward the end of the project. The same resut has been found in other engineering environments [4]. This fact makes it possibe to discourage the idea that deays can be overcome as the project progresses. Figs. 7 and 8 present the reasons for the deays and overruns. During the study it was found that many activities started too ate. Fig. 7 shows the distribution of the reasons for activities which start too ate. These were divided into the groups identified in Section III. Note that when an activity started too ate because of a deay in a previous activity, it was recorded as reason 11, a capacity-reated reason (see Tabe V). This expains the arge capacity section in Fig. 7. The input-reated reasons had to do with the ate deivery of hardware components deveoped in parae with the software. The start of the software deveopment activities was aso deayed because of this. The reasons for the differences between the panned and actua duration are isted in Fig. 8. Within the groups identified it was found that the most frequent reasons for differences between the panned and

7 588 IEEE TRANSACTIONS ON SOFIWARE ENGINEERING, VOL. 17, NO. 6, JUNE 1991 Fig. 7. CAPACITY-RELAT 43 TOOLS-RELATED 2 PUT-RELATED 8 Distribution of reasons for differences between the actua and panned starting date (N = 53). PERSONNEL-RELATE 7 Fig. 8. INPUT-RELATED 23 CAPACITY-RELATED OTHER-REASONS 1 TOOLS-RELAT ODUCT-RELATED 2 35 Distribution of the reasons for differences between panned durations (N = 113). actua durations were: reasons 12 to 16: more time spent on other work than panned (these reasons were named in 27% of the cases). Reason 43: compexity of appication underestimated. Some outsiders bame a the software deays on underestimation. In this case, underestimation was given as an expanation in about 20% of the cases. V. INTERPRETATION OF THE RESULTS The resuts were interpreted during a meeting attended by the project eaders taking part, the department manager, and the researcher. In the researcher s opinion, data of this kind shoud, in the first pace, be anayzed together with the peope invoved in data coection. Six reasons for this are given: first, it is the engineer s, project eader s, and manager s job to contro software deveopment. They shoud be supported with a the avaiabe data. Second, those invoved represent the knowedge of software deveopment in the department concerned; this knowedge is needed to interpret the resuts. Third, those invoved can assess the feasibiity of any actions for improvement. Fourth, actions which are decided on by members of the organization concerned wi be accepted more easiy, and thus be impemented more quicky, than actions recommended by an outsider. Fifth, interpretation of the resuts shows the peope invoved that the data is being used for their benefit. This shoud motivate them to participate in future anayses. Finay, a meeting ike this can contribute to creating a common understanding among project eaders and genera managers regarding probems within the department. Coective interpretation of the resuts can hep to prevent the and different perceptions of the probems, as was reported by Thambain and Wiemon [12] (see Section II). During the meeting it was found that the resuts of the study confirmed and quantified a number of existing impressions of project eaders and the manager. For some of those present, the resuts provided new information. For instance, it was not cear to everyone that the amount of other work had such a significant effect on duration. The foowing are exampes of the possibe actions for improvement that were discussed at the meeting. It was found that the amount of other work in the projects studied was underestimated. During the meeting it was shown that the other work consisted mainy of maintenance. Those present decided that in future projects, more time and capacity shoud be set aside for other work. During the meeting it was shown that the maintenance activities in particuar constanty interrupted deveopment. A number of possibe ways of separating deveopment and maintenance was discussed. The possibiity of setting up a separate maintenance group was discussed and rejected. It was decided to schedue the maintenance work as far as possibe in maintenance weeks, and to incude two maintenance weeks in each quarter. It was obvious that not a maintenance can be deayed for a number of weeks. Any defect that affected the customer s operation was resoved immediatey, irrespective of the maintenance weeks. Defects of this kind were ony a sma fraction of the defects, and correcting them invoved ony a sma fraction of the maintenance effort. The vast majority of defects was found in products before they were reeased to customers. By carrying out most of the maintenance during maintenance weeks, it was hoped that deveopment coud proceed more quicky and with fewer interruptions during the other weeks. This suggestion was impemented by the department within one month after the meeting. The department wanted to gain more insight into the origin of maintenance. Another anaysis study started. Its aim was to gain an insight into the origin of maintenance in order to be abe to take improvement measures which coud reduce future maintenance effort. At the end of the meeting it was concuded that the study had yieded sufficient resuts for those invoved. A considerabe contribution was the fact that ongoing discussions coud now be supported by facts. Comparabe studies have been carried out in a number of other software deveopment departments. The resut of one of those studies is given for the sake of comparison, and aso to discourage unjustified generaizations of the resuts given so far. Fig. 9 shows the reasons for differences between panned and actua durations, which are given for 80 activities, carried out in a deveopment department which deveops systems software and CAM software [8]. The groups of reasons distinguished in Section III were again used here. The differences between the distribution of reasons given in Fig. 8 shoud be obvious. Based on ongoing measurements in a number of departments, the author concudes that the distribution of causes varies strongy for each department. Every department shoud therefore gain an insight into its

8 VAN GENUCHTEN: WHY IS SOFTWARE LATE? 589 PR03UCT-REL 37 SONNEL-RELATED 3 INPUT-RELATED 4 ORGANIZATION-RELATED 45 CAPACITY-RELATED 11 Fig. 9. Distribution of the causes of differences between the panned durations in another department [8]. reasons for deay in software deveopment projects in order to be abe to take appropriate actions for improvement. VI. CONCLUSIONS The concusions beow consist of two parts: first, the study and its resuts are compared with the surveys discussed in Section II of this paper, after which the main concusions of the study wi be restated. Three surveys concerned with the investigation of deays and the reasons for deays were presented in Section II of this paper. A comparison of the definition of the surveys and the study presented in this paper was given in Section III. The comparison showed that the surveys on the one hand, and the study on the other, were compementary rather than simiar. The comparison of the resuts of the present study with the surveys described in the iterature provides the foowing information: The average overruns found in the present study approximated the overruns found by Phan et a. [9], [o] and Jenkins et a. [7]. However, in the present study the reative ead time overrun was greater than the reative effort overrun. Jenkins et a. found the opposite resut. Over-optimistic panning was cited as a probabe cause in a the studies which examined reasons for deay. Phan et a. found that 44% of the respondents named over-optimistic panning as a reason. An unreaistic project pan and underestimation of the scope were named as major reasons in Thambain and Wiemon s [12] survey. The study described in this paper recorded underestimation of the compexity as a reason in 20% of the cases. Thambain and Wiemon s investigatiqn of the subte reasons for deay indicate that the reasons were not technica in nature, but were reated to organizationa, manageria, and human aspects. The present study shows a simiar resut. The product- and toos-reated reasons represent most of the technica reasons. They comprise ony one-third of the reasons mentioned. It must sti be noted that reativey few studies on deays and their reasons have been described in the iterature. Moreover, this statement is generay true for empirica studies of the contro of software deveopment. An empirica study of the contro of software projects was presented in this paper. An important advantage of the study and definition seected was that, in spite of the imited effort required from the project eaders taking part, resuts were achieved fairy quicky. The cooperation of the deveopers and project eaders was vita in carrying out the study. One of the conditions for the cooperation of the project eaders was that it was made cear in advance for what the data coected woud and woud not be used. Insight into the predominant reasons for deay enabed actions for improvement to be taken in the department concerned. An important concusion was that the distribution of reasons for deay varied widey from one department to another. The author recommends that every engineering department shoud gain an insight into its reasons for deay in order to be abe to take adequate actions for improvement. This study targeted the activities within a project. If a project pan is regarded as a set of agreements concerning the work to be done, it might be said that the study investigated to what extent agreements within projects were fufied. Externa entities aso have an infuence on the execution of a project pan. One exampe is the fact that departmenta management does not provide the panned resources. Another exampe is faiure of a marketing department to deiver ceary defined requirements on time. The author concudes that to some extent, a project cannot be executed according to pan, because externa entities do not fufi their agreements. Software engineers shoud continue to investigate how agreements are fufied within projects. The author woud aso recommend a comparabe study on the fufiment of those agreements which infuence the execution of a project pan, but are not controed by the project team. ACKNOWLEDGMENT The author woud ike to thank the foowing peope for their cooperation: E. Buijs, M. Fierst van Wijnandsbergen, E. der Veen, H. Keizers, G. Schoten, L. Hustman, and E. de Vries, and aso T. Bememans, F. Heemstra, M. Howard, R. Kusters, and again, M. Fierst van Wijnandsbergen, for their contributions to and comments on an earier version (see [5]) of this paper. REFERENCES [] V. R. Basii, R. W. Seby, and D. H. Hutchens, Experimentation in software engineering, IEEE Trans. Sofhvare Eng., vo. SE-12, pp , Juy [2] V. R. Basii and H. D. Rombach, The TAME project: toward improvement-oriented software environments, IEEE Trans. Software Eng., vo. SE-14, pp , June [3] F. B. Brooks, The Mythica Man-Month: Essays on Software Engineering. London: Addison-Wesey, [4] M. J. 1. M. van Genuchten, Towards a software factory, Ph.D. thesis, Eindhoven Univ. Technoogy, The Netherands, [5] M. J. I. M. van Genuchten and M. Fierst van Wijnandsbergen, An empirica study on the contro of software deveopment, in Proc. Conj Organization and Information Syst. (Bed, Yugosavia), Sept , 1989, pp [6] F. J. Heemstra, Estimation and contro of software deveopment projects, Ph.D. thesis, Eindhoven Univ. Technoogy, Kuwer, Deventer, The Netherands, [7] A. M. Jenkins, J. D. Naumann, and J. C., Wetherbe, Empirica investigation of systems deveopment practices and resuts, Inform. Manage., vo. 7, pp , [8] F. L. G. van Lierop and R. S. A. Vokers, Controing software projects: a matter of measurement, Masters thesis, Facuty of Industria

9 590 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 17, NO. 6, JUNE 1991 Eng., Eindhoven Univ. Technoogy, KJuwer, Deventer, The Netherands, [9] D. Phan, Information systems project management: an integrated resource panning perspective mode, Ph.D. thesis, Dept. Management Inform. Syst., Univ. Arizona, Tucson, [o] D. Phan, D. Voge, and J. Nunamaker, The search for perfect project management, Computerword, pp , Sept [] W. J. A. M. Siskens, F. J. Heemstra, and H. van der Stet, Cost contro of automation projects: an empirica study (in Dutch), Informatie, vo. 31, pp , Jan [12] H. J. Thambain and D. L. Wiemon, Criteria for controing projects according to pan, Project Management J., pp , June Michie van Genuchten received the M.Sc. degree in industria engineering from the Eindhoven University of Technoogy, The Netherands. He is currenty empoyed by the Eindhoven University of Technoogy, Department of Industria Engineering, Section Management Information Systems and Automation, and Phiips Eectronics (Lighthouse Consuting Group). His research interests incude the contro and anaysis of software engineering, the appication of production contro concepts to software engineering, and the reuse of software.