99328

By Watts S. Humphrey

MAY 20, 2002



Two questions have often bothered me about software work. First, why do competent software professionals agree to completion dates when they have no idea how to meet them? Second, why do rational executives accept schedule commitments when the engineers offer no evidence that they can meet those commitments? Where software is concerned, many otherwise hardheaded executives willingly accept vague promises and incomplete plans. Management’s undisciplined approach to schedule commitments contributes to every one of the five most common causes of project failure:

You might think that pushing for an aggressive schedule would accelerate the work, but it actually delays it. When faced with an unrealistic schedule, engineering teams often behave irrationally. They race through the requirements, produce a superficial design and rush into coding. This mad scramble to build something – anything – results in a poor-quality product that has the wrong  functions, is seriously defective and is late.

Inappropriate Staffing

The only way to complete an engineering project rapidly and efficiently is to assign an adequate number of people and then protect them from interruptions and distractions. This helps build the motivation and effective teamwork needed for quality results. When managers fail to provide timely, adequate and properly trained resources, their projects will generally fail.



Changing Requirements During Development

To start designing and building products, engineers must know what product to build. Unfortunately, management, marketing and even customers often don’t know what they want. Worse, they think they know and then change their minds partway through the job. While the requirements (or objectives) normally change in the early phases of a job, there’s a point beyond which changes will waste time and money and disrupt the work.



Poor-Quality Work

Consider the case of Greg, manager of a manufacturing software project that had to meet an accelerated delivery date set by his boss. Greg unmercifully pushed his engineers, who rushed through the design and coding and skipped all of the quality reviews and inspections. Testing found many defects, but Greg argued for delivering the software and fixing defects later. Greg met the deadline, but the system was a disaster. It was so unreliable that the software had to be fixed every time a change was made in the product or product mix. Excessive factory downtime and repairs cost the company over $1 million. When executives push for unrealistic schedules, the project either will be late in delivering a working product or will produce a product that doesn’t work. There’s a saying about software quality: “If it doesn’t have to work, we can build it really fast.”



Believing in Magic

Commercial off-the-shelf software, or COTS, is an attractive way to save development time and money. But COTS isn’t a silver bullet. If not properly managed, it can be a disaster. A COTS product that works perfectly in demonstrations, for example, may crash when subjected to different hardware configurations, higher data rates or even data-entry errors. You must test the product thoroughly enough to expose previously untested conditions. If the program is troublesome when stress-tested, it will almost certainly be troublesome when used in production.



– Watts S. Humphrey

Humphrey is a fellow at the Software Engineering Institute at Carnegie Mellon University, where he led the Capability Maturity Model effort and other work to improve software development. This article is adapted, with permission, from Winning With Software: An Executive Strategy (Addison-Wesley, 2002).