Top 7 Reasons for Project Failures

We all know that more projects fail – in some way or another and to some degree or another – than succeed.

But what causes those failures? Perhaps a better insight into the root causes will help us to avoid or mitigate some of those failures as we are attempting to deliver on our project engagements.

Related Article: Success or Failure? Collaboration is Key to Success

I decided to take an impromptu survey of business analyst and project manager colleagues, and connections as well as CIOs, CEOs, creative directors and PMO directors, and CTOs to see what they thought were the top causes of project failures. I received a little over 150 responses – a good sampling – and created a top 7 from those enlightening responses.

1. The project has gone over budget.

Too common, very painful. I always say, a 10% budget overage is usually acceptable and if not, can probably be fixed over a relatively brief period of time. However, a 50% overage will almost always be disastrous, will likely never be acceptable, and probably can never be fixed. At least I’ve never been able to fix one that is that far off the mark. The key is to stay on top of the project budget on a weekly basis. Weekly review, analysis, and re-forecasting of the project budget will help the business analyst and project manager to keep the budget manageable and will mean those in charge of the project financials are never surprised by a project budget that has gone off the mark by 50%. They will realize there is a problem in time to take proper corrective action.

2. The project is too far off the timeline.

The next most common problem – the project has gone too far off schedule. So many variables can cause this one…work that wasn’t planned but can really be assigned to a change order, gold-plating of the solution, poorly estimated work efforts, a project delivery team that is lacking the right skills to get the work done on time…the reasons for missing the schedule could be nearly endless. What do you do to get it back on track? If it’s realized too late or corrective action doesn’t happen at the first sign of a scheduling problem, then there likely isn’t really anything that can be done. You keep moving forward because you have to…but you’ll never get the the project back on the proper timeline.

3. Requirements were poorly defined.

Requirements are the lifeblood of the project. Good requirements are the basis for estimating and pricing, building the schedule out, building the right solution for the customer, recognizing when change orders need to happen, properly testing out the solution, and rolling out the right solution to the customer’s end user base. If requirements are poorly defined, then any or all of these could miss the mark. When that happens, the project will experience many issues, possibly a decent amount of expensive re-work.

4. The customer was not ready to start.

Sometimes the customer just isn’t prepared to start. I had this happen once when my business analyst and I were working on requirements definition with the customer. They weren’t ready because they didn’t understand enough about the potential solution to connect the dots with us on their business processes and how they translated into real project requirements and a functional design. I had to halt the project and line up some customer training. Likewise, sometimes the customer says they are ready, but they still have some project defining left to do on their side or possibly even some issues completely unrelated to the project at hand that are getting in the way and have to be taken care of first. I’ve had that happen many times in my consulting practice with clients I’m working with. The end result is time and effort and budget wasted on work that basically gets erased, leaving the project a mess when the work is restarted.

5. Delivery team did not have the right resources.

When the project is started with the wrong team in place, it can be extremely painful. You didn’t realize you needed a database guru with ‘x’ skill set or experience. Now the project has started, and you need that experience ASAP. What are you going to do? The project and project timeline suffer as a result. And onboarding project resources later in the project that do have the right experience or skill set can be expensive.

The best situation is never to start the project without the right team ready to go, but that can’t always be the case because you may not realize you don’t have the right team till the project is well underway.

6. Inaccurate estimating of the work to be performed.

This can be a common issue. Often, initial estimating is performed by an account manager or technical sales person, and that often leaves the project manager, business analyst and tech lead in the position of making that original estimate work because it was the basis for pricing the effort. You can’t write change orders if the effort hasn’t changed. The end result is a project that goes off budget if the work is performed as planned but there aren’t enough hours and dollars in the project to cover it. Hence, a project failure.

7. The project did not have proper support of the organization.

Any project undertaking that lacks support at the top of the organization is unlikely to remain viable for long. Funding and staffing will be an issue, and client confidence will suffer as well if they become aware that the project does not have the support of the delivery organization. Reasons for this could be a realization that the project does not align well with the delivery organization’s core competencies or possibly the direction the are planning for future project engagements. Either way or for whatever reason, the project is likely doomed.

Summary / call for input

This is my top seven reasons for project failures as gathered from BA, PM and related project colleagues around the world. What are your top reasons? What would you change on this list or add to it? Please share your own experiences and discuss.