Project failure is the subject of this article in the August 2007 edition of PM Network. The article presents some good common-sense points about how to deal with project failure and learn from it. The standard wisdom of finding problems early when they are small, and applying lessons learned are put forth. All of this seems like common sense, but why do I know of many project managers who ignored trouble signals on projects, including myself? And why are lessons learned mostly used as a theoretical construct, and not something referenced regularly in everyday project management?
I have a few thoughts, and some were provided in the article.
Executives that humiliate and punish failure will ultimately breed a culture in which the incentives to rectify project problems early are outweighed by the consequences of admitting potential failure or problems. As the article stated, no project manager goes into a situation with the intent of making a project fail. However, if you look at the incentives at play on an individual project manager, the environment can create a situation where project failure (in the distant future) can be preferable to going through painful confrontation today.
Many project managers I have worked with this in the situation have adopted an attitude of “if they want it that way, we’ll ‘just do it’. Even if it doesn’t work, we did what they told us to do.” Even if on a subconscious level, it seems many people don’t mind failure, as long as they have an adequate reason ready to point the finger. The Nuremberg Defense in response to project failure, however, is both unproductive and a cop-out. A project manager must meet the needs of the stakeholders, but if the constraints do not allow for a successful result (at any point) they must be open and honest about the failure, and use negotiation and political power wisely to either change conditions, or scrap the project. See my post Negotiation in Project Management for some thoughts on what can be done as a project manager to negotiate terms of the project. I would say negotiation is a strength of mine, because for the most part I am very willing to “tell it like it is” and make alternative suggestions to a sponsor and/or stakeholders.
A point I am weak on, however, is utilizing lessons learned effectively. I fall in the trap that I think many project managers do, which is plain, unadulterated negligence. Lessons learned a thrown around in conversation sometimes, and perhaps even warrant a few hours at the end of the project plan. They may be written down, but are rarely used, especially not across multiple project managers. I have a personal log of lessons learned, but I’m ashamed to say it is out of date, and I have not made it a habit to review it when working my projects. Perhaps this ‘coming out’ will encourage me to develop the discipline to do so.
As a New Year’s resolution to myself, in 2008 I will document lessons learned regularly once a month, and review previous lessons learned at the same time. This process should help me out personally, and if it works well, perhaps I can suggest it to other project managers for implementation on a larger scale. Imagine all the project managers in a division getting together once a month for an hour, starting out with a review of a lessons learned database, and then adding to it via group discussion and sharing experiences. Now that actually sounds like a useful meeting!
As a final critique of the article, I was disappointed that instead of mentioning methods of analysis for failed projects and deriving lessons learned, they simply stated things like “..get to the root cause of the failure,” etc. While that is a good goal, I would have liked to see a little more detail like using an Ishikawa diagram,Toyota’s 5 Whys, or a Fault Tree Analysis. All of these can be applied to project failure.
Throw me a bone, leave a comment!
Best of PM Network 2007 – Index
About the author
Josh Nankivel is a Project Planning & Controls Control Account Manager and contractor for the ground system of the Landsat Data Continuity Mission, a joint project between the USGS and NASA. His academic background includes a BS in Project Management, summa cum laude. He can be found writing and contributing in many places within the project management community, and his primary project management website is located at pmstudent.com.
