My Theory on Why IT Projects Fail
My Theory on Why IT Projects Fail
By Jorge Dominguez
The number of failed IT projects ranges in the 60% to 80%. But, what constitute a failed project? Why do they fail? They are IT projects but is it IT’s fault that they failed? There are many theories around and, yes, I will give you mine.
A failed project may be one in which one of the required features is not working according to the specifications, but all the other 20 features work well. Seriously, many times it is very badly subjective.
First and foremost, projects fail because we don’t define project success at the start of every project and as a consequence any minor mistake can be used to classify the project as a failed project. Think about it, if all project stakeholders defined success for each project from the beginning it will make it very difficult that if met the projects will be labeled as failed. And it could be as simple as a statement in the project plan saying this project will be successful if:
- All the scope and only the scope defined in the Project Scope section is delivered on time
- Project deliverables are of high quality, 90% defect free
- The project cost was within 10% of the budgeted amount, plus or minus
If I had a similar statement such as the above in every project, even if there were defects, as much as 10%, my project could not be labeled a failed project as long as all the 3 points above were met. Bottom line, define success. Make it easy for everyone to know how the project will be successful.
Just because it is an IT project and it failed it is not necessarily IT’s fault. What about if the user refused to participate, as it is very common? It is still an IT project and it will certainly be labeled as an IT failed project but it is clearly not IT’s fault.
In more general terms, the Standish Group International has been publishing the CHAOS report for a number of years now. This report examines the reasons why achievable project success often turns into fruitless endeavors and has identified a project success scale that would most likely improve your project’s probability of success. The CHAOS Ten and their weighted points according to their influence on a project’s success (the more points the lower the project risk):
| Success Criteria | Weighted Points |
| User involvement | 19 |
| Executive management support | 16 |
| Clear statement of requirements | 15 |
| Proper planning | 11 |
| Realistic expectations | 10 |
| Smaller project milestones | 9 |
| Competent staff | 8 |
| Ownership | 6 |
| Clear vision and objectives | 3 |
| Hard working, focused staff | 3 |
| Total | 100 |
Take into consideration the CHAOS Ten in all your projects. Although no project requires all 10 factors to be successful, the more factors that present in the project strategy, the higher the level of confidence. Don’t you think so…? Well, I do.
Jorge Dominguez, PMP®
http://www.Expiriance.com
Jorge
Good post. I’d agree with all of your reasons but why isn’t data quality on there? As I’m sure you know, so many projects are doomed from day one because once organizations get around to trying to test the build of a new system, the data is in such horrible shape that the project is irrevocably harmed.
ps
Surely the declaration of a successful project is defined in any software development contract? I would be very surprised otherwise (I am assuming of course you are discussing large projects here). Also, your 3 statements are just targeted at the developers responsibilities, what about the clients commitment to the project?
My experience is that on large projects the contract is often negotiated between client and developer with little or no technical intervention with the sole aim of winning the contract. Where technical input is sought it often conflicts with pre-negotiated upper management cost/time projections and therefore ignored. The seeds of disaster are thus sown.