Why do projects fail?

Let's start with a definition of project success criteria:

• It is delivered on time.
• It is on or under budget.
• The system works as required

Only a few projects achieve all three. Many of them aren't even used!

Why does this happen? The reasons commonly pointed could be:

• Lack of top management support
  
• Lack of User Involvement
• Inadequately trained and/or inexperienced project managers
• Failure to set and manage expectations
• Failure to adequately identify, document and track requirements
• Poor plans and planning processes
• Poor effort estimation
• Scope Creep
• Cultural and ethical misalignment
• Misalignment between the project team and the business or other organization it serves
• Inadequate or misused methods
• Inadequate communication, including progress tracking and reporting
  
• Poor leadership at any and all levels
  
• Long or Unrealistic Time Scales
• No Change Control System
• Poor Testing

This are all organizational problems, not technical ones. But they too have their contribution:

• Lack of development methodology
  
• Weak technical leadership
• Difficulty in sharing among pairs (particularly problematic when passing information to newcomers)
  

I found this old paper, where it lists top 10 ways to guarantee the failure of a systems project:

1. Don’t use a specific methodology because coding is all that is really important
2. Create the project plan by working backwards from a drop-dead system completion date
3. Don’t bother with a data model [editor: I'd had to had Domain Model]. Just build whatever tables [static structure] you need.
4. Use a Technical Lead that has never built a similar system. Hiring such talent is too expensive.
5. Hire forty developers to make the coding go faster
6. Build the system in Java, even though most of the development team still thinks that Java is coffee and you have no intention of ever deploying to the Web
7. Three months before the system goes live, assign one junior developer to handle the data migration
8. Skip the testing phase because the project is way behind schedule
9. Change the system to support critical new requirements discovered during final development
10. Buy a commercial, off-the-shelf package and customize it … a lot [editor: sorry, it was true in the past, but not necessarily in the future...]
    

The paper ends with the following recommendations:

1. Don’t cut corners, methodologically. In the long run, this results in system failure or an inadequate system that doesn’t meet the users’ needs.
2. Audit each major deliverable and step along the way for accuracy and correctness.
3. Carefully monitor top management support for the project. Make sure that managers are aware of the progress of the team.
4. Secure the correct technical lead for the project.