There is an ongoing discussion taking place in the PM Community Group on LinkedIn around the following statement:

In a failed project there is no one else to blame but the PM.! ! I

As of few days ago the discussion attracted 216 comments and a thorough review of the comments identifies some interesting observations:

  1. The majority of the commentators made a categorical observation – they either accept or reject the premise of the statement; and
  2. There seems to be an even split between the yea’s and the nay’s

The discussion itself makes for a fascinating read, especially now that it has a substantial body of opinion.

Some of the key comments made by proponents of the statement include:

A failed project is a project where the PM gave up and rode instead of rowed

I do feel PM stays accountable for the outcome of the project no matter what it is! Worst case obviously is when the project fails and irrespective of the reasons for failure, at the end of the day, it’s the  PM who is held accountable for it

I believe that when the dust settles, the PM is to blame regardless of the incompetents above, alongside, and below

…Failure is not an option. It’s up to the PM to plan, and thru planning identify combinations of scope, budget, resources, etc.

…In the event of a failed project be quick to step up and own that failure after all you are paid to see it coming…

…So the bottom line is even though the project failure is collective responsibility of the team, if it needs to label primitively to someone, then first name in the list will be the Project Manager – The Team Captain

Exactly, PM is like Coach, once game failed, the Coach has to go

Yes, and that is why they pay us the big bucks. The “buck” stops  with the project manager

I cannot agree more. The PM lives or dies by his own sword.

If you can’t assume accountability for a given project, don’t bother being a project manager…A project usually fails for a variety of reasons..but regardless what the root-causes may be, the one accountable and responsible for a project outcome is still the PM

Hence, it is a collective effort of people or departments that results  in a project failure or success, among which PM bears the maximum share

Fantastic stuff, right? Let’s see what the opponents had to offer in response:

I’m not sure if the PM is to blame here. If you’ve seen where the problems are, developed a plan to correct them and put the project back on progress, but your management won’t approve, is the PM to blame here?

You can take the blame if you wish, but often the only thing you should be blamed for is taking on the project in the first place

The mantra I use is  that if a project fails, it’s EVERYONE’s fault – from the PM, to the project team, to the customer, to the stakeholders. Each one of them did not do enough to ensure the other one succeeded.

The PM is  often caught in a conflict of RESPONSIBILITY and AUTHORITY. When the PM is responsible for things over which he or she has no authority, then there is the possibility for exposure to blame for negative events for which they were not at fault

…the blame game is not productive. In a blame culture people hide information and we lose the opportunity to learn from experience. We should look at a failed project to understand why it failed rather than to attach blame.

 …a majority of projects do not occur in the ideal “the PM is in charge” scenario…90% of projects occur within a weak matrix, multi project environment…by creating the myth that the PM is always responsible for the project can create some very distorted behaviors amongst the 90% of PMs who have less authority than “ideal”.

Get real my friend, most PM’s just get given a project and have no option of declining it. Further the major decisions are given by the Project Boards and stakeholders.

…do not confuse accountable with guilty (blame). PM is accountable for failure of the project before senior management, but the team as a group is to blame, because if no solution is provided, all of them as part of the problem.

There is rarely a time when the failure of a project is the PM. Why? Because the organizations are usually to blame because their performance, oversight, expectation and process bars are so low.

And this is where I stand:

I have an issue with the whole notion of ‘blame’. My understanding of failures is that they represent a process breakdown, that while could be traced to a single person, its ultimate results are a consequence of breakdown along a governance chain. To suggest that a single person is to be ‘blamed’ for a failure is more an indication of our immature view of complex webs of communications or our innate biblical desire to see someone punished for a supposed sin. Either way, I don’t see anyway where this approach can be taken seriously.

One of the disappointing (or rather alarming) aspects of this discussion is that too few commentators took the trouble to qualify their response with the overriding ‘it depends…’.

Superman and James Bond are fictional characters and in the real world many project managers operate in complex, matrix environments where their sphere of influence is limited The categorical declaration made by some in this thread, according to which it is always the PM’s fault and therefore it is always him/her to blame is so simplistic and unrepresentative so as to make them utterly questionable.

Another claim, whereby if you face a situation where you know you’re gonna fail, you refrain from taking on the management of this project is also, for many of us, out of this world. Not all PM’s have this luxury of selecting their own projects or setting standards for which projects they will take on and which ones they don’t.

Time to set our feet firmly on the ground guys.

Think about it!

