My Theory on Why IT Projects Fail

September 9, 2008 | Author: PM Hut | Filed under: Project Management Musings

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

Share this article:
  • Facebook
  • LinkedIn
  • TwitThis

Related Articles

3 people have left comments

[...] stated before that we have to consider the CHAOS Report results in a recent article on my theory on why IT projects fail. But we, PMs, already know that all these measurements work in tandem and need to keep this in [...]

The CHAOS Report 2009 on IT Project Failure - PM Hut wrote on June 16, 2009 - 10:38 am | Visit Link

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

Phil Simon wrote on January 7, 2010 - 7:44 pm | Visit Link

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.

Andy wrote on April 18, 2011 - 3:31 pm | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories