PMO Leadership: Who is to blame when a project fails?

From the PMO Setup T3 - Tips, Tools, and Techniques Blog
by
Bringing you PMO Setup Tips, Tools, and Techniques for PMOs of all shapes and sizes.

About this Blog

RSS

Recent Posts

PowerPoint Presentation Tips

Planning tips from a mouse..!

Fool me once shame on you, fool me twice shame on me..!

Project Manager Knowledge Areas

Who is to blame when a project fails?


Categories: PMO Leadership


Failure (noun) / an act or effort that does not accomplish its intended purpose.
 
PMO Comics, by Mark Perry
 

Who is to blame when a project fails? Should the blame fall entirely upon the project manager? Or, is a failed project the result of others not doing their work, whether that is the users responsible for but not providing clear requirements, the business analysts responsible for analyzing and validating the requirements, or the developers responsible for design and delivery of the solution, or perhaps management redirecting resources and jeopardizing the project.

Surely, the blame can be spread around. But, it is the project manager that is the person that must deliver the project and manage and be responsible for all issues and obstacles that stand in the way of successful project delivery. So, at the end of the day, there is only one person to blame for a failed project, the project manager. Or, is something else really the blame.

According to Deming, “95% of a problem is the process, only 5% the people.” Perhaps not always, but more often than we would like to admit, project organizations have much better people skills and tools, than they do processes.  

Treating project failure as a process defect, and correcting that defect, will likely be more beneficial to the organization and than berating the project manager, not to mention the right spot to place the blame.

 
Posted on: July 02, 2008 02:20 PM | Permalink

Comments (5)

Please login or join to subscribe to this item
I agree that too often project failure falls on the Project Managers shoulders. If the PM is not being blamed, then the organization is likely tring to "fix" the problem by addressing PM methodology and associated PM processes. In fact, most project failures are due to poor IT Governance and the resulting poor project and portofolio management. I agree with the notion of looking at the process and not just the people. Just make sure you are looking at the right processes, and in most cases, the missing processes.


Steve Romero, IT Governance Evangelist
http://community.ca.com/blogs/theitgovernanceevangelist/


Mark:
Here is an interesting view of a report refuting Standish Reports of IT Project Failure metrics by Michael Krigsman. Project Managers seem to be the likely suspect of project failure but I beg to differ. Project Managers are an easy target for the organization to pinpoint the blame by sponsors, executives and goverance boards. Organizations needs to stop relying on heros to pick up the pieces for abandoned and projects that are overcommitted. This needs to change and if anyone is paying attention, PMs are adding value around the world; organizations need to work smarter, stay to the course of a realistic vision, focus on training their employees to step up to current and future challenges to stay competitive and have open communication from top to bottom, across the organization and from the bottom up to the top.

http://blogs.zdnet.com/projectfailures/?p=513

Excerpt from article:
The authors offer these managerial insights:

Our results indicate that while approximately 9% of IT projects are abandoned, another 7% consistently overdeliver on original project targets.

What our results suggest is that IT project managers cannot accept all of the responsibility of delivering projects successfully. Top management and steering committees have a significant role to play in managing project risk. Ambitious-sized projects, moving targets, and managerial turnover present challenges for IT projects that stretch even experienced project managers and result in greater variances. Effective oversight of projects can help project managers respond to these challenges.



Naomi, I agree with you and beg to differ as well with all of those that are too quick to point the blame at the project manager. Thanks for the post and insights.

The blame will always fall on the project manager. Oh, the joys of responsibility without authority.

Coincidentially I am preparing a revision of the project metrics in the PMO where I work. I have slimmed down the metrics to seven, five based on EVA and two quality metrics. Given the organizational structure here, none of those metrics are directly under the control of the project manager. I have tried to position the metrics as measures of the project and not of the PM, but we will have to wait to see how that works.

It depends on the nature of the failure. The PM is the first in-line. The PM is the figure-hea. However if the fault lies elsewhere then that needs to be addressed and respected.

The PMs role is one of getting things done. If the team don''t know what to do then the PM must accept blame - for not communicating and ensuring that the understanding of the requirements (technical, schedule, budget) were understood. Similarly if the team aren''t doing what they should, then the PM should know, communciate and get the fault corrected. If the Senior Management make decisions affecting the business case then the PM needs to communicate the impact back to them.The PM is then a messenger and we all know what happens to messengers with bad news.


Metrics will help the PM spot problems arising, once the problems are spotted they need to be advertised and then they can be corrected. Failure to spot, communicate or cause a corrective action response must rest with the PM. Failure in other areas must rest with their owners. The PM is not alone on the project and every empowered team-member and stakeholder has a share of the responsibilty for achieving success, and must therefore share some of the responsibility for not achieving success.


I believe the important thing is to learn for the experience. So after any project successful or otherwise, hold that post-project review and learn what went right, wrong and indifferently.



Please Login/Register to leave a comment.

ADVERTISEMENTS

"How can you govern a country which has 246 varieties of cheese?"

- Charles DeGaulle

ADVERTISEMENT

Sponsors