Back to Basics: Why do Projects Fail?

I was working for an IT services company in early 2000. The much-dreaded Y2K problem had just passed without giving us too much trouble, and we had gotten a big project from a U.S based Fortune 500 company. They wanted us to re-engineer their existing system using Java and CORBA. Those were the two of the hottest technologies in those days probably at the peak of the hype cycle.

I remember that we were all elated and just couldn’t believe our luck that we will be using the latest and greatest technology. What we didn’t realize at the time was just how much new technology can hurt a project. Anything that is new and unknown just increases a project’s complexity—and that’s just what happened.

In those days, the Internet was still in its infancy. In addition, there was not much out there about CORBA. Somehow, we got hold of a book on the topic, but it had to be shared among all the team members. To cut the story short, we faced a lot of risks and issues because of the new technology being used. Somehow, we finished the project, but it took six months longer than what we had originally estimated.

An unknown technology is only one of the reasons for project failure. There are many others, some of which are more harmful than an unknown technology.

A PwC study of over 10,640 projects found that only a tiny, tiny portion of companies (2.5% to be exact) completed 100% of their projects successfully. Failure is part of project management. Let’s try to understand why!

Failed vs. Challenged Projects

A project is considered a failure if it does not meet the defined objectives or if it fails to deliver the agreed-upon requirements. Some projects are also considered failed if they don’t meet financial parameters or if they fail to meet the Return on Investment (ROI) target.

A project is considered challenged if it delivers most or all of the agreed-upon requirements, but if it is delivered late and/or goes over budget. A project is also considered as challenged it fails to achieve the right balance between the six project management constraints. Delivering most of the requirements means that the final product, service, or result has fewer features and functions than it was originally envisaged.

Reasons Projects Fail or Become Challenged

Leadership Related Reasons

  1. A project sponsor is a person or a group who provides resources and support for the project and is accountable for enabling success. If there is no sponsor or if a sponsor does not have the requisite authority, a project is doomed from the start.
  2. A project can fail if there is no clear authority and/or accountability established. For example, a project manager is either not identified early or does not have sufficient authority to lead the project.
  3. Challenges or failure can occur when the senior management gives more focus to technology or technical details, losing sight of the desired business outcome.
  4. A final leadership-related reason for failure is the general lack of transparency. For example, if the leadership does not share all the details with the team.

Organization Related Reasons

  1. An organization’s priorities can change in the middle of the project, leading to changes in a project’s priorities, as well. This results in failure or a project becoming challenged.
  2. The same is true if there is a lack of organizational culture to complete the projects. Many organizations give greater thrust to building a preeminent product. In the process, they lose focus on customer demand, and the product launch is invariably delayed.
  3. Projects can fail or become challenged when there is no consistent methodology for managing projects within an organization. Different projects use different methodologies of project management.

Project Management-Related Reasons

  1. One of the most common reasons for project failure is when a project manager is either inexperienced or not knowledgeable enough. Many people are taken from technical roles and pushed directly into project management without being given proper training.
  2. Even when the project managers are experienced, they often spend more time on implementation and put the plan on the back burner. Overall poor planning results in challenges/failure.
  3. Sometimes plans are made for the senior management and quality auditors, but then they are not followed. The plan not being followed in letter and spirit dooms a project.
  4. If there is inadequate monitoring and control, many projects do not follow a proper process for monitoring on a regular basis and run into difficulty. In some projects, the periodicity of monitoring is not decided while in others monitoring is done superficially.

Project Initiation-Related Reasons

In my previous article, I wrote about how to start a project. The chances of failure increase if projects are not initiated properly. Here are some major points from that article, which can lead to project failure:

  1. Goals and objectives are either not properly defined or are unclear and fuzzy.
  2. Goals and objectives change frequently. Shifting goal posts are never good for any kind of project.
  3. The customer is not involved right from the beginning of the project.

Resource Related Reasons

  1. Project team members have inadequate domain knowledge or experience.
  2. Project team roles are not properly or clearly defined. There is a lack of resources for planning and team members do not have proper assignments.
  3. There is a lack of coherence among the team members. They do not actively help each other.
  4. Project team members are not motivated.
  5. Some of the project’s team members, who are more experienced or knowledgeable than the others, are over-allocated (i.e. they are assigned more tasks than they can chew).
  6. Project team members do not have the requisite tools to produce consistent results.

Scope Related Reasons

  1. The project scope is not properly defined. A project cannot succeed without a formal scope statement and Work Breakdown Structure (WBS).
  2. There is frequent scope creep. Scope creep is the addition of features and/or functionality to product scope without corresponding adjustment to customer-approved time or cost.
  3. There are too many changes in the project. Changes are part and parcel of every project and they are not bad, but too many changes can lead to project failure.

Schedule Related Reasons

  1. Project tasks are either not properly estimated or the project team makes too many estimation assumptions.
  2. Timelines are unrealistic (usually happens because of customer or senior management pressure).
  3. The project schedule is not properly defined. The best way to create a good project schedule is by carefully analyzing the project network diagrams.

Risk Management-Related Reasons

  1. Risks are not identified, documented, analyzed, and prioritized.
  2. There is inadequate or poor risk planning.
  3. Risks are not regularly monitored, re-analyzed, and re-prioritized.

Other Reasons

  1. There is inadequate or poor-quality planning.
  2. There are inadequate testing activities.
  3. There is inadequate or poor communication among project stakeholders.
  4. The project team does not regularly communicate with the customer.
  5. Customers do not regularly participate in project activities and team meetings.


I have written thirty-four reasons for failed or challenged projects. From your experiences you could possibly add a few more, but they will most likely be related to the reasons written above.

More important than finding the reasons for failure is finding out what is ailing your project. You should read these reasons again, cogitate, and brainstorm with your team to come up with two or three major reasons for harm within a challenged or failing project. Then, take some positive actions to make your project successful while there is still some time.

Which reason from the above list is most detrimental for the project? Would you add anything else to the above list? I would love to hear from you in the comments below.

Next Webinar

You’re Invited to Join a WBS Schedule Pro Presentation

Written by Praveen Malik
Praveen Malik, PMP, has two-plus decades of experience as a project management instructor and consultant. He regularly conducts project management workshops in India and abroad and shares his project management thinking in his blog, PM by PM.
Share This Post
1 Comment
  1. Excellent article!

    I would add that the scope statement should include boundaries – what is included and “what is not included” in the project. Often scope creep comes from “what is not included” in the project.

Leave a Reply