I'll start…The most valuable lesson I've learned is that a Risk that is present at the beginning of a project will not go away by itself and will only show it's ugly(ier) head again at the end of a project if not resolved. Lesson learned? Don't delude yourself into thinking that just because the project has a long timeline you can get rid of the risk later. Eliminate project risks early and often!
What valuable lesson have you learned from projects that have failed? Saving Changes...
Mitch KraytonPresident| Krayton SeminarsDenver, Co, United States
You learned one thing that did not work. If you are a cat, you will learn never to do that again. If you are a delusional human you will continue to do it again and again expecting a different result.
Learning is all about having the freedom to fail. Success is learning how to stand back up more times than you fall down. Saving Changes...
Ken BensonProject Manager| Acxiom CorporationConway, Ar, United States
One of the lessons I have learned is to track all issues, action items and risks in one Excel Workbook. Make the information and updated information available to all. Assign, prioritize and set a due date for all the issues, items and risks and keep assigned personnel responsible and accountable for mitigation and closure. A public posting in SharePoint or a common drive is the way to ensure all have access. SharePoint provides a history of the changes and that is an additional benefit. Saving Changes...
Bradley NortonProgram Manager| Abbott LaboratoriesLibertyville, Il, United States
Never underestimate the power of a sponsor who doesn't understand what it takes to implement a project. I actually had a wildly successful project that was implemented six months ahead of any industry benchmarks, but didn't meet the time line one of the project sponsors had secretly guaranteed deemed a failure. Even after the post mortem, where all of the users, developers and other key stakeholders indicated that the project delivered, she still rated it as a failed implementation. Saving Changes...
Ken BensonProject Manager| Acxiom CorporationConway, Ar, United States
Another lesson is to have a meeting at the closure of the project. The discussion should be free flowing with all ideas and comments being recorded and no justification is required. Capture the items in three categories: Would definitely do again, would do differently and would not do again. Post this document in a publicly accessible area for others to learn. Someone said, "Learn from the mistakes of others because we do not have time to make them all ourselves!" [I think it was Admiral Rickover.] Saving Changes...
I fully agree with Jennifer for this if one risk which is identified at an early stage but ignored can be a potential disaster at later for the project which leads to failure. One of the lessons that i learned for project failure is "Gaps" it may be a requirement understanding or a communication or may be as is process gap which leads to project failure. Saving Changes...
Vaughn SmithProject ManagerCourtenay, British Columbia, Canada
Mitch is right, but organizations constantly do the same thing hoping for new results. They often are incapable of learning from their mistakes. Documenting lessons learned is poorly done and even when it is, other project managers don't heed the warnings. Saving Changes...
The lesson that I learnt from a project failure is that process should be strictly enforced even under extreme/exceptional situations. In one of my projects we skipped the review phase because of time constraint and the project failed.
The requirements kept changing even in the last minute and we just shipped the product after doing an informal review. After the delivery of the project the quality was found to be poor and we did not have the review report to track what went wrong.
Alan CaseySenior Project Manager| Ford Motor Credit CompanyDewitt, Mi, United States
Scream long and loud when you see a train wreck coming!
I was part of a project office for a large project that failed spectaculary. Everyone on site knew that the project was failing. I worked thorough management layer-by-layer all the way to the top (without success). Having done all I could to fix the problems and not received executive support, I left the firm.
The project failed. The client sued (and won). The company nearly went under. The client called me to help put together the recovery project.
Lesson Learned: When you perceive a coming train wreck - reach out and make sure that executive management is informed. If executive management doesn't act - leave the project (you have no obligation to go down with the ship). Saving Changes...
Jiju NairSenior Manager| Fannie MaeReston, Va, United States
Jennifer,
Great topic. In fact, I have first hand experience in efforts to recover projects from a failing or failed status. To your question, I can list a good long list. However, the most important element that comes to mind is business case prioritization. Some of the most unsuccesful projects failed to realize the priority given to business case by stakeholders thereby spending unecessary project resources (time, equipment, people) to implement them. The end result was stakeholder dissatisfaction as other priority business case implementation were left incomplete by the project team.
I will briefly outline a few key aspects that can help PMs to recover failed/failing projects. This was part of an article that I had written on the subject of Project Recovery.
1) Business case priority - As explained above
2) Project Methodology - Agile or Waterfall, it should fit the stakeholder and team's needs
3) Technology Assessment - The right technology fit for the project will work wonders that also should be blessed by enterprise approval bodies
4) Team Effectiveness - Fire or Retain? A PM should make hard choices when he or she is trying to keep a project on the rails.
