Disband Your PMO

After nearly 30 years of project work, I struggle to understand the role of a project management office (PMO). Even though, I have written of the pros and cons, and read a plethora of articles, opinions, and how-to guides little has been done to convince me that the PMO is reducing project failure. It seems to be nothing more than a tool to fill a void in leadership? Even the acronym, which is so widely thrown around, has little meaning as the "P" has no less than four meanings. It is an executive's crutch for their lack of understanding in how projects work. These, like other, unattended holes in the corporate accountability create opportunities for new and greater bureaucracies and empires that further obfuscate accountability.

But, Our PMO Is A...

I already hear distant sound of cocking guns, I can sense people taking aim, and I can feel the anger rise with the murmuring, "I'm gunna' to shoot this idiot down." The issue is a much bigger business problem than the PMO, someone's empire, or the project. The trouble is accountability and leadership—more accurately, the lack thereof. The PMO, which at many companies is created and destroyed with regularity every four years, tries to fill a number of corporate gaps: project prioritization, uniformity of reporting and process, resource allocation (fancy words for "Gimme a PM"), PM coaching, support, and advocacy, corralling the problem project; or some combination of these attributes. Anyone of these honorable goals, however, is a misdirected effort at compensating for deficiencies elsewhere in the organization.

As a Prioritization Group

PMOs that prioritize the queue of projects are simply hiding the fact that the "leadership" is shirking their accountability in providing clear, concise direction. CEOs and their direct reports should be prioritizing initiatives and projects to meet corporate goals. Having a secondary layer in place to make that call is a feeble attempt to push accountability out of the executive suite. The cries that the PMO has to coordinate priorities across various business units (the justification for many IT-PMOs) simply points out that the "leadership" does not comprehend the complexities of the matrixed organization and they need to spend time understanding basic resource loading.

As a Standards Group

"But, how will we be able to compare performance if we are not all using the same standard process?" Projects by definition build unique capabilities, how in the world can you expect them all to use the same processes? Some projects build new capabilities and need an adaptive and innovative approach; other projects are more repeatable and require a well-documented and tested methodology.

The answer is to look for the project manager with the proper skill set to run that type of project. Speaking of which...

As a Resource Group

Although I hate calling people resources, shouldn't Human Resources be supplying people with the right skill set? Just pop into a dictionary or thesaurus and alternative words for resource include supply, store, source, and means. Why not have a store of project managers with various skills that HR has in their inventory. As a sponsor initiates a project and identifies the required resources (money, people, buildings, time, etc.) they define the skills required for the job and Human Resources identifies the resource who has the means to complete the job—not just any PM currently on the bench. The executive sponsor is accountable for describing the need (it is his or her project after all) and HR is accountable for finding the right person. Viola! Done.

As an Advocate

"Our project managers need advocates for when they run into political road blocks, or the sponsor or end-user is not engaged." Wait a minute. This is clearly a problem with prioritizing the project. "Politics" is simply a code word for someone not being onboard to support the project. Lack of engagement is misaligned priorities—someone has something more important to do than the project. We are back to an executive sponsor problem or a CEO that has confused the priorities. Remove the bureaucracy—the PM should be raising the flag to the executives. They need to change the priorities of the disengaged people or drop the priority of the project.

As a Project Recovery Group

I am always amazed when companies build internal project rescue teams. Yes, rescuing projects is my business, and I am not worried about the competition. There is plenty of work to go around! I am amazed at the strategy of fixing a failed project, rather than running it right the first time and running health checks. Focus on preventing the problem project, do not take pride in how many you can fix.

The Real Picture

The other day, I was talking with executive at a multi-billion dollar corporation who is a good friend. He was complaining about the never getting the real picture of project status. "We continually get a rosy picture when my peers and I are clear that our culture is about transparency." Obviously that message has not gotten through and the layers of managers, PMOs, etc. have created the status quo of sanitized project reports, greener projects, and softer news through its standardized reporting system. Sorry, Liz, it is a cultural issue. She sighed, but I am unclear on whether she was willing to take the hit.

