Why Projects Fail – 15 Top Reasons

Is there a bottom line?  Why Do Projects Fail!?
YES!  The simple answer is that nobody stops them from failing!

As Project Manager it is your role and duty to do whatever you can to prevent projects, under your control, from failing.
As the Executive your role (as the appointed Executive Action Team) is to EAT the Red Beads!

How do I stop my projects failing?

Managing Projects is very much like driving a car.

Because projects are defined as once off activities, in this example we will not use an example like driving to work each day. 
Rather we need to think of driving off to a holiday destination. 
Therefore, with this wonderful thought firmly in mind this is how you do it!

Can we learn to stop projects failing?
The answer is most definitely YES!

Continue to read and absorb the caveats found below.
Use this wisdom and implement ways to avoid failure in your own projects.
Remember: The secret of avoiding a trap is knowing of its existence!

Ultimately, projects failing within an organization could have numerous and inter-related causes.
Listed (and accessible via the INDEX) below are the top reasons that could contribute to project failure:

Tell me about the 13 top reasons for project failure now!


1.    Operating in JUST DO IT! CMMi Level 1. maturity mode.

2.    Poor or NO Project Management (Lack of project controls / quality audits of the project process)

3.    Poorly Defined Requirements / deliverables (Poor Scope Definition)

4.    Scope Creep (or a lack of control in change management - NOT MANAGING THE IRON TRIANGLE!)

5.    Lack of Resources

6.    Poorly Defined or Unrealistic Time Scales & Estimates

7.    Inadequate (or non-existent) Testing

8.    Use of New or Unfamiliar Tools

9.    Over Optimism  Yeeee Haaaaa  LET'S JUST DO IT!!!

10.  Political Infighting (Power Struggles)

11.  Lack of User Involvement

12.  Lack of Communication

13.  Poor Risk Management

14.  Lack of Command and Control / Lack of and Accountability to a Project Management Office / Lack of and Accountability to Project Management Board / Lack of and Accountability to an allocated Sponsor / Lack of Sponsor Involvement

15.  Lack of Project Control Systems. I.e. an Enterprise Project Management System


1. Operating in JUST DO IT! CMMi Level 1. maturity mode.  (Normally indicative of a lack of formal Project Manager appointment / no signed off Project Charter / no "managed" project process / no EPMS etc.)
Back to INDEX