Print Friendly


  1. I’m perplexed by many of the comments; very black and white, not much nuance.

    I see a difference between responsibility and accountability. The PM may be responsible but every team member is accountable for his part in the success or failure of a project.

    I’d also caution the high and mighty about being too cocky. If you play the PM Role long enough, you may have a project fail badly. You’re still responsible but you better identify what went wrong and get all people at fault, if any, to understand their part in the failure, and put measures in place or the failure may repeat itself.

    Finally, don’t blame, fix.


    • Pat, I couldn’t agree more. There is a fair chance that many of the commentators think ‘accountable’ when they use the term ‘blame’. These two terms, clearly, are different. I also suspect that the overwhelming sense of confidence exhibited by some is a reflection of the impression (or perception) that PM’s need to be assertive and self-assured. So there you go.


      • Glen B. Alleman

        Shim and Pat,

        I think you’ve hit on an important point. Many don’t separate accountability from responsibility. There are few examples of truly successful projects. So Pat, you’re right about being too high and mighty.
        In the end the PM may or many not have the authority to correct the malfunction of the “customer.” Certainty in our domain, there are too many constituents to “mess up the pie,” for a single person to manage.


        • Glen, funny enough, one of my posts, titled ‘accountability vs. responsibility in project management’ is the most read post. I was always wondering about that.


  2. Glen B. Alleman

    My take comes from defense, space, and ERP where there are enough failures to cover the planet. The RAND ( and IDA ( Root Cause Analysis of Nunn McCurdy breach (>25% over target baseline for ACAT1’s which are greater than $5B, yes Billion) shows that the PM is low on the list as the root cause. Number 1 and 2 are funding inconsistencies and changing requirements which come essentially from congress and the Joint Chiefs. In ERP my personal experience is instability of funding and changing requirements for senior management.

    Rarely in ERP are changing business conditions the root cause, since mature business environments are the norm. It’s an urban legend. Now Number 1 in ERP and general enterprise class systems is the failure to define what “done” looks like in any meaningful units of measure, so the project is doomed before it starts. This “may” be the PM’s issues, but rarely can the PM in enterprise IT “demand” senior management do it her way.

    I’d suggest that the question is much too simple (no offense to the OP), and requires – as always – a domain, context, technical environment (maturity), political environment (must government problems are political according to RAND and IDA). Disclosure I work as a contractor for IDA.

    So there are plenty of assessment in a variety of domains – construction, public works, defense, space, enterprise IT of the root causes. But the PM is just a “manager” of the work. Not the stakeholder, not the “owner,” (if so in construction the project size is small and no one cares), and most importantly not the primary influencer of the mission and vision of the project. That’s where – in my experience – projects go off the rails. They don’t know, “why” they are there – no defined capabilities. And when they do, they don’t know what “done” looks like in terms of delivered capabilities.

    US DoD has Capabilities Based Planning, but many programs toss those needed capabilities out the door when “ups and adds.” Here’s a counter example of ruthless control by the PM and stockholders of a moderate (for our world) program that was a success The processes, people, and tools can be replicated for other programs, even outside the domain. So it can be done. I was not on this program, but one of the authors was. Page 9 is the common failure mode of a large number of ACAT1’s. If you see these on your project, you’ll probably end up in the same place – over budget, behind schedule, and your “toy” won’t work.


    • Hi Glen, thanks for the details response. I particularly value the suggestion that each response need to relate to such variables as domain, context, technical environment (maturity) and political environment. Blank statements without providing such background are too generic to be of any analytical value.


  3. Shim,
    I find this debate to be somewhat of a “red herring”. Like many of the LI discussions it is overly simplistic. (As Glen noted above)

    First, there is a difference between the contractors and owners perspective. As a contractor, I can only be held accountable for that which is contained in the contract documents. Meaning unless the project is a design-build (or EPCC) I cannot be held accountable for the performance of whatever it was the project was undertaken to create or do. Traditionally, contractors, specifically those working under firm fixed price contracts, are only responsible for time, cost, quality, safety and environmental considerations and even then, under contract law, are only held accountable for that which they can reasonable control. (See force majeure or impossibility of performance/frustration of purpose clauses)

    And more importantly, contractors, by way of the contract documents, are legally empowered to make decisions on these issues and are likewise held legally and financially accountable should they fail to fulfill what the contracts require. (The “contractor shall” clauses)

    Then we have owner organizations. In MANY owner organizations the project manager is NOT empowered to make decisions and in fact, many of the decisions re cost, time, resources and strategic objectives were made long before the project manager was even appointed. (See Merrow’s “Industrial Megaprojects” for more on that) What we find in many owner organizations is that the formal authority provided to their project manager is often NOT commensurate with the responsibility and without authority, there can be no accountability. This is especially true if the owner is trying to hold his/her project manager accountable for not only the performance of the PROJECT but also for the “success” of the PRODUCT the project created. A growing body of research (GAPPS, Turner, Isenbeck & Frieman ) is putting more responsibility on the backs of the project SPONSOR for at least in an owner organization, it is the project SPONSOR and not the project manager who makes the decisions regarding time, cost, resources and strategic objective of the project. Which is why we are seeing a push by organizations such as the US American Institute of Architects (AIA) to be pushing for more “up front planning” or “front end loading” with their Integrated Project Delivery (IPD) approach. This same philosophy is being espoused by Ed Merrow et al in his “Megaprojects” book. The basic premise underlying both books is that the entity which assumes responsibility to own and manage risks are those who are best positioned to manage or control those risks and if there are risks which neither party has control over, then those risks are shared.

    Bottom line on all this, one of the fundamental tenets of management in general is that in order to have accountability there must be authority commensurate with the responsibility. (see Henry Fayol and Kelly Johnson, of Skunkworks fame for specifics on this.

    BTW, as Mathew Weaver has black-listed me from this specific forum because of the discussion and ensuing debate over my posting about PMI having bought HSI, feel free to quote me if you so desire.

    Dr. PDG, Jakarta, Indonesia


    • Hi Paul and thanks for your detailed and informative response. It strengthen the arguments raised previously and adds another dimension, not previously raised, about the apparent distinction between project managers operating as Contractors and those operating in Owner Organizations. My own experience has always been in Owner Organizations where, as you correctly suggest, some of the fundamental aspects of the projects I was brought in to manage have already dictated and settled before I came in, limiting substantially my ability to influence key governance decisions.

      Thanks again, Shim.


  4. Glen B. Alleman

    One possible collection of software domains


  5. Pingback: New PM Articles for the Week of October 21 – 27 | The Practicing IT Project ManagerThe Practicing IT Project Manager

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: