Five reasons why software projects fail

Computerworld - 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:

Unrealistic Schedules
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