Enterprise Services
Showing results for 
Search instead for 
Do you mean 

The Three Primary Causes of Project Failures

‎08-06-2013 04:44 AM - edited ‎09-30-2015 06:57 AM

Target.jpgBy:  James (Jim) R. Hughes, Global Business Analysis Capability Leader, Hewlett Packard Company


Author’s note: My blogs address the challenges that limit applications solution delivery success, and how to overcome them.


Pareto, the Italian economist, identified the 80/20 rule—roughly 80% of effects come from 20% of the causes. For example, 80% of a company’s revenues will be derived from 20% of its customers. The long-tail phenomenon is based on the same principle—but focuses on the 20% of results rather that the 80% of effects.  For example, roughly 20% of books sold by Amazon will be attributed to 80% of authors.


The Pareto Principle also applies to the causes of software development, system integration, and COTS implementation project failures. If there are ten possible reasons why projects fail, we would expect two of these reasons to account for about 80% of the failures, and three of them to account for 90-95% of all project failures.


During the past 30 years I have been engaged in fixing different kinds of projects which have run into delivery challenges. I have reviewed statistics from multiple root-cause analyses of projects which have gone ‘red’. Both the anecdotal and statistical evidence indicates that there are three primary reasons why projects fail.


However, before we consider these three reasons, let’s dismiss some false reasons many believe are why projects fail:



False Reasons Why Projects Fail

Bad design

Rarely can a catastrophic project failure be attributed to a bad architecture or inferior software design. Yet, invariably, when projects go ‘red’ executives seem to think that throwing the right ‘technical’ resources at the project will fix it.

Team not equipped with the right tools

A well run project, with team members displaying a ‘can do’ attitude, can make just about any tool work.

Coders produce too many defects

Coders do produce defects. However, if the code is sloppy, the root cause does not usually lie with the developers but rather with project management not insisting on using best practices.

Using off-shore teams

Using remote teams can be a challenge. But as with the previous problem, the root cause lies with project management which has not required disciplined communication and requirements traceability.

Bad estimates

Projects don’t fail because of bad estimates. Good project managers deal effectively with potential budget overruns through early intervention (e.g. by reducing scope).


The three primary reasons project fail are:


  1. Poor project management. The main reason projects fail is that the people assigned to manage them simply can’t manage projects. There is a spectrum of reasons why people can’t manage projects including a lack of skills, knowledge, or experience. Some executives think that requiring PMP certification will address this. It doesn’t. I was asked once to bring back on line an ERP implementation project. The project manager and most of the team leaders had PMP certifications but the project was significantly off schedule, had hundreds of open issues, and was suffering from morale problems. I introduced PM 101 to the project, cleaned up the issues and froze the scope (see the next point) and within a few months the project was back on track and successfully delivered. The most important attributes of good project managers are knowing where the project must go (seeing the ‘big picture’), communicating the direction clearly, being firmly and consistently decisive, and paying attention to every detail.


  1. Poorly defined scope. A close second reason why projects fail is that the project team doesn’t really know what they are supposed to deliver. Even when the initial scope is defined, the project manager allows scope-creep to derail them. I recall one instance where an account executive told me he had agreed to add a particular piece of functionality to the project. I replied that he had a right to do that since it was his budget. However, I still wanted a change request so I could adjust schedule and resourcing. He said I didn’t need the change request because the client wasn’t going to have to pay for the additional functionality. I insisted on costing the change request and revising the schedule accordingly. He tried to sneak a second scope change by me but I blocked it. After that it never happened again and the team was able to keep to the schedule.


  1. Poorly defined Requirements. Developers, testers and documentation specialists need more than just scope to precisely defined requirements. When requirements are missing or poorly defined, all down-stream deliverables suffer. Well defined requirements, approved by the users’ stakeholders, are essential for supporting good project communication and providing the baseline for everything else that occurs on the project.


In short, the equation for project delivery success is simple:


Success = Defined and controlled scope (i.e., requirements)  +  Simple clear plan  +  Attention to detail


Other blog postings by Jim Hughes, which address the challenges that limit applications solution delivery success, and how to overcome them:



Blogs in the Producing Quality Software series by Jim Hughes


Other blogs by Jim Hughes:


Image for Blog.jpgJames (Jim) R. Hughes, Global Strategic Capability Leader, Hewlett Packard Company

Jim has been with HP for 33 years and currently leads a global Strategic Capabilities Management team, with a specific focus on Business Analysis and Configuration Management. Jim also manages a team within the US State, Local, and Education division of HP. He was a member of the IIBA committee that created a Business Analyst Competency Model and he participated in the development of IEEE standards. Jim graduated from Harvard University, the University of British Columbia, and Ottawa Theological Hall. He currently lives in Toronto, Canada.

0 Kudos
About the Author


Jim has been with HPE for almost 35 years and leads a matrixed global Strategic Capabilities Management team. His specific focus is on the Business Analysis capability. Jim is also a member of a team within the US Public Sector division of HPE, responsible for delivering application software to Federal and State governments. He was a member of the IIBA committee that created a Business Analyst Competency Model and he participated in the development of IEEE standards. Jim graduated from Harvard University, the University of British Columbia, and Ottawa Theological Hall. He lives in Toronto, Canada.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Aug 29 - Sep 1
Boston, MA
HPE Big Data Conference 2016
Attend HPE’s Big Data Conference to learn from peers in every industry and hear from Big Data experts and thought leaders in an exciting, energy fille...
Read more
Sep 13-16
National Harbor, MD
HPE Protect 2016
Protect 2016 is our annual conference and is the place to meet the world’s top information security talent, discuss new products and share information...
Read more
View all
What's New