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 “failed” 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     

The slippery path to productivity improvement

Productivity tools simply aren't delivering increased productivity even when a project is managed “by the book”. It is demonstrated that there may be more systemic, albeit counterintuitive, causes for the “productivity paradox”. Specifically, the productivity potential of software engineering tools may be squandered not because organizations fail to institute the necessary managerial practices but because the software development environment is a complex social system that causes such practices to have unintended consequences. To support this view, the author uses a system dynamics microworld of the software development process to simulate the long term productivity trend in a a hypothetical project environment managed “by-the-book”. The microworld lets the project team examine possible causes one by one through controlled experimentation and hence allows them to discern true causal relationships in a failed project. The results indicate productivity erosion was unintentionally accelerated by perfectly “good” planning and control practices     

When good enough software is best

“You can get it fast; you can have it cheap; you can get it right. Pick two”. That sign could be displayed on the wall of every software development organization; and yet most of our customers want all three. The author tackles this dilemma. He contends that we don't rationally establish a proper balance among the critical project parameters: cost, schedule, staffing, functionality and quality. Our customers want us to optimize all these parameters, even when this is clearly impossible     

Using metrics in management decision making

The amount of code in NASA systems has continued to grow over the past 30 years. This growth brings with it the increased risk of system failure caused by software. Thus, managing the risks inherent in software development and maintenance is becoming a highly visible and important field. The metrics effort within NASA's Mission Operations Directorate has helped managers and engineers better understand their processes and products. The toolkit helps ensure consistent data collection across projects and increases the number and types of analysis options available to project personnel. The decisions made on the basis of metrics analysis have helped project engineers make decisions about project and mission readiness by removing the inherent optimism of “engineering judgment”     

The power of process [software processes]

Some people in the software development community think “process” is a four letter word. They think software processes are rigid, restrictive, and inefficient. They hold that the best way to run a project is to hire the best people you can, give them all the resources they ask for, and turn them loose to do what they do best. Sure, they say, there will be some amount of unproductive work is (also known as “thrashing”). After all, developers will make mistakes. But they will also be able to quickly and efficiently correct these mistakes at a cost that is less overall than the cost of processes. This point of view has intuitive appeal. At the beginning of a project, a focus on process certainly does take time away from productive work. If that trend were to continue throughout the project, it wouldn't make sense to spend much time on process. Software industry experience, however, has found that for projects that don't pay attention to establishing effective processes early are forced to slap them together late, when slapping them together takes more time and does less good. The article points out the problems caused by inattention to process, explains what happens when a project thrashes, and discusses the use of process versus creativity     

The software design studio: an exploration

Some software designers have recently turned for inspiration to the process of building design to improve development practices and increase software's usefulness and effectiveness. Architects' education revolves around the studio course, which promotes: project based work on complex and open ended problems; very rapid iteration of design solutions; frequent formal and informal critique; consideration of heterogeneous issues; the use of precedent and thinking about the whole; the creative use of constraints; and the central importance of design media. M. Kapor (1991) suggested that software practitioners needed to “rethink the fundamentals of how software is made” and proposed the architect's role in building design as a fruitful analogy for software professionals seeking to reform software practice. This analogy helps us focus on usefulness, usability, user needs and practices, and other technical and nontechnical aspects of good software design. It highlights concerns about people's lives and work practices and how people “inhabit” systems. Several authors have explored similarities and differences between software design and building design, including some who have pursued the software implications of architect Christopher Alexander's design patterns     

Engineers don't build [software development]

Most of us never approach a construction project with a software development methodology. However, construction projects exhibit much higher success rates than software development projects. The author identifies the “master-builder” approach taken by most software development projects where the developers assume the role of architect, engineer, builder, and inspector. Most large-scale construction projects abandoned the approach nearly 100 years ago. Why do we do it for large-scale software projects? Engineers design systems or buildings, and programmers or builders implement them. That approach yields greater success rates in terms of quality, time, and budget     

Do we ever really scale down? [Software management]

The argument that scaling down project engineering practices is just as difficult as scaling them up is, in polite terms, specious. The practice of building software has always involved an initial effort to decompose the task into manageable chunks-and from there, we always scale up. The difference between engineering large and small projects focuses on the issues of coordination and communication between the manageable chunks and the people working on them. Practices at the “chunk” level reflect a combination of the organization's culture and the project manager's personal preferences. In other words, we start by decomposing the problem and then build the management structure necessary to bring the various pieces together. We start small and scale up, so where does “scaling down” enter the picture? This issue is largely of concern only to those who value the purity of their methodologies above the practical needs of producing software     

The evitability of software patents

Responding to Kenneth Nichols' article in Computer (“The Age of Software Patents”, April 1999, pp. 25-31), the author disputes the two claims: “software patents are neither inherently good nor bad” and “software patents are here to stay.” The author thinks software patents are not impersonal technology, but rather a part of an intellectual patent system that is a social artifact. Because all social artifacts are fair game for judgments, software patents fall into that category. Not only does the author think it reasonable that an interested party examine the ethics and morality of any branch of the legal system (of which software patents and copyrights are a part), but he feels professionals in relevant areas have a social duty to do so. After exploring several arguments for software patents and copyrights, the author settles on the evitability of software patents, though he points out this does not ensure they will be avoided. However, he thinks there are good arguments for avoiding software patents for other more practical and just forms of monopoly for software     

Gauging software readiness with defect tracking

In the competitive commercial software market, companies feel compelled to release software the moment it is ready. Their task is treacherous, treading the line between releasing poor quality software early and high quality software late, Finding a sound answer to the question: “is the software good enough to release now?” can be critical to a company's survival. That answer is, sometimes based on gut instinct, but several techniques can put this judgment on firmer footing     

