Cause for Project failure

Two questions we bother 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.

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.

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

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, there’s a point beyond which changes will waste time and money and disrupt the work.

Poor-Quality Work 

If rushed through the design and coding and skipped all of the quality reviews and inspections, testing found many defects, if argued for delivering the software and fixing defects later. You 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.

Believing in Magic
Commercial off-the-shelf software, or COTS, is an attractive way to save development time and money. 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.

Next time you run a software project, review the project first and remind yourself to take steps to ensure your success, you’ll be surprised at the difference it makes.