Project Management

The Sure-Fail PMO Implementation Approach

From the Game Theory in Management Blog
by
Modelling Business Decisions and their Consequences

About this Blog

RSS

Recent Posts

The Gig Economy Comes For The PM Roller Coaster

Why Project Management Is The Only REAL Management

Disruptive Data … Or Disruptive People?

The Relevancy Conundrum

Disruptive Data, Or Time To Pound The Table?



According to 4pm.com, organizations can see a project failure rate as high as approximately 70%.[i] Bad as that is, according to a research paper by McKinsey and Company and the BT Centre for Major Programme Management at the University of Oxford, 17 percent of IT projects fail so badly that they threaten the existence of their companies.[ii] With rates like these, it’s small wonder that project-oriented organizations make it a point to set up Project Management Offices, or PMOs, in order to instill in their project teams the techniques that maximize the odds of their projects coming in on-time, on-budget. So, how ironic is it that the effort to set up and maintain the PMO is, itself, so likely to fail?

I don’t have any hard data on that last assertion, because I’m fairly certain it would be next to impossible to collect. PMO failures do not usually manifest the same way that individual projects do. Individual projects succeed (or, as the data suggests, crash and burn) when their actual performance is compared to their original success criterion of scope, cost, and schedule. PMOs fail much more subtly, and I think it’s important to Game Theory In Management Nation to be able to quickly recognize those signs.

The symptoms of a soon-to-be-failing PMO are easiest to read if you happen to be in the organization when the PMO is initially set up, but they are still observable if you happen across it in the middle of its story arc. There’s this widely accepted implementation approach, or template if you will, that is often employed by start-up PMOs which dramatically reduces its chances of success. This strategy involves employing the following tactics, usually but not necessarily in this order:

  • Executives make the announcement that a Program/Project Management Office is being funded, usually because they’ve just been stung by one of those massive project failures that threatens the very existence of the organization.
  • Then comes the announcement that the PMO will be headed by a person assumed to be in high standing, either within the organization itself or from the outside PM community. Typically, however, the remaining members of the new PMO will be from other teams performing administrative functions.
  • There will be an attempt at clarifying the scope of the new PMO, usually with some reference to one of the maturity models out there, the most famous being Carnegie Melon University's Software Engineering Institute's Capability Maturity Model®. This reference will be wildly speculative, both about the organization’s current Level®, as well as the one to be attained “within 18 months.”
  • Other organizations, recognizing the groundswell of support for “doing PM right,” will vocally support the initiative, promising the head of the PMO the “support” needed to attain the stated goal. Personnel will be encouraged to get their PMPs®.
  • The PMO will get to work on three specific tasks:
    • Identifying the software platforms for handling schedules and cost performance reporting,
    • Arranging to train the recently-transferred staff, and
    • Writing procedures.

It’s that last bullet which proves to be the most poisonous, as we shall see.

  • The tools get selected and installed, and the staff goes through the training, but the procedure-writing will begin to get bogged down. If the original versions of the documents detail minimum standards for all of the organization’s projects, then the existing PMs who disagree with the content of the documents will find ways to argue that these procedures ought not apply to them. And they will succeed, regardless of the level of “support” promised by their superiors only weeks previously.
  • The procedures are finally finished, and very senior executives within the organization sign off on them, implying dire consequences for non-compliance.
  • Some projects make sincere efforts at implementing the procedures, most make half-hearted attempts, some pretend, and others ignore.
  • Once it is realized that the pretenders and ignorers don’t face consequences, the half-hearted teams stop their efforts, and the organization quickly returns to its previous project failure rate.
  • The PMO has now failed, but it has done so quietly. The head of it will be replaced, and this person will go out raging about the lack of genuine support from upper management.

I’ve seen this pattern repeat so many times I could probably recite the steps in my sleep. Naturally, I believe I have a far superior approach to PMO set-up and maintenance, predicated on some rather basic Game Theory, and its key components are…

Look at that! I’m out of pixel ink for this week. Besides, GTIM Nation is probably contemplating which aspects of the failed model are intrinsic to their home organizations, and probably isn’t in the mood for the right answer right now.


[i] Retrieved from https://4pm.com/2015/09/27/project-failure/ on November 3, 2018, 19:40 MDT.

[ii] Retrieved from https://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value on November 3, 2018, at 19:44 MDT.

Posted on: November 05, 2018 10:59 PM | Permalink

Comments (8)

Please login or join to subscribe to this item
re this: "70% Most Organizations Have a 70% Project Failure Rate "

I don't buy that at all. I did a quick scan of the article and don't see any empirical evidence to support that statement

Michael, I have seen this too happen, thanks for writing it down.

Standardizing PM procedures seems to lead to more perceived buerocracy, resistance and in the end (after 2-3 years) PMO closure. Is it even a primary cure for easing the sting pain of that executive who chartered the PMO in the first place?

It comes down to measure the benefits of a PMO:
- standardized project management - who cares, its a means, not an end
- reducing the time executives spend on troubleshooting - might be better
- creating transparency to reduce uncertainty for executives - even better

A good prescription for PMO failure.

Very interesting, thanks for sharing

It sounds like “why even bother.. “ :)

My personal experience is not as bad as desribed.
The pressure point is the sustainable (!) interest of the PMO report recipients and their hierarchical power. Hence the durability of the PMO is linked to the support of managerial power, which see a value in the PMO activities and do not allow to process or not process certain things without involvment of the PMO.

If any problem ever really occurs, its usually the lack of buy-in or urgency. Consider how fast a football team fires their coach after a singular poor season as an analogy.

Please Login/Register to leave a comment.

ADVERTISEMENTS

No matter how much cats fight, there always seem to be plenty of kittens.

- Abraham Lincoln

ADVERTISEMENT

Sponsors