Standish Group Research Articles

The Economic Impact of Learning and Flexibility on Process Decisions

The perception that software projects have unusually high failure rates has fueled the debate on software process. In the 1990s, the Standish Group estimated that the total economic toll of cancelled or overrun software projects could reach several tens of billions of dollars in terms of wasted effort and opportunity costs. Worse yet, even when delivered on time and on budget, software rarely has any significant salvage value when it fails to meet user needs. This article argues for an economic basis for rationalizing process selection decisions. It demonstrates how, under conditions of uncertainty, learning and flexibility affect such decisions. Uncertainty is a critical driver in process selection because it's ubiquitous in software development and it determines the degree of flexibility and learning needed to maximize economic value.

How large are software cost overruns? A review of the 1994 CHAOS report

The Standish Group reported in their 1994 CHAOS report that the average cost overrun of software projects was as high as 189%. This figure for cost overrun is referred to frequently by scientific researchers, software process improvement consultants, and government advisors. In this paper, we review the validity of the Standish Group's 1994 cost overrun results. Our review is based on a comparison of the 189% cost overrun figure with the cost overrun figures reported in other cost estimation surveys, and an examination of the Standish Group's survey design and analysis methods. We find that the figure reported by the Standish Group is much higher than those reported in similar estimation surveys and that there may be severe problems with the survey design and methods of analysis, e.g. the population sampling method may be strongly biased towards ‘failure projects’. We conclude that the figure of 189% for cost overruns is probably much too high to represent typical software projects in the 1990s and that a continued use of that figure as a reference point for estimation accuracy may lead to poor decision making and hinder progress in estimation practices.

6.3.2 Goal / Strategy Maps Methods, Techniques and Tools to Specify Requirements in Different Evolutionary Contexts

Abstractthis paper reports the status of a research program that deals with the issues specifically raised by Requirements Engineering (RE) in the context of Information System (IS) evolution projects. This research program was triggered by the ‘Chaos’ report by the Standish Group, which explains that the lack of adequate RE methods techniques and tools is a major cause of failure of IS projects, and on the other hand, by Bohem's report, which says that most of IS projects are set in an evolutionary context rather than for developing new IS. Our goal was three‐fold: (i) to identify the methodological frameworks for doing RE in IS evolution projects, (ii) to build adequate modeling techniques that match the need of these frameworks, and (iii) to propose adequate methods and tools to deal with IS evolution requirements. This paper reports on each of these aspects.

SYSPOINT: Unit of Measure for IT Infrastructure Project Sizing

What can be done to improve the success rate of IT infrastructure projects? The Standish group considers an IT project successful when it is completed on time and on budget, with all the features and functions originally specified. Thus, time, cost, and scope – the triple constraint of project management is measured for success. The initial project estimation directly results in constructing the baseline for the two success parameters – time and cost. The traditional software estimation models uses lines of code and function points as sizing unit of measure. The IT infrastructure projects are significantly different from software development projects to use the software sizing techniques. This paper defines the concept of size for IT infrastructure projects. Specifically, the project size for IT infrastructure projects are measured in terms of the eight factors (server, workstation, printer, LAN, WAN, handheld, server applications, and client applications), infrastructure related software components, and the complexities defined based on the physical and functional categories of those factors.

The Impact of Revitalized Management Practices on the Adoption of Information Technology: A National Survey of Local Governments

T he emergence of new information technologies such as electronic government, virtual workplaces, and electronic democracy has been widely discussed in recent years (Bonnett, 1999; Kamarck & Nye, 1999; Peirce, 1999). This study examines the impact of revitalized management practices on the use and effectiveness of these information technologies, as well as other factors that shape information technology in local government, such as stakeholder pressures and demands, and policies and procedures. In addition, this study examines the effect of information technology on the use of revitalized management practices. Revitalized management practices are defined in this study as those that promote increased openness, mutual support, and risk taking by employees and managers (e.g., Berman & West, 1998; Garson, 2000). This study is based on a national survey of city managers, in cities with a population of more than 50,000, conducted during the spring and summer of 2000. In addition to the above, it also provides information about the uses of new and established information technologies in local government. This article contributes to the literature by exploring, in a systematic fashion, the role of management practices that revitalize public organizations. Previous systematic studies have analyzed the adoption of information technology from other perspectives, such as the role of leadership and managerial champions, strategic planning, concern for productivity and improved service delivery, and the external environment, including user involvement and fiscal scarcity (e.g., Bajjaly, 1999; Borins, 1998; Bozeman & Bretschneider, 1986; Ewusi-Mensah & Przasnyski, 1991; Garson, 1992; Standish Group, 1995; Stevens, Cahill, Overman, & Frost-Kumpf, 1994; Swain, White, & Hubbert, 1995; Tapscott & Caston, 1993; Thompson, 1992; Weikart & Carlson, 1998). Researchers have also addressed the reasons behind information technology failures

