Lessons from failed projects

CHAOS report in 2009 showed that the successful projects were 32% of the total number of projects, the other 68% of projects were either failures or challenged.


Many of us were part of challenged or failed projects. Marking project as successful does not change the fact of being failed project as many projects have to suffer change of scope, time, or cost that will change the whole shape of this project.

It’s stressful to fail in a project, but failure projects will give you some lessons you will never learn from successful projects.

Andrew Makar, the writer of this article mentioned 3 lessons can be learned from failed projects and was referring to one of the projects he was part of.

The project was an IT related project involve“implementing multiple web applications that supported resume collection and online candidate assessment”. Andrew was a business analyst for an HR recruiting project.

The project involved many internal IT professionals, consultants, and project managers. One of the main causes of the project failure is that they did not develop an integrated project schedule for the whole project. This in fact will raise many issues in such project as they will not be able to identify the critical path(s) or to have a good estimates for the time and cost of this project.

So Andrew considered that the first lesson from this failed project was “The project schedule is your friend”, as it’s important to build and manage project schedule for the success of any project.

From what I’ve learned in MGT598 and from my experience in my professional life. It’s very important to have a written, scheduled plan for any project to be able to identify the critical path and any bottleneck in resources or time constraints.
The other lesson Andrew set was “You can’t escape the project triangle even if you’re an executive”, where he was referring to the scope, time, and cost. As they were running the project, one of HR executives decided to increase the scope of the project while thinking that this will not impact the other constraints of the triangle which are the cost and time, and for sure this was wrong assumption as the change in the scope without even studying the impact and the outcome of such change had a bad impact on the project as they missed the deadline and the cost of the project was over what was budgeted.

The lesson was to make sure that the scope is well defined and any changed in the scope is studied with impact analysis highlighted. This lead us to the issue of scope creep as well.

The third lesson was “Project heroics only lead to project failure”. Andrew described how the consultant in the project he was working in was acting like a hero and was working alone saying “just leave him alone so he could work” where at the end nothing from what he promised was delivered!

We learned in our field project “Raising funds” that the team work is a key in any project for it to be successful.


Do you agree with these lessons?

What are other lessons you believe can be learned from failed project?

Have you been part of failed project and what have you learned?

Reference: http://www.techrepublic.com/blog/it-consultant/the-three-best-lessons-i-learned-from-a-failed-project/

4 thoughts on “Lessons from failed projects

  1. Thanks for the useful article, all what you have mentioned are great lessons from a failed project, in addition to what was mentioned I would like to add to lesson one that in the schedule the project manager will distribute the tasks among the project team.
    I fully agree that controlling the scope, the cost, and time as well effective team work are the basis for successful project.

  2. I find it interesting that changing the scope of the project without examining the time and cost can lead to failure. I attribute failure in project management with poor leadership or lack of dedication for the team. However, someone might increase the scope of the project because they want it to grow and accomplish more. These are the mistakes made by passionate leaders and hardworking teams. So even though the intentions were right, not setting the proper project parameters can be a huge downfall. The same concept goes for the ‘project hero’. This mistake is made by someone who is so invested in the project that they are not able to delegate responsibilities to ensure there is enough time to get all of the work done.

  3. I believe at some point in time everyone is involved with a failing project, meaning at some point we will all have experience with it. The project failures will really depend on the type of project being worked on. This list could be endless and range from poor project planning to a failure to mitigate risk. The writer has some good lessons to be learned. I especially like Scope Creep and Project Heroics. Having an accurate schedule and well defined scope are obvious core management principals that need to be address for every project. Scope Creep is something very important that tends to happen quite often. It can ruin both the budget and schedule. The lesson learned is that the scope should be followed to the tee and if there is a change in the scope you essentially need to start from square one. You need to go through all the different management phases/processes from project planning to mitigating risk and more. The third lesson learned I really like as well since I have experienced this. There is no “i” in team and a project management approach almost always involves a team or group of individuals. It should never be left to a “project hero” as the team should work together. This is especially true if the particular individual has a history of missing deadlines or talking a “big game”.

  4. This is a great recap of lessons learned from failed projects. Your 2nd lesson learned “You can’t escape the project triangle even if you’re an executive” is right on. I have had the opportunity on several occasions to be part of projects where scope was updated after the project was already in flight. In such cases, it is important to ensure that when the scope is changed that the time required and costs are also updated to reflect such change. When the scope change is reflected across the board, I have seen that it is important to communicate the impact to the business owners. When business is aware of the full impact of their scope change, it gives them the opportunity to truly see if such change is necessary. While it is not possible to “escape the project triangle”, it is critical to properly account for the changes and communicate the results to business owners. When things are communicated, there should be no surprises and management can make necessary decisions.

Leave a Reply

Your email address will not be published. Required fields are marked *