Gray rebuts Bach: no cowboy programmers!

The author presents a response to an article by James Bach (“Microdynamics of Process Evolution”, Computer, p. 111-13, Feb. 1998). The author considers the importance of checklists in software project planning and the use of process standards     

The project scoping gamble

A discussion is given on how to get people and technology to work together. The authors argue that software project managers can learn important lessons from the gambler. Software development is a gamble. Its a risky game-not unlike high stakes poker. And, like a gambler who must try to figure the best bet, when we're put on the spot trying to “scope” a software project we feel in need of some advice. Judging the timing and resources for a project is difficult when there's not much to go on. And yet, if you fail to estimate correctly, developers, management, and customers will all be unhappy. Defining a proper scope for your project won't guarantee its success, but a poor and especially an overly restricted scope may doom your project to failure. A gambler playing poker uses a variety of strategies to improve the odds of winning     

Leverage your lessons [project management]

In today's fast-moving market, software project teams don't have time to make several attempts to meet a customer's requirements. Teams need to be smart about what they do learning from the experiences of colleagues within their own organization and in the industry. In short, teams need to take the time to do things as “right” as they can because they don't have time to do things over. Why do we often have to do things over? Why do we repeat the mistakes of the past? It's related to this: Insanity is doing things the same way we did them before, but expecting different results. It's hard for a team to get better at what it's doing if it doesn't think about its work and how to improve it. Some project teams do, in fact, think about how and why their projects worked. They gather and document lessons learned. Some teams share that information with others in their organization, and a few teams attempt to review what others have learned as they start a new project or new phase of a project. But many teams do none of this. They're the ones that encounter the same problems over and over again, attributing them to bad luck when, in fact, poor project learning and poor organizational learning are the underlying causes     

Software design methods: life belt or leg iron?

Do software design methods have a future? The issue I explore in this article is concerned with the problems that the use of design methods can present. It can be expressed as a question: “Will the adoption of a design method help the software development process (the `life belt' role), or is there significant risk that its use will lead to suboptimum solutions (the `leg iron' role)?” (I use “method” to mean “a way of doing something”, rather than using the more pretentious-sounding “methodology”, which more correctly means “study of methods”). To address, but not necessarily answer, this question, I first consider what designing involves in a wider context, and then compare this with what we do, and finally consider what this might imply for the future     

TAP: a software architecture for an inquiry dialogue-based tutoringsystem

In the tutoring agenda planner (TAP) project, we study the feasibility of implementing the inquiry teaching method of Collins and Stevens (1991) as tutoring software. This paper describes the software architecture for TAP-1-a simple inquiry tutoring shell based on the theory of inquiry teaching. The inquiry teaching style has the objective of teaching scientific reasoning skills through a “localized” sequence of well-planned inquiry dialogue. To complement the “localized” dialogue planning framework inherent in the theory of inquiry teaching, the TAP-1 architecture has adopted the “global” curriculum planning technique. TAP-1 has successfully demonstrated the inquiry teaching style through an inquiry planner within an intelligent tutoring system shell. In addition, PADI-a geography tutor that delivers inquiry teaching style-has been implemented using TAP-1. A group of students performed well in an evaluation activity of the tutor. They also foresaw the potential of TAP for achieving the aim of cultivating scientific thoughts     

Software benchmarking

In software, “benchmarking” usually compares two companies' practices and results, but, occasionally, it involves sets of companies. For example, there are benchmark comparisons of industry software, such as insurance software, military software, telecommunication software, commercial software, and the like. In other domains, “benchmark” usually means the collection of a substantial body of quantitative data. Benchmark comparisons of various computers, for example, rate their relative performance in at least half a dozen categories. Historically, software benchmarks have been qualitative rather than quantitative. Even the Software Engineering Institute's Capability Maturity Model (SEI CMM) is essentially a qualitative benchmark that ranks company performance on a five-point scale that lacks quantification for specific quality and productivity levels     

The I/O subsystem-a candidate for improvement

A computer system can be partitioned into hardware and the software executing on that hardware. The hardware consists of processor(s), memory, and “everything else”. The “everything else” we generally combine under the umbrella “I/O, whose job it is to manage the availability of information to and from the processor(s) and memory”. That information comes from storage devices, networks, and nonstorage devices. The I/O subsystem is the collection of all three; its influence on performance is a reflection of how well it manages the availability of information to and from all three. The impression today, from both the hardware side and the software side, is that the I/O subsystem can certainly stand improvement. The author considers improvements to the I/O subsystem     

OPM3要素对项目组合管理能力影响的SD建模与仿真

根据组织项目管理成熟度模型（OPM3），确定影响项目组合管理能力的OPM3要素，分析OPM3要素与项目组合管理能力的因果关系，构建系统动力学模型，仿真模拟OPM3要素对项目组合管理能力的影响。仿真结果表明：OPM3要素与项目组合管理能力正相关；OPM3要素对项目组合管理能力的影响在短期内并不显著；在OPM3要素中，对项目组合管理能力影响较为显著的是战略执行与规划、组织领导能力和信息分析。     

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     

Software “engineer”? Time will tell

A discussion is given on the legal and policy aspects of information technology use and development in the US. There is a continuing proliferation of individuals and companies who portray themselves as being or employing software “gurus”, “experts” and “engineers”-titles that imply the knowledge and capability to resolve programming problems. Many of these individuals either lack these skills and experience or are applying their knowledge in environments where it has no value. This problem is particularly acute in the area of telephony or data/software/telecommunications convergence. There are signs, however, that your ability to describe yourself as an engineer or your company's services as engineering, without proper training and certification, may be coming to an end