Before we look at the Project Charter (a key / very important project document, but also just one of the many important project control documents), the slide below shows us how an immature organization (lacking project management process - and without key control document's management firmly in place) normally operates.  CMM and CMMi deal with the quest for sustainable quality through definition of business processes in depth. 

Not about being lucky  What can go wrong will go wrong, or What can't go wrong wont go wrong!

Essentially what is required is for the organization to "up its game" towards higher levels of maturity. 
The CMMi diagram below clearly explains how the goal is to increase Productivity and Quality while reducing Risk and Waste!  The essential skillset that is required to get to CMMi Level 2. maturity is Project Managment as is shown in the slide below.

While there are many control documents in Project Management Process, the Project Charter is one of the most important as it "sets the scene" empowering the Project Manager to focus in on and get the work done.

In The Charter page of PMWay, I discuss the role of the project charter.  I also emphasize its crucial importance towards the ultimate success of any project.  (click here to revisit what the Project Charter is and why is it needed?)

The Project Charter is essentially the ‘what’ portion of the criteria of the project. It dictates exactly what is being built, created or enacted and explains in high level terms the various justification and initial scope for the project. The charter itself becomes part of the over-arching project plan. What makes it so important is that it gives a concise explanation of what the project is actually looking to achieve; all initial stakeholders for the project must sign off on the project charter to ensure they are on board with its definition and are in agreement with moving forward with the project. In many cases of project failure, a poorly defined or non-existent project charter leads to continuous revamping of the project since stakeholders are still providing input into what they ‘thought’ the project was going to do. This leads to delays and endless rework and can often end up causing project slippage or outright failure.
The Project Charter should clearly define how we intend to:  

The project manager should ensure that they have a detailed project charter in place prior to project start (the move into the EXECUTE PHASE) and that ALL stakeholders have signed off on the document.

Also take a look at the Stage Gates Two important gates are visible.  I.e. 1. at the oficial appointment of a Project Manager in the INITIATE PHASE of PMWay and 2. Signed off Project Charter at the end of the PLAN PHASE of PMWay.

2. Poor or NO Project Management  (Lack of project controls / quality audits of the project process)
Back to INDEX


Hurry... we have a deadline.  No time to plan. 

Just start digging!


What are the problems associated with immature or no Project Management?
  • The plan (or lack there of) is flawed from the start (If you don't know where you are going any road will take you there - nowhere!).
  • The project gets out of control and can't be recovered.
What causes this?
  • You have to do the work and weren't also given time for project management.
  • Perhaps you only have a 10% or 20% allotment for project management duties.
  • You were never officially appointed via sign off (from management) of a Project Charter.  With official appointment a project manager can begin to manage the project I.e. ensure adequate resources:  time, money, skilled people, project control documents in place etc.
What to do?
  • Planning a project is like setting out a roadmap.  Without it you will likely get lost.
  • Controlling a project is like controlling a car.  You have to continuously watch the road (the plan) and make little adjustments.  Imagine driving home tonight and only controlling the car 10% - 20% of the time.

With all of the aforementioned being said, the last (and probably least popular reasons, among project managers at least) when it comes to project failure is simply this: poor project management.

Now while any of the aforementioned items can cause project problems or outright failure, a good project manager can often stay on top of them. However, what about a project manager that is simply ‘bad’ at their job? It can and does happen. Sometimes, a project was adequately staffed, have a good charter, proper timetables and the backing of the primary sponsor. Yet it simply fails because the project manager did a poor job. In a previous post, I discussed the criteria for what makes a ‘good’ project manager. (For reference, that post can be found here: What makes a good project manager?) Like any other position within a company, the success of your projects and your business as a whole depends on staffing your organization with the right people.

And hiring competent, well skilled project managers / resources is no exception.

Improved PM Skillset

"I think I should know how this helmet goes on.  I have been riding scooters for two years now - you know!"

What are the problems associated with lack of PM Skillset / low maturity?
  • You projects don't finish on time.
  • Your projects are always squeezed at the end.
  • Your projects are stressful.
  • You have to deal with unrealistic expectations from immature managers or customers.
  • You feel your projects are out of control.
  • You feel you need to be a "super hero" to get everything done.
What causes this?
  • People often don't know what they don't know.
  • Their projects are out of control but they don't know why.
  • They feel they are doing okay but could benefit from formal project management education.
What to do?
  • Learn the methods, tools, processes and techniques successful professional project managers use to initiate, plan, execute and control their projects.
  • Contact a PMI Certified Global Registered Education provider in your area and get certified / only employ certified project managers!
  • Learn about CMM and CMMi.  Project / Process Maturity is not something you can buy.  It often takes many years of sustained effort to evolve and develop these skills!

3. Poorly Defined Requirements  / deliverables (Poor Scope Definition)
Back to INDEX

While the project charter describes the ‘what’, the low-level requirements explain the ‘how’. It is absolutely essential for the project manager to ensure that the primary requirements for the project are defined early and are as detailed as possible.

How not to do it...

"I'd like a set of stairs up to a bridge"

"Emergency phones installed.  Deliverable Completed."

What are the problems associated with poor requirements definition?
  • Customers will be unhappy.
  • Customers will complain and you will end up doing what they want - often at your expense.
What causes this?
  • What the customer wants was not clearly documented.
  • What you believe the customer wants is different from what the customer believes they asked for.
  • The customer did not sign off the requirements document.
What to do?
  • Find out and document exactly what the customer wants.
  • Inform everybody of the project scope.
  • Document business, functional and technical requirements.
  • Have the customer agree to and sign off the requirements documents.
What are the problems associated with Scope Creep?
  • Changes that were not initially planned for are added to the project.
  • The project takes longer and costs more than planned and there is no record of why.
And for poorly defined Deliverables:

What are the problems associated with poorly defined deliverables?
  • Difficult to get agreement that the project is finished.
  • Customer keeps waiting more, saying you didn't do it to their specifications.
What causes this?
  • The milestones or deliverables were not measurable.
  • "The customer never told us how many they wanted, so we just assumed...
What to do
  • Ensure milestones or deliverables are clearly defined and measurable (or quantifiable).
  • For example:  Red is bad, Red #ED2D2D is better.
  • For example:  1.22 GHz is better.

Holding regular requirements gathering meetings at the outset will reduce the likelihood that the requirements are incomplete. It is also important to revisit these meetings during the execution phase of the project for occasional refreshers and to ensure that the current requirements can be achieved in the allotted timeframe. Note that high and low-level scope need to be adequately itemized as well. Poor defined requirements can be a surefire way to leading to project failure.

4. Scope Creep (or a lack of control in change management)
Back to INDEX

Also known as...

"You'd like it just a bit bigger? No problem"

"Oh, still a bit bigger...ok"

"Even bigger?! It wasn't in the plan but okay..."

 "you want it even bigger than that!  um...  okay..."

When Scope Creep happens the end result is always more work than expected.

What are the problems associated with Scope Creep?
  • Changes that were not initially planned for are added to the project
  • The project takes longer and costs more than planned and there is no record of why
What causes this?
  • Disingenuous customer with a determined value for free policy.
  • Poor change control.
  • Lack of proper initial identification of what is required to bring about the project objectives.
  • Weak project manager or executive sponsor.
  • Poor communication between parties.
  • Not having a method to handle or recognize changes.
What to do?
  • Document the change management process to be used and followed by the project team.
  • Educate the project team to recognize a change or deviation from the plan.
  • Follow the change management processes.
  • Have the customer agree to and sign off the requirements documents and any change management documents that occur during the lifecycle of the project.

The bane of many a project manager’s existence, scope creep is the tendency for stakeholders and project participants alike to try to ‘sneak’ new features or requirements into a project after the primary requirements have already been agreed upon. Adding scope to a project during its run is not in itself unusual, but it is imperative for the project manager to ensure that any changes in scope are effectively discussed and any changes to the schedule are also itemized. The famous ‘triple constraint’ (scope, time, cost) demonstrates that one cannot change scope within a project without changing one of the other items as well.

Project managers need to be cognizant of the fact that adding scope without addressing the overall project itself can lead to missed schedules or a poor quality deliverable, since scope was added at the expense of other things, like product quality. 

Manage the Iron Triangle or it will manage you!

Note:  The sides and middle of the traingles are defined differently.  This does not pose a problem to Project Managers as essentially all four components (Time, Cost, Scope and Quality) are seen to work together to produce the best result.  Click here to see that there are, in fact, even more dimensions that can be taken into consideration.


This is the end result of not managing the IRON TRIANGLE on a basic task:  I.e. lets dig a hole.

PMBOK sees the above as a project management process.  I.e. shown in the image below.

Click here for an article that ties the Iron Triangle into CMM. 

Remember to "Mind the Gap!"

5. Lack of Resources
Back to INDEX

You do not have enough people, the right skillsets, or the team is not committed to the project.

Every project needs resources. How much and how many depends on the size and scope of the project. Like most project managers can attest, working on projects with scarce resources is not all that unusual. Management will always invariably try to minimize costs while working with maximum productivity. Projects running somewhat ‘lean’ are not an unknown in project management circles. However, there are situations where the project is simply unattainable because the allocated resources are woefully insufficient. In those types of situations, it may be a case whereby key personal required for project success are just made not available.


An important paper on this subject that is a must read by Mats Engwall and Anna Jerbrant is entitled,  "The resource allocation syndrome: the prime challenge of multi-project management?".   You can also click here for a summary of this "Resource Allocation Syndrome" paper.  The key takeaway from the paper is that the resource allocation issues are a consequence of flawed organisational procedures rather than poor project management practices.  Project and portfolio managers responsible for resource allocation are only too aware of this. However, they are powerless to do anything about it because, as Engwall and Jerbrant suggest,  addressing the root cause of this syndrome is a task for executive management.

And if you click here you will find a page dedicated to the same resources being asked to work on Projects and also to provide ongoing services to clients.

What are the problems associated with Lack of Resources?
  • Tasks take longer than expected to complete.
  • Deadlines and milestones get missed.
  • Project completion date comes into jeopardy.
  • You end up working double-shifts to complete all the work.
What causes this?
  • There was no pre-commitment of resources to the project.
  • The project was not supported.
  • There was no analysis and documentation of all skillsets required.
What to do?
  • Get executive sponsorship for the project.
  • Document which resources and skillsets are needed to get the job done.
  • Create a plan that gives enough time to get the job done with the allocated resources.
  • Pre-assign the required resources to the team.
  • Work in hours left to complete work not in % completed.

6. Poorly Defined or Unrealistic Time Scales and Estimates
Back to INDEX

One of the most important duties for a project manager is scheduling. A schedule defines the timeframe, milestones and key deliverables for a project. It is probably one of the most challenging yet essential parts of the project manager’s job. Which is why when it is either performed inadequately or a sponsor or set of stakeholders give an unrealistic set of goals and timeframes to the team, the project manager must act accordingly. One of the hardest jobs a project manager must undertake is the ability to say ‘no’ or ‘that timeframe is unrealistic’. Management never likes hearing what can’t be done. But invariably, a project manager that willingly ignores all the red flags pertaining to a project’s schedule is just as guilty if the project ultimately fails as the executive team.

Remember Murphy’s Law of Short Cuts:   The problems associated with any short cut are inversely proportional to the shortness of the cut!

What are the problems associated with poor Time / Schedule estimating.
  • An unrealistic timeline (tasks in the project schedule) or budget will be agreed to
  • You will not be able to do all the work in the time allocated
What causes this?
  • No formal estimating method.
  • Estimate confidence is low.
  • Volume of work not understood.
  • Not enough information.
  • Not involving the "key people in the know" / subject matter experts who can help you pin down timelines and costs.
What to do?
  • List all the work as well as possible.
  • Estimate each work package.
  • Add up all work packages.
  • Do not give "elevator" estimates if possible.
  • Always give answers using a range of dates  -  A rule of thumb:  Estimates where the work is well defined:  15% inaccuracy. Estimates where the work in not well defined:  100% inaccuracy.

7. Inadequate (or non-existent) Testing
Back to INDEX

Throughout the life cycle of any project, there have to be timeframes and iterations allocated to testing the integrity of the deliverable. This almost seems like a no-brainer. Yet it is striking just how many times projects hit the wall or end up failing miserably in the marketplace because of inadequate testing. Product quality is something that any organization strives for since that actively contributes to the company’s reputation. As such, allocating the necessary cycles and resources to testing at various stages of the project life-cycle is absolutely essential. That includes unit testing, regression testing, alpha/beta testing by consumers and standard build-based testing. In many cases where released products displayed poor quality, the most obvious culprit in those circumstances is a schedule and process that did not allocate the necessary time for testing.

8. Use of New or Unfamiliar Tools
Back to INDEX

Good tools are essential for the success of any project. Whether that be access to a good software development environment, a good CRM system or a good defect tracking system, tools are a staple component to the success of any project.

However, a common fallacy that many project managers and team leaders often make is attempting to utilize a new or unfamiliar tool at the same time that a new project is starting. This can lead to severe problems during the life-cycle of the project since the team now has to contend with their common project duties while also dealing with the learning curve of the new tool. This can easily lead to delays or outright missed issues if the team members are too novice on the tool to be able to utilize it wisely.

As a rule of thumb, it is usually the best policy when thinking of adopting new tools to bring them into the fray gradually. Allow the team to use existing tools for any new or current projects and make adoption of the newer tools reside on a parallel track. Ensure that adequate training is provided and only begin usage of these new tools for any new projects once you are satisfied that the team is up to snuff with their usage.

9. Over Optimism
Back to INDEX


Not about being lucky

"To be sure, to be sure".
Project Management is not about fast moves, and four leaf clovers! 
Click the leprechaun to revisit the all time classic:  "Recovery Project Ireland" in Technicolor! 

What are the problems associated with Over Optimism?
  • There was little or no planning before deciding you can get the job done.
  • The task you agree to turns out to be more work than expected.
  • It takes you longer and jeopardizes other deliverables.
What causes this?
  • Not enough time spent planning.
  • You may have been pressured into giving an answer right then and there.
  • Didn't have a full understanding of the work involved before committing.
What to do?
  • Take the time to fully understand the work before agreeing to it.
  • It's okay to say the work is not possible or will take too long.
  • Only agree to work when you're sure it can be done.  This will benefit you and your manager.

10. Political Infighting (Power Struggles)
Back to INDEX


It exists in companies as well as governments. Functional managers and executives with their own vested interest in specific aspects of the business can often come to blows over new or existing projects.

The worst has to be the political player with a covert agenda who is also a backstabber.  I.e. undermining the project and typically, you don't even see them coming.


Power struggles are especially prevalent in situations where a project may span several different business units that may or may not all utilize the same process or have the same mid to long-term mission statements. As a project manager, it is important to be able to function adequately as the referee and mediator in these situations and try to smooth out any differences of opinion as they arise. Groups of stakeholders or functional managers involved in a project that do not see eye-to-eye on the project scope, its implementation or its schedule can be extremely detrimental to the overall success of the project.

It is difficult enough to get it right with project management.  Why make it even more difficult with infighting and power struggles!

Maturity is essential!  I.e. Understanding PMP, respecting project roles and working as a team:  putting the project goals first and working together towards success!

11.  Lack of User Involvement
 Back to INDEX

A project that is producing some deliverable is likely going to have a specific user constituency. i.e. a group of individuals that are the consumers of that product. Whether it be a new hardware widget, a piece of software, or even an augmentation to some existing mechanism, users will be the ultimate customers. As such, it is imperative that the users are actively engaged during the project life-cycle to ensure that their particular feedback and suggestions are effectively cataloged. This is often done with a small subset of product ‘consumers’ who participate in some of the initial product screenings. This then expands to more involved Alpha and Beta release cycles where a broader number of users are brought in and their input is used to guide the project. Failure to actively engage with users can often lead to an end result deliverable that does not meet the needs and expectations of the users.

12. Lack of Communication
Back to INDEX

What are the problems associated with poor, or a lack of communication?
  • Team members do not have the information they need when they need it, causing delays.
  • Issues or changes do not get escalated.
  • Project reporting (and therefore control [RAG status etc.]) is sluggish.
What causes this?
  • The project's communication plan was not completed.
  • The project's communication plan does not have enough detail.
What to do and prevention?

Find out the communications requirements of all team members and stakeholders, document them in a communication plan and follow the plan.

  • Who needs the information.
  • What do they need to know.
  • What level of detail.
  • How do they want it.
  • When and how often do they need it.
  • How should it be delivered, and by whom.

A project management tool often used to pin down communication requirements is called a RACI matrix

You can also take a look at the section in PMWay on Communication Skills

13.  Poor Risk Management
 Back to INDEX

"Sorry about the project, I left it in my car this morning and there was a bit of an incident"

What are the problems associated with Poor Risk Management?
  • Unexpected events cause delays.
  • Domino effect of things going wrong.
What causes this?
  • No formal risk management.
  • Just try to predict the big things that can go wrong.
  • It's the sum of all the little things that make a project late.
  • Nothing is more stressful than trying to keep on schedule when unexpected things keep happening.
What to do?
  • List all the work as well as possible.
  • Figure out what can go wrong with each piece of work.
  • Prioritize each risk:  -  High / Med / Low probability By High / Med / Low impact (or effect).
  • Sort the list.
  • Create a plan to deal with the risks at the top of the list.

PMBok states that a Risk Register must be created.  Also that a Risk Management Plan must be in place.  I.e.  monitoring and controlling risks on an ongoing basis.

Remember managing risks on your project (avoiding them is first prize) is one of the neatest ways to manage the Iron Triangle I.e. Time and Cost.  If risks happen then these will surely impact negatively on the project.  Preventing them is a no brainer!

Take a look at the Risks / Issues / Actions page in this web site to see how to use Issue Management to which monitored and controlled actions are put in place and tightly managed (via project minutes) to ensure Risks as mitigated.

14. Lack of Command and Control / Lack of and Accountability to a Project Management Office / Lack of and Accountability to Project Management Board / Lack of and Accountability to an allocated Sponsor / Lack of Sponsor Involvement
 Back to INDEX

PMWay web deals with this subject in great depth.

The PMWay Vision is the quickest way to get a handle on this.

The Project Management Boad and Sponsor are key.

Why all this control?
Because it is easier and cheaper to keep the project on the road than to allow it to career off out of control into a ditch! [Click the Show Button]

15. Lack of Project Control Systems. I.e. an Enterprise Project Management System
 Back to INDEX

Again PMWay web deals with this subject in great depth.

The PMWay Vision is the quickest way to get a handle on this.

The Enterprise Project Management System and EPMS Light or Heavy are key.

The above ties to an understanding of Ideas on using the EPMS for Transparency, Accountability , Governance and delivery of quality need satisfying products and services to the Stakeholders (our valued clients) which is critical for project / our success - into the long term.

Back to INDEX

Projects succeed and sometimes, projects fail. Knowing what factors can lead to project failure is important for the project manager so they know what to look for when managing their projects. The aforementioned list should give a project manager the necessary reference to be able to stay on top of things within their areas and get the jump on any problems that arise, thereby minimizing the likelihood of project failure and maximizing the likelihood of success down the road.