Who is to blame when a project fails?
From the PMO Setup T3 - Tips, Tools, and Techniques Blog
by Mark Price Perry
| Blame (noun) / to assign responsibility for a fault or wrong. |
| |
 |
| |
| Who is to blame when a project fails? |
| |
When a project fails, who is to blame? 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: August 27, 2012 01:23 PM |
Permalink
Comments (12)
Please login or join to subscribe to this item
Ian Whittingham
Managing Director| Calixo Consulting
Golden Cross, East Sussex, United Kingdom
Thanks for raising this question, Mark. The blame game is an easy 'out' if you are not really committed to identifying and fixing the root causes which may be the source of project failures.
Another consideration is organizational competency, both at the project level, and at the macro level of the organizational environment in which the project is performed. You also need to account for the extent to which an organization not only has the resources and skills to perform projects but the way in which the behaviours of the performing organization help or hinder the successful execution of a project. And I don't necessarily mean in the sense of the organization's project management maturity, although that can be a factor in project failures. What I am thinking of specifically is the role that organizational bias, the unacknowledged habits of mind an institution encourages, may play in contributing to project failures, something I wrote about back in 2009 http://www.gantthead.com/content/articles/247058.cfm
Wai Mun Koo
PMO Director| Intergraph PP&M
Singapore, Singapore
'Blame' is a negative word. People get freaked out when they hear it. 'Accountable' is a better word for it. If we ask "Who is accountable?" instead of "Who to blame?" then obviously this is more soothing for the ears. If a project fail, the PM is accountable, but the root causes can be anything. Yet, being accountable does not mean that everyone is to point finger at the poor chap. We have to understand that sometimes, things happened beyond the capability and authority of the PM to handle (e.g. natural disaster). However, this does not mean that the PM is not accountable. We should clearly differentiate between accountability and root causes of failures.
Mark Price Perry
Business Driven PMO Evangelist| BOT International
Orlando, Fl, United States
Ian, so enjoyed your article "Hubris and Happenstance: Why Projects Fail (Part 2)"... http://www.gantthead.com/content/articles/247058.cfm
Like you mentioned, it can be (and so often is) an easy out to quickly place blame, though we all know (or should know) better..!
Mark Price Perry
Business Driven PMO Evangelist| BOT International
Orlando, Fl, United States
Wai Mun, great point, I so agree. The difference between finger pointing and continuous improvement is small in terms of attitude changes required, yet tremendous in terms of benefit to an organization. Thanks...
The blame game is one that always seems to rest on the Project Manager, and maybe it should. They are the ones that are the "steward" of a project, "coordinator" of efforts and people, communicator, team motivator, keeper of the "task" lists. The expectation is there that the Project Manager should know better, and be more "efficient' at reading the signs when a project is failing. But I also agree with Ian, organizational competency or even maturity is a killer to a project. I believe the Project Manager should take the temperature of the stakeholders that he/she is dealing with, stakeholder management here is key to the success of your project. You need to have their skin in the game to support you as you progress through the project. The PM maybe the one that walks around with the target on them, but it's the entire organizational that fails when a project fails.
Drew Craig
Sr. Agile & Product Coach| Vanguard
Philadelphia, Pa, United States
Great Mark, very true indeed. Accountability lies with the PM, but there are others in the game - people, process, etc., which are factors to consider when performing a post-mortem/retrospective. The question is then, what's next?
Vincent Guerard
Coach - Trainer - Speaker - Advisor| Freelance
Mont-Royal, Quebec, Canada
You are right the PM is the easy target, like the messenger.
You need to dig deeper, process and the organisation are likely part of the failure.
Agreed... PM is accountable.
But should also pay attention to process, people or any other important factors...
Prashant Sonwane
Sr. Program Manager| Winjit Technologies Pvt Ltd
Nashik, Maharashtra, India
Root cause Analysis (RCA) should be done after failure or success of the project.
Failure projects would give us some learnings and Successful projects would give us improvements.
Matthew Morey
Project Turn Around and Recovery Expert| C4 Explosive Leadership Training LLC
Old Hickory, Tn, United States
One of the lessons I've learned over the years is "Fix the Problem, Not the Blame." In fact, I had an experience that could have been career-threatening, which I shared here:
http://www.c4-elt.com/2013/04/fix-problem-not-blame.html
People were too quick to assign the blame rather than fix the problem because they were worried about their own position.
Over the years, I've learned to shoulder the responsibility but look for ways to grow and avoid the situation again in the future. Often someone has to absorb the blame, if for no other reason than letting the team/sponsor/stakeholders etc. relieve stress/vent, then you can move forward and address the issues as defects like you mentioned in the article. Thanks for sharing!
Joey Perugino
Agile Project Management Consultant| Perugino - Project Management
Montreal, Quebec, Canada
I agree with you Mark that it's easy to blame the PM but that it doesn't solve the root cause of why project's fail to be delivered successfully.
Introspection is not something that I have found many organizations very willing to do.
It's a painful process and requires having the strength to take some actions that would in most scenarios not be very easy to do without ruffling feathers.
Blaming the PM is sometimes taking the easy way out.
Please Login/Register to leave a comment.
|
"There's a Mr. Bartlett to see you, sir."
- Graham Chapman, Monty Python's Flying Circus
|
