Mavenblogs: Flipping the script on Project Management Office (PMO)

Managing Director Jon Vordermark discusses some mistakes organizations make when building and implementing Project Management Offices (PMOs), often undercutting their project leaders and relegating them to bureaucracy and administrative roles. For organizations that see project work as truly the crucible of change enablement, Vordermark recommends more Mavendog thinking.


PMOs are beneficial if built for the right reasons and in the right way. Their purpose is to make project managers more effective, and as a result, improve delivery quality and customer service. That being said, I personally have a love-hate relationship with PMOs, not because PMOs are bad, but because many organizations do not set up or use them properly. 



1. A PMO is purchased and implemented as an off-the-shelf product

A PMO should be reflective of a company's culture and environment. But in the rush to implement one, organizations sometimes choose to buy or outsource it. They spend millions shoe-horning a PMO into the organization, along with pre-packaged tools, or worse, a managed-service project management staff. The PMO then faces resistance from internal departments. Even large organizations have a poor track record with such PMOs and have to cut them because of high Cost of Ownership, poor customer adoption, and spotty Return on Investment. PMOs are an evolutionary support service for effective project management. It must be built organically over time with experienced project managers leading the way. 

2. A PMO evangelizes and enforces one delivery methodology

The most common methodological dichotomy in project management is Agile versus Waterfall. For some organizations it has become an internecine debate, with PMOs seen as a canonical enforcer of "right" versus "wrong". But organizations that favor one methodology over another force project managers to adhere to something that may run counter to project realities. Methodologies should be fluid – a tactical decision made by experienced project managers on the front lines, who have the best visibility and understanding of current conditions.

3. The PMO overly monitors, manages, and controls its resources

The case for PMO governance is that it promotes delivery consistency and repeatable success. And that is true, but only to a point. Delivery consistency has more to do with the experience project managers and delivery team integrity than a PMO. Once a PMO takes a heavy-handed governing role, the project manager finds him or herself in an administrative, policing role rather than delivery-motivated work. Governance must NOT compromise a project manager’s authority, accountability, and flexibility when leading project teams.

All three of these mistakes is tied to one underlying misunderstanding – that a project manager is subservient to the PMO. Such a view subverts an organization's most valuable resource for driving change. A project manager's very purpose is to be a change agent. They are the tip of the spear for implementing each component of corporate strategy and innovation.

[Note:  Mavendog's Unilateral Project Management (UPM) practice offers executives the option of side-stepping a dysfunctional or overly bureaucratic PMO.]


Three Mavendog Philosophies for PMO setup and function:

When I advocate "flipping the script" on PMOs, I am referring to relegating PMOs to a support vehicle for project managers in the field (rather than the other way around, which is unfortunately more common). Below touches upon three Mavendog recommendations to achieve this shift in PMO thinking.

1. Organic tools tailored to the company's products, customers, and delivery teams:

PMOs are a good repository of project management tools and techniques. But rather than buying and imposing them from on high, I advocate using project managers to build them in real time. Project managers can flag any practice, process, and template that works well in the field and could be a potential PMO standard. The goal is to tailor the PMO to the organization's domains, customers, and delivery teams. The PMO, therefore, should be organic and unique to the organization it supports. This approach also applies to methodology-specific tools. Whether a project calls for either iterative development (Agile) or Waterfall methodology, the project manager has the best insight to identify and promote the one that works best.

2. PMO-Project Manager field coaching (customer-specific):

Mavendog recommends a PMO that supports its project managers by prepping them for the markets, customers, and stakeholders they encounter on their projects. PMOs are not just repositories of tools and templates. They are wonderful sources of customer trends, tribal knowledge, and idiosyncrasies. Most organizations have a broad diversity of internal and external customers (i.e., various lines of business; regions; size; etc.). Through coaching/advisory services, PMOs can help project managers navigate unfamiliar terrain or pitfalls that have nothing to do with project management processes and procedures. And as a result, project managers improve their chances of building buy-in and change adoption.

3. Integrate the PMO into a BMO (Business Management Office): 

The PMO should be a part of an integrated group of customer support services – services such as Marketing, Communications, Member Services, Corporate Planning, IT, Portfolio Management, and so on. Together, these groups comprise a Business Management Office, or BMO. Working with BMO leaders, the PMO can help establish a cohesive, seamless customer service vehicle, all of which provide far better support services and tools for the project managers in the organization. Without this BMO relationship, the PMO's core services lose customer context and value.

[Note: PMO setup support falls under Mavendog's Change Management & Rehab practice. It is led in concert with our partnerships with Align 3 and Bottom Line, Inc. The service is also supported by our Executive Project Managers in Project Management Assessment and Project Management Command practices.]


Dedicated Project Teams, not Sourcing Departments

Project consistency and repeatability have more to do with team dynamics than anything else. The more projects that are staffed by the same core project leaders, the greater the likelihood for consistency, quality, speed, and reduced cost. The barrier to this setup is traditional departmental silos (the matrixed environment we all know so well). In this paradigm, the PMO becomes an internal staffing agency, negotiating with each department individually for resources to cover the projects in its portfolio. The final product is a patchwork delivery team with resources who are pulled in multiple directions -- between that of their functional department, and that of their new project. 

An organization's objective should instead be to keep delivery teams together, especially teams that show good unit integrity and have a track record of success. This construct points to a more projectized than matrixed organizational model. And while it is often utopian to move to a truly projectized organization, it is still a utopia that one should aspire to, especially if the organization has a mission of innovation and reinvention.

In the projectized vein, Mavendog recommends organizations build as many dedicated delivery teams as possible, each with an experienced project manager at the helm. It is a construct where the PMO provides only governance and support, and it gets away from being an internal staffing agency. In fact, in this paradigm, the Business Management Office (BMO) (not the PMO) works with senior project managers to construct the right dedicated teams.

The dedicated project team model sounds extreme and unusual, but it is not unorthodox. It is common to strong-matrixed structures, and could be more effective for companies with a diverse customer base.

[Note: Mavendog helps BMOs define the team-driven delivery model. Led by Project Management Command consultants, we work with IT Road-mapping, portfolio management, and Member Service leads to identify factors that would make up an dedicated project team (e.g., recurring IT project needs and domains; customer types and location; strategic priorities; complexity and sensitivity; etc.).]