Quality software development

Abstract

There are a number of authors who have documented problems with our software development processes. Unrealistic schedules and budgets, with continuing steams of requirements changes lead to projects with a high risk of failure. There is too often only a vague idea of the required solution at the outset of a project and this makes it difficult for estimators and developers. It is commonly accepted that there will be requirements changes throughout the project. This means that managing changes becomes a challenge.Most IT experts agree that failures occur far more often than they should. Most developments are expensive, with a difficult process affected by a series of problems including poor project management, cost and schedule overruns, poor quality software and under-motivated developers. Unfortunately few project post-mortems are conducted, and little understanding is gained from the results of past projects. Most project failures are predictable and avoidable, but many project managers cannot identify what success and failure factors are important, early enough to take action.Many factors are described in the literature including project pressures with project stakeholders impacting the cost and quality of the project, organizational structure, communication with customer/users, and amongst customers, developers & users, stakeholder politics, commercial pressures, poor leadership, lack of upper management support and personality conflicts, unrealistic, unarticulated goals, poor user requirements and requirements specification, customer satisfaction; scheduling. project budget, and inaccurate estimates of resources, poor project management, poor reporting of project status, unmanaged risks, inability to handle project complexity, the project management process and tracking tools, sloppy development practices, software development methodologies, use of immature technology, product quality, business processes and resources.There are generally more than 1 or 2 reasons for a project failure which may be caused by a combination of technical, project management and business decisions. Most organizations do not see preventing failure as an urgent matter. Unfortunately, the literature on project failure is based on handful of failed project case studies.Our research is concerned with getting quantitative evidence on aspects contributing to failure. If we know what factors are responsible for failure we can focus on these factors and improve the quality of our development processes for future projects. We also should recognize effects of project failure on development staff. Late projects usually cause long hours of unpaid overtime, loss of motivation, and stress. This then leads to high staff turnover and its associated costs. This research provides an update on prior studies and tests the validity of previously reported anecdotal evidence about project failure factors. We build on previously reported research but our concern is with everyday projects, not the high profile projects normally reported in the newspapers.We collected a set of project data and teased it out to find the main failure factors for a whole group of projects. We first developed a questionnaire targeting software developers? perceptions of practices affecting project outcomes. Our questionnaire was based on extensive discussions with 90+ software developers as well as the literature. The survey included 88 questions organized into sections covering sponsor/senior management, customer/user, requirements, estimation and scheduling, the development process, the project manager and project management, and the development team. We also asked if the project was a success or a failure. The questionnaire was distributed to practitioners from a large U.S. financial institution where each responded by answering it twice. It was then distributed to various companies in North Eastern U.S.A., a number of different Australian companies; and a number of different Chilean organizations; each respondent in the latter groups answered the questionnaire once.We collected data on 304 projects, 70 were failures. Of the failed projects, 49 were in-house and 21 outsourced, 65 were development projects and 5 maintenance projects. The largest project that failed had 180 developers. We examined the data using frequency analyses and as well investigated relationships between the most important factors.