The Problematic PMO

Perhaps the greatest comedy bit is Bud Abbott and Lou Costello’s “Who’s on First”. You can see a clip of it here on YouTube. You can also see it at the Baseball Hall of Fame.

Bud Abbott’s character, the manager for the St. Louis Wolves baseball team, knows all the players. He knows Who plays first base, What second, and Idontknow is on third. But things quickly go into a tailspin when he tries to explain the team composition to an incredulous Lou Costello.

What does this Abbott and Costello routine have to do with project management? Taken a different way, it gives us some insight about what happens on a project when the team members don’t know who is responsible for doing what. When this kind of confusion happens, it’s almost always caused by poorly defined project roles. If the confusion has been going on for some time, then it’s indicative of a defective or nonexistent project management methodology. If there’s a PMO involved, then chances are the PMO is also defective.

In baseball, “defensive indifference ” happens when a player steals a base with no reaction from the opposing team. Similarly, you could say that a project allowed to achieve and maintain a dysfunctional state is enabled by management indifference. That may seem like a harsh characterization, but the only real reason a project in chronic trouble is allowed to go on is a culture that discourages dissent and manages conflict by avoiding it.

NASA had similar cultural issues that directly contributed to the Apollo 1 fire and the loss of the space shuttles Challenger and Columbia. Fortunately, most failed IT projects don’t end up killing people, but they do consume careers, money, and credibility.

A Symptom of Something Bigger

Like a baseball team, a well-oiled system acquisition project team consists of a group of motivated individuals working together to complete the project on time and budget and deliver a IT system meeting the scope and quality goals specified (or referenced) in the project charter.

You won’t find the definitions of all of the project roles in a properly written project charter. Instead, the charter should only name the individuals assigned to the project as the project manager and the project sponsor. The project charter should not describe the project manager and project sponsor responsibilities on the project. Those “job descriptions” should be invariant across projects and detailed in the project management methodology documentation – usually maintained by a Project Management Office (PMO).

If your organization has a mature project management methodology, then the roles of the project manager and project sponsor are defined by your methodology and not in the project charter.


Regarding Agile, there’s no reason not to use charters for Agile software development. To effectively survive in the business environment, an Agile effort benefits from an executive champion – a “sponsor” – just as much as a “traditional project”. Other roles named in the charter depend upon the Agile framework used (determined before starting the project). For example, a project using SCRUM would name the sponsor, SCRUM master, and the Product Owner in its charter.

Where to Define Project Roles

As I mentioned above, project roles should be defined in the project management methodology documentation and referenced in the project planning documents. You shouldn’t have to start from scratch and write new project role definitions for each project (or Agile effort). Just use the roles described in your project management methodology (which would include approved Agile frameworks). If you run into something brand new needing a unique role, then by all means update your methodology documentation. Keeping documentation up to date helps future project managers and project teams plan their projects.

I know the “Agilistas” reading this article are cringing at the thought of documentation, but you do need some regardless if the project is classic “PM” or hardcore Agile. One document that every project – Agile or not – should have is a RACI matrix. (This article from CIO magazine describes what a RACI matrix is and how to create one.) The only change I would make to the RACI is to link each role to an individual. If Bud Abbott had a RACI matrix for his baseball team and gave it to Lou Costello, we might have missed out on their all-time great comedic hit.

Example RACI Matrix from Referenced CIO Article

Project Mangers Reenforce Project Roles

Perhaps the most important project manager (or similar role for Agile) responsibility is to enforce the roles members have on the project team. Individuals are (supposed to be) assigned certain responsibilities on a project because they have the right mix of knowledge, skill and ability to successfully complete their assigned tasks on the project. Projects get into trouble when team members decide to switch or take over other roles and the project manager lets them do it.

Illustrating how important it is for the project manager to reenforce project roles, consider this project that had four project managers in one year (this is an extreme example, but it really happened). Because of the time it took to bring each project manager up to speed, the product owner subsumed the project manager, business analyst, and application architect roles.

Despite having no professional experience or certification in these three specialties, the product owner was allowed to continue in all those roles and complete the project a year late and at ten times the original estimate. The requirements documentation generated by this one-person project was so poorly written that contractor business analysts had to come in and work overtime to completely rewrite it for developer use.

Perhaps more importantly, the agency policy that specified experienced and certified project managers on efforts like this example project was completely undermined. The PMO and management let it happen. While this project did deliver a system, the technical decisions it forced on downstream projects added significantly to their cost.

The Value of Project Reviews

The project management methodology should require that every project longer than six months have built-in project reviews (including project management documentation) for the duration of the project. The purpose of these reviews is not to rewrite the documentation, but to assess if the documentation is up to date (e.g., the RACI matrix described above) and relevant.

By relevant, I mean that the documentation is assessed to verify that it is continuing to serve a purpose as a communications tool to the project team, the stakeholders, and the project file. Any documentation that doesn’t pass this “smell test” should be jettisoned because it’s adding drag to the project. You could say that’s being Agile (and I’ll accept the complement), but it’s really just being practical.

Project reviews are invaluable because they get more “eyes” on the project. Projects that operate in isolation (like the extreme example I described above) have a tendency to succumb to groupthink and can go off the rails before anyone knows it. Reviews can help battle groupthink and ensure that projects stay on course.

The Problematic PMO

The purpose of a Project Management Offices (PMO)is to improve the chances of project success by mitigating project risk. One of the most effective ways of reducing project risk is for the PMO to adopt and socialize processes for managing projects. You can call this a project management methodology, a framework, standards, guidelines – whatever. But the idea is to have a consistent, predictable, repeatable way to initiate, plan, manage, and monitor projects.

In my article The Zombie Project, I described how ineffective project sponsorship can encourage a project to become a never-ending, resource consuming burden that never delivers. Effective PMOs are zombie project killers. I should rephrase that – with an effective PMO, projects never become zombies because corrective action is taken before the project goes into zombie mode.

How could a project managed by a PMO become a zombie project? Probably because the PMO’s project management methodology (if there is one) is lacking. As the issue was allowed to happen and then not dealt with, it also reveals a culture where questioning the PMO is not acceptable behavior. If the PMO has the backing of a powerful executive, it could reinforce the notion that the PMO cannot be questioned.

Addressing issues with the PMO is harder if it’s advertised and recognized by executives as a center of excellence for project management. Lets say there are individuals with extensive IT project experience in the organization – but not housed in the PMO. They don’t work in the “center of excellence” so they don’t have the referential authority of the PMO and its executive sponsor (the “clout”) to push a zombie project back on track.

All of this combines to make it that much harder for management to act on a zombie project. It also makes it easier for the PMO to deflect attention to some other party involved in the project, such as a contractor (a favorite target because they can’t fight back) or some other internal IT group.

It’s tough to recognize a problem project if the experts charged with preventing problem projects are the cause of them.


Evaluating the PMO

Having a defective PMO doesn’t mean that every project it touches becomes a zombie or is doomed to failure. A defective PMO can be quite successful delivering on smaller, uncomplicated projects. For example, there may be certain types of projects that have a “built-in” methodology or guideposts that orient the project team in the absence of a defined project management methodology. Some other characteristics of projects that don’t require “heavyweight” process that a defective PMO can pull-off (provided the team members are diligent and have the appropriate level of skill) include projects:

  • With simple and easy to define project scope and/or functional requirements (or user stories).
  • Homogeneous (or nearly so) stakeholders having few differences in their understanding of the project and the system the project will deliver.
  • Developing systems that are not based on complex technologies and are of short duration.
  • Where the tools used to develop the solution have built-in development processes.

A PMO may have a long rack record of success when dealing with these kinds of projects, but still lack the process maturity needed for tackling more complex projects. This could engender a false confidence in the defective PMO that it is truly capable of successfully managing complex and challenging projects. Here are a few indicators that your PMO might not deserve the confidence placed in it:

Lack of a documented project management methodology – Ask the PMO for a copy of its project management methodology. When I worked as an in-house project management consultant for the Federal Reserve Board’s Banking Supervision PMO, we had a project manager’s handbook (we called it the “PMH”) that served as a guide for planning, managing, monitoring, and reporting the status of IT projects. If the PMO in question can’t produce this kind of documentation, there probably is no methodology.