The Place for the PMO

The best role of the PMO is a temporary group to help re-align the organization. Step in the middle for six months and show the deficiencies in the organization. Help HR set up the "project manager pool;" help align the priorities to the corporate goals; move shared services closer to the customer; help the leaders define and communicate clearly articulated goals; help define the executive sponsor's roles and responsibilities; and, then, step aside and let the newly accountable organization do their job. Foster transparency and train the leadership on how to deal with the blunt facts it brings. Be proud to be an empowering leader and then, as all good leaders do, get out of people's way. Change the meaning of the "P" away from Project, Portfolio, Process, Program, and even People. Make it a Problem solving group that temporarily focuses on problems and solves them once and for all.

Related items

The other day a Latvian student contacted me for my views the connection between culture and success criteria—an important and intriguing topic. After working in Taiwan, Singapore, Korea, Japan, Israel, United States, and Canada, I wear many scars of both blatant and subtle cultural violations. I also know that within a culture one person's success is often another person's failure. So, after dispelling concerns about clicking on some random email link, I completed her survey (please feel free to take it yourself). In the process, I struck up a friendship with the student, Kristine Briežkalne, who is studying at Riga International School of Economics and Business Administration . She has some interesting views and presented me with a Venn diagram showing four frames to a project (business, client, project management, and growth perspectives) and how they intersected. As the diagram is part of her Master's thesis, I will let you ponder the how to label the overlapping areas (an eye-opening exercise).

There is a reason we do not teach classes on fixing failing projects. Many a cynic feels that we simply do not want to teach our trade, however, our reason is far nobler—we should be teaching prevention rather trying to create white knights to save the day. It is the same philosophy as building a fence at the cliff's edge rather than an emergency room at its base. Our language is replete with idioms telling us to look past the symptom and address problems at their root cause. 'An ounce of prevention versus a pound of cure' or 'a stitch in time saves nine.' Please, feel free to supply your own in the comments. Unfortunately, most of our businesses loathe this philosophy, waiting to address an issue until it is irrefutably broken.

Trust relationships, certifications, and standards sound like such a safe harbor. These sound like such great words in a proposal or statement of work. How could you possibly go wrong building a trusted relationship with a customer by committing to follow a standard? In fact, this can burn you… in court.

No one ever starts a project with the goal of ending up in court. In fact, litigation may never cross your mind; after all, you have built a trusted partner relationship. Taking a few cautionary steps, however, will make your life easier if you end up in that ill-fated litigious position. Your best chances for success come long before you enter the courtroom—even before the project starts.

It was such an innocuous question, "Working on an article; what is the biggest problem you see with project governance at orgs? Can you comment?" Can I comment? Really? That is like cheese to a mouse. Where could I start—bureaucracy, draconian process, poor executive sponsorship, disengaged leaders? Plenty of fodder, because they all lead to project failure. I fired off, "Creating an over bureaucratic morass stifling innovation & implementing process instead of cultivating leaders." Then the maelstrom started and it went directly to the gap between the executives and projects managers. Naomi Caietti, Robert Kelly and I had a great conversation. Most of the thread is below.

"Kotter, ADKAR, or CAP which methodology should we be using to build our approach to improving project adoption?" I hear this question repeatedly from people trying to implement an organizational change management (OCM) program. The problem is that is the wrong question. Take a perfunctory peek at any of the models and you will see that in the quest for an answer people have mistakenly jumped over the first few steps and they head down the road of failure. It is a Catch-22; unless you already have an OCM process in place, you will most likely fail at implementing it. Putting one in place, however, is a change—one of the most difficult cultural transformations your company will undertake. As a result, people jump to the solution stage, which is well down the change management process path (which, they did not know, ironically, since there was no procedure in place).