Project Termination Doesn't Equal Project Failure

One of the most frequently cited software project statistics comes from the Standish Group's 1995 Chaos report (http://www.standishgroup.com/visitor/ chaos.htm): “A staggering 31.1 percent of...

Project termination doesn't equal project failure

One of the most frequently cited software project statistics comes from the Standish Group's 1995 Chaos report (http://www.standishgroup.com/visitor/ chaos.htm): A staggering 31.1 percent of [software] projects will be canceled before they ever get completed. The Chaos report, and numerous documents citing it, label these canceled projects as and imply that all 31.1 percent of them were canceled because of poor software management. This implication is both false and hazardous. It is false because, particularly in an era of rapid change, a lot of software projects are properly started, well managed, and properly terminated before completion because their original assumptions have changed. It is hazardous because it often leaves software managers with the following temptation: It's becoming clear that continuing this project will waste company resources. I should probably have the project canceled now, but that would make me the manager of a failed project and wreck my career. I'll be better off if I say nothing, keep the project going, and look for a new project to transfer to. To counter this train of thought, the author reviews the main sources of project termination determined in the Chaos report, and estimates how likely each termination source applies to a well- or poorly managed project.

Knowledge management technology and the reproduction of knowledge work practices

Organizations seeking ways to manage their knowledge assets are increasingly turning to information technology for solutions. As knowledge management systems are being developed and implemented, it behooves both practitioners and researchers to learn from the successes and failures of more established types of information systems including MIS and DSS. According to the Standish Group, the implementation success rate for these systems runs at around 30%. Many argue that these low success rates are, in part, attributable to technologists’ lack of understanding of the situated work practices of the systems’ user communities. This has lead to increasing calls for research on work practice in the field of Information Systems. Unfortunately, it is not always clear what is meant by work practice. Furthermore, the consideration of work practice outside of its circuit of reproduction can be misleading. By circuits of reproduction we mean the reciprocal relationships through which practice creates and recreates the objectified social structures and conditions in which it occurs. In this paper, we adopt Bourdieu's Theory of Practice to illuminate work practices and their circuits of reproduction. Relying on data that were collected during an eight-month ethnography of knowledge work practices in a US-based, Fortune 500 manufacturing firm, we focus on the situated “gatekeeping” practices of a group of competitive intelligence analysts and explore how their situated practices were at odds with the generalized “gatekeeping” practices embedded in a knowledge management technology whose implementation they themselves were advocating. We argue that their inability to see this incongruence until very late in the pilot implementation is associated with an understanding of their work practices in isolation, i.e. outside of their circuits of reproduction.

4.2.4 Guiding Principles for Next Generation Computer‐Aided Systems Engineering Tools

AbstractThe Standish Group recently made major waves when it reported a disturbing 50%+ failure rate among software development projects. It places the blame squarely on a number of factors including; failure to understand and deliver customer requirements to design personnel, lack of real time decision support in concert with requirements, as well as delivery mechanism to feed requirements to downstream development tools–all of which falls in CAD/CAE poor purview of systems architects. This was brought closer to home at the 1999 INCOSE International Symposium, when Gerard Le Lann in his “Reality Check” paper threw the focus of blame from software to systems. “like blaming the transmission for engine problems”. This paper attempts to define some high level guiding principles for tools needed to support “systems thinking” and describes the features of these next‐generation systems development CAD/CAE environments needed to counter these alarming trends.

CORBA

article Free Access Share on CORBA: from vision to reality Author: Karen D. Boucher The Standish Group International, Inc., Dennis, MA The Standish Group International, Inc., Dennis, MAView Profile Authors Info & Claims StandardViewVolume 6Issue 1March 1998 pp 14–16https://doi.org/10.1145/293376.293384Online:01 March 1998Publication History 2citation476DownloadsMetricsTotal Citations2Total Downloads476Last 12 Months1Last 6 weeks0 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteeReaderPDF

Feasibility studies

Is a cancelled project a bad project? After surveying about 8,000 IT projects, the Standish Group reported that about 30 percent of all projects were cancelled ("Charting the Seas of Information Technology", 1994). Capers Jones reports that the average cancelled project in the US is about a year behind schedule and has consumed 200 percent of its expected budget by the time it's cancelled (Assessment and Control of Software Risks, Yourdon Press, 1994). Jones estimates that work on cancelled projects comprises about 15 percent of total US software efforts, amounting to as much as $14 billion per year in 1993 dollars. In spite of these grim statistics, cancelling a project is, in itself, neither good nor bad. Cancelling a project later than necessary is bad. The trick is to perform the minimum amount of work necessary to determine that the project should be cancelled.