Access the full text.
Sign up today, get DeepDyve free for 14 days.
S. McConnell (1996)
Rapid Development: Taming Wild Software Schedules
R. Pressman (1998)
Manager: Fear of Trying - The Plight of Rookie Project ManagersIEEE Softw., 15
This research has been fully supported by the Chilean grant FONDECYT 1030785
Standish group report: There's less development chaos today. SD Times
(1994)
CHAOS: Project failure and success report report
R. Glass (2002)
Facts and fallacies of software engineering
B. Boehm (1991)
Software risk management: principles and practicesIEEE Software, 8
Capers Jones (1996)
Why software fails, 4
(1994)
Standish group report: There's less development chaos today http://www.sdtimes.com/article/story-20070301-01. html 13. Standish Group International. CHAOS: Project failure and success report report
J. Brooks (1978)
The Mythical Man-Month: Essays on Softw
Frederick Brooks (1975)
The Mythical Man-Month
R. Charette (2005)
Why software fails [software failure]IEEE Spectrum, 42
J. Pinto, S. Mantel (1990)
The causes of project failureIEEE Transactions on Engineering Management, 37
Narciso Cerpa (ncerpa@utalca.cl) is an associate professor in the computer science department of the Faculty of Engineering at the Universidad de Talca
Kurt Linberg (1999)
Software developer perceptions about software project failure: a case studyJ. Syst. Softw., 49
(2007)
Standish group report: There’s less development chaos today
Verner@gmail.com) is a visiting professor of software engineering at CSE
M. Jørgensen, Kjetil Moløkken-Østvold (2006)
How large are software cost overruns? A review of the 1994 CHAOS reportInf. Softw. Technol., 48
R. Glass (2002)
Software Engineering: Facts and Fallacies
(1998)
Software Runaways
L. Owens (1996)
The mythical man-month: Essays on software engineeringIEEE Annals of the History of Computing, 18
(2000)
On Time Within Budget
Introduction We have been developing software since the 1960s but still have not learned enough to ensure that our software development projects are successful. Boehm 2 suggested that realistic schedule and budgets together with a continuing steam of requirements changes are high risk factors. The Standish Group in 1994 noted that approximately 31% of corporate software development projects were cancelled before completion and 53% were challenged and cost 180% above their original estimate. 13 Glass discussed 16 project disasters. 5 He found that the failed projects he reviewed were mostly huge and that the failure factors were not just management factors but also included technical factors. Linberg in 1999 found that 20% of software projects failed, and that 46% experienced cost and schedule overruns or significantly reduced functionality. 8 Later, Glass revisited failed projects and found that poor estimation was high on his list of failure factors. 6 In 2007 the Standish Group reported that 35% of software projects started in 2006 were successful compared with only 16% in the corresponding 1994 report; however, the 2007 CHAOS report still identifies 46% (53% in 1994) of software projects as challenged (having cost or time overruns or not fully meeting user's requirements) and 19% (31% in 1994) as outright failures. 12 The validity of the Standish Group findings has been questioned as not consistent with cost overrun results of other surveys. 7 Jørgensen and Moløkken-Østvold suggested that there are serious problems with the way the Standish Group conducted their research and that the findings were biased toward reports of failure because a random sample of top IT executives was asked to share failure stories when mailed confidential surveys. Recently Charette 4 commented that "billions of dollars are wasted each year on failed software projects" and that "we have a dismal history of projects that have gone awry." 4 Charette suggests that from 5%-15% of projects will be abandoned before or shortly after delivery as hopelessly inadequate. 4 Other recent studies, suggest various failure rates for software development projects up to 85%. 7 Stories of software failure capture public attention and in general there is a perception that software quality is not improving but getting worse. Developing software systems is an expensive, and often a difficult process. Although there are many guidelines for successful software development, 9,11 few project post-mortems are conducted, and little understanding is gained from the results of past projects. The project manager (PM) and the development team must deal with many pressures from project stakeholders (for example, upper level management, marketing, accounting, customers, and users) during the software development process. These pressures impact both the cost and the quality of the software produced. There are generally more than one or two reasons for a software project to fail, and it usually is a combination of technical, project management and business decisions. Many software project failure factors have been described in the literature. 1-13 However, most organizations do not see preventing failure as an urgent matter. It is not understood why this attitude persists. 4 Because most of the literature is based on a handful of failed project case studies, in our research we analyze 70 failed software projects to determine those practices that affected project outcome. We are interested in providing, from the perspective of software practitioners, quantitative evidence targeting those aspects of the development process that contribute to project failure. Essentially, we are interested in updating the results of prior studies and testing the validity of previously reported anecdotal evidence. To date, no one has taken a set of project data and teased it out to identify, for a whole group of such projects, the most common failure factors. We are interested in everyday projects that are not high profile enough to be reported in the literature. Our work builds on that previously reported by Boehm, 2 Charette, 4 Glass, 5,6 Jørgensen and Moløkken, 7 Linberg, 8 and the Standish Group, 12,13 among others.
Communications of the ACM – Association for Computing Machinery
Published: Dec 1, 2009
Read and print from thousands of top scholarly journals.
Already have an account? Log in
Bookmark this article. You can see your Bookmarks on your DeepDyve Library.
To save an article, log in first, or sign up for a DeepDyve account if you don’t already have one.
Copy and paste the desired citation format or use the link below to download a file formatted for EndNote
Access the full text.
Sign up today, get DeepDyve free for 14 days.
All DeepDyve websites use cookies to improve your online experience. They were placed on your computer when you launched this website. You can change your cookie settings through your browser.