A high-performing project managers worst nightmare is usually the failure of his or her project. No one wants to be associated with a failed effort, especially with high visibility, high cost projects. I have seen my fair share of failed projects, and like animals fleeing a sinking ship, months before the project is actually declared a failure people begin to disassociate from the project. Once highly-engaged project sponsors are nowhere to be found, and everyone from junior analysts to executive sponsors flee for another initiative while the PM is forced to watch in horror.
While failure is never pleasant, fleeing the scene and effectively closing down the project the moment its cancelled does your company a further disservice. A failed project may not have accomplished its stated objectives, but usually these projects have produced some meaningful output. Even the failure itself, when properly analyzed, can result in improvements to future projects.
The project manager usually doesnt have the luxury of abandoning ship before the project is officially terminated, so it becomes imperative to try and capture any value that has been produced as others flee. Acknowledge this behavior and ask your team for one last bit of help to gather, package, and archive whatever valuable materials theyve produced. As part of this process, capture feedback on what various parties perceive as having driven the project to failure. Was it a technology that didnt deliver on its promise? A lack of competent staff assigned to the project? Perhaps the project was accomplishing its objectives, but an external factor like economic conditions or a merger changed the need for the project. Getting a rough idea of the perceived circumstances that led to the projects demise can aid you in planning a formal post mortem or after action review of the project, and must be done sooner rather than later since youll likely have limited participation in that process.
Most of the worlds militaries conduct a formal after action review (AAR) process after every mission, whether it was a smashing success or failure costing lives. This process is just as useful in a project environment, and should strive for the following goals:
- Capture observable behaviors that hindered the project and avoid vindictive speculation. An observable behavior would be that a technology vendor did not meet a specified deadline and is a helpful and verifiable data point. Saying that the software stunk is not.
- Document external factors that influenced the outcome. Did the economy or market change? Did the companys strategic priorities change?
- Explain any resource shortages that contributed to the failure. Were you missing key people, or were critical elements of the budget reduced or made unavailable?
- Finally, speculate, in a helpful and forward-thinking manner, on what would have been required to make the project a success. If certain skills were not available, document what training would have helped rather than lamenting the weakness of your team.
This document should be something you can hand to another project manager, a program management office, or even yourself before you embark on a future PM role months down the line, and should serve to educate rather than lay blame. Furthermore, the AAR should highlight the most valuable activities the project successfully completed, and suggest ways to leverage those activities. Perhaps there are opportunities for a series of smaller efforts to implement what you designed, or knowledge that can immediately be put into practice separately from the overall project.
While it may be human nature to run from failure, a few extra weeks will ensure that money spent on a failed project does produce some positive outcomes. Whether you provide some valuable education for fellow staff, or identify some useful elements of the scrapped project, abandoning ship too soon merely adds one more wasted opportunity to an already failed effort.