Methodology effectiveness – If the PMO produces its methodology documentation, have a project management methodology expert review and assess it along with the other materials listed above. Just because a PMO has a documented methodology doesn’t mean it’s a good one – and it will take an expert (not a lay person) to make that determination. For example, I knew of one PMO that bought an off the shelf project life cycle methodology and developed a library of nearly 100 project management document templates. On paper, the methodology looked pretty good. In practice, it was not much more than a documentation and ticket-punching exercise. Bad projects still got approved and many projects came in late and over budget.

Quality of lessons learned documentation – Lessons learned from completed projects are one of the principal inputs for project management methodology improvements. Without them, it’s hard to make the methodology better. Ask for copies of earlier lessons learned documentation. Review the lessons learned documentation and look for recommendations for improving existing project processes. If there are no recommendations, either the existing methodology is perfect or doesn’t exist.

Project charters – I discussed this earlier in reference to project roles, but there are other areas of concern to watch out for with project charters. For example, any project charter that is longer than one page – front and back – should be immediately suspect. It shouldn’t take more than double-sided sheet of paper to charter a project. I recall a project charter that was in excess of 15 pages. The charter identified the entire management chains of the sponsoring organization and the PMO as project sponsors. The bulk of the charter consisted of a history of the program the project would support and project/program management and risk management plans. Both plans should have been stand-alone documents and not included in the project charter. And it was written by a PMO.

Conflating Projects and Programs – Projects are not programs and vice versa. There’s a different skillset involved in managing an IT program than managing an IT project. If the PMO mixes the two together, there’s a good chance that it doesn’t understand the difference.

Walking the talk – Does the PMO require that all project managers have professional certifications? If so, does the PMO staff have those certifications as well? Or is it more of a “do as I say but don’t do as I do” situation?

All tool and no process – Another subtle indicator that something is amiss is if the PMO makes a large investment in a project management information system that nobody but the PMO uses. Chances are that the PMO is trying to create a methodology around a tool. This is backwards and never works – you need a methodology first, and then find and use tools that fit the methodology.

There are other, more subtle indicators showing that the PMO might not be up to snuff that only experienced project managers might notice. For example, I remember getting into a discussion about the difference between an issue and a risk. This is basic, esoteric project management knowledge, but a PMO consultant arguing that the two are the same is a clue that something is a bit off.

Fixing the Situation

Notice that I didn’t say, “fix the PMO” in the heading. Because the organization’s culture is enabling the malfunctioning PMO, it’s going to take someone high up on the executive chain to take charge of the situation. The first thing this lucky executive will have to do is acknowledge that there is a problem.

Failing to acknowledge the problem only postpones the inevitable. A zombie project will, eventually, face an existential threat. Usually, it’s in the form of auditor (for the US federal government, the Inspector General or the Government Accountability Office). There’s nothing worse than an audit determination describing how the organization knew there were problems with a project but did nothing about them.

Before you can fix the situation, you have to evaluate the PMO and the first step is to secure outside project management expertise to do the evaluation. This is not a job for management, who may lack the knowledge and experience to effectively do the evaluation. Nor is it a job for internal resources. But it is the ideal job for a disinterested third party (don’t let the PMO being evaluated select the evaluator).

In some situations, major changes to the PMO may be unnecessary. For example, the PMO may be doing fine with smaller, less complicated projects, but can’t handle big, complex projects. If there is a large, complex project underway that the organization can’t afford to terminate or suspend, the solution may be to remove it from the PMO’s influence while minimizing the impact on the project.

Let’s say there’s a zombie project that is part of a larger program (and most usually are). The solution could be to create a IT program office in the sponsoring business organization and move the project there. The IT program office (and its projects and other activities) could be decoupled from the PMO. This may involve reassigning resources and some organizational responsibilities from the PMO to the IT program office.

While excising the project from the PMO addresses the immediate problem of maintaining project momentum, it does nothing about the PMO’s inability to handle larger, complex projects. However, if these kinds of projects are far and few, then it may make sense to limit the PMO to smaller projects that it can handle.

Every organization is unique, so the remedies I’ve described here may not apply to yours.

Wrapping it Up

During my career, of the dozen or so PMOs I worked with, only two were dysfunctional. Both of the parent agencies for these PMOs had “Dissenting Opinion” policies where someone could raise questions about a decision or a direction the agency was taken. Interestingly, neither agency extended that policy to dissenting opinions in the IT realm. Sometimes, the tools for addressing a defective PMO are already there, but not used.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: