What Do I Need to Know to Set Up a PMO?

I’ve Been Asked to Set Up a PMO. What Do I Need to Know?

First, let’s be clear. Setting up a PMO (Project or Program Management Office) isn’t exactly simple. It isn’t easy, it isn’t quick, and sometimes it’s not even a good idea.
 
On the other hand, for organizations that want to be better than their competitors at executing vitally important work, a PMO can be a powerful way to get there.
 
So for the next few months, we’ll explore what you need to know to do it right. In this issue, we’ll answer some basic questions (and bust some pervasive myths) about PMOs based on what we’ve seen over our decades of experience building and improving them for organizations of diverse sizes, industries, and geographies.
 
Let’s start at the best possible place…the beginning.

What is a PMO?
Would you believe this is a loaded question? Lots of intelligent people disagree about what a PMO is (or should be) and how it can best add value to organizations. So let’s use a broad definition that most people can agree on:
 

A PMO (Project Management Office) is a group or department within an organization that is accountable to build and/or strengthen excellence in project management across the enterprise.

 
This definition is broad enough to encompass a variety of types and sizes of PMOs. It also gets at the central reason that PMOs exist. The bottom line, PMOs are put in place to improve an organization’s project management results.

This doesn’t sound like the definitions I’ve heard…
Not surprising. If you look at common textbook or industry definitions of a PMO, you’ll see additional words like governance, standardization, standards, documentation, methodology, and reporting. 
 
These are some of the methods or functions that a PMO often performs as it seeks to improve an organization’s overall project results. 
 
To understand why we exclude these words from our definition, let’s perform a thought experiment. Let’s pretend that tomorrow, we all wake up to irrefutable evidence that standardization and templates actually lead to poorer project outcomes. (I know it’s far-fetched, but stay with me.) 
 
Would there still be a reason for a PMO to exist? If your definition of PMO centers on process standardization, the answer would be no.
 
On the other hand, if your PMO has been focused the whole time on what will move the needle on better project results, this new information wouldn’t threaten its existence one iota. Your PMO would simply chase the evidence in new directions, seeking to add value in new and more impactful ways.

Why do PMOs look so different from company to company?
If PMOs exist to strengthen project management excellence across an organization, it stands to reason that they will need to look different depending on the company’s size, industry, culture, and strategy. 
 
In fact, even within a single organization, the average life expectancy of a PMO before it changes something significant about its charter or structure is just two years.
 
It can be helpful to think of PMOs as falling somewhere along a spectrum between “supportive” and “directive.” 

• Supportive PMOs provide training, development, and consultation to business units that execute projects themselves.
• Directive PMOs take control of some or all of an organization’s projects by managing them themselves. 

Between these two ends of the spectrum, you might see varying levels of control, or governance and oversight, over how projects are managed at an organization.

How can we determine which type of PMO is the right one for us?
Great question! This one takes a bit of time to answer, which is why it will be the single focus of our newsletter next month.