Australian Software Development: What Software Project Management Practices Lead to Success? J. M. Verner National ICT Australia Australian Technology Park Alexandria Sydney, Australia
[email protected]
Abstract We surveyed a number of Australian software practitioners in order to understand what software development practices were used in their recent software projects. We were particularly interested to discover what project management practices are common in Australian software projects. The relationship between practices and software project outcomes enables us to investigate why some projects succeed and others fail. We found that nearly 20% of projects had no lifecycle methodology and 10% of our respondents did not understand what was meant by a software development lifecycle methodology. Many recognized software practices are not being applied consistently in the projects investigated. Fifty percent of projects began with unclear requirements. Risk assessment is not normally a part of the development process and the organizations are not learning from their mistakes as post mortem reviews are much more likely to be held for successful projects than they are for unsuccessful projects.
1. Introduction In order to gain an understanding of Australian software development practices and to identify possible research opportunities we used a previously developed questionnaire [20] to collect data from Australian software developers about software projects on which they had recently worked. The developers we contacted were asked to describe a recent IT project, either successful or unsuccessful. Our practitioner sample is not a
N. Cerpa Departamento de Ingeniería de Sistemas, Universidad de Talca, Camino Los Niches Km. 1, Curicó, Chile
[email protected]
random sample but rather a convenience sample of practitioners known to us. The questionnaire was organized into seven sections; however owing to space limitations we only consider three sections related to project management here: • Project management, • Requirements, and • Cost/effort estimation and scheduling The project management perspective is important because most software engineering research has emphasized “technical matters above behavioral matters” [10]. Moreover, “there has been a general lack of quantitative survey-based research regarding early non-technical aspects of software development”. The motivation for this work is to explore project management practices in order to provide a preliminary set of project success factors for Australian software project managers. This will give general guidance for both project managers and business managers to help ensure that the software development projects they are responsible for succeed. We discuss, in Section 2, details of the questionnaire and characteristics of the project data, in Section 3, the results of our survey are described, and in Section 4, we identify and discuss areas for further research.
2. Questionnaire Responses We received completed questionnaires from 42 Sydney software developers each reporting on a different software development or maintenance/ enhancement project (i.e., 42 projects). The
Proceedings of the 2005 Australian Software Engineering Conference (ASWEC’05) 1530-0803/05 $20.00 © 2005 IEEE
majority of our respondents were developers involved with software for use within their own organizations (financial institutions, banks, pharmaceutical companies, insurance companies, etc.).
3. Results and Analysis Our sample size is quite small but large enough to gain some useful insights into both Australian software development practices and to identify promising areas for further research. Of the projects our respondents chose to describe, 78% were successful, 78% were development rather than maintenance/enhancement projects, 66% of the development projects were successful and 88% of the maintenance/enhancement projects were successful. The percentages of full time employees on the projects was 1-4 = 29; 5-9 = 37; 10-19 = 16; 20-29 = 2; 30-39 = 5.5; 40-99 = 13; and 100-180 = 2.5 (range 1-103, median 7). We asked our respondents what development methodology was used; 19.5% of the projects had no prescribed development methodology, 31% used a waterfall or a modified waterfall methodology, 2% used a prototyping approach, 2% the spiral model, and 10% an in-house proprietary methodology. Twenty six percent of respondents did not answer this question and the rest (9.5%) apparently did not understand what was meant by a software development methodology. In response to the question “Was a defined software development lifecycle methodology (your own or another) used? Explain what this methodology was”, comments such as “GUI based”, “procedural way”, “simple method to acquire requirements”, “users + stakeholders”, “user workshops”, “tick sheets listing all tasks required to be done” etc., were made. No respondents reported on a project that used incremental delivery. The percentage of “yes” responses to the survey questions is shown in Table 1. Table 2 shows those variables with a significant relationship with project success (
