Why a (Proper) PMO Matters

What a PMO is

According to Project Management Institute (PMI®) PMBOK® Guide 5th Ed: “A project management office (PMO) is a management structure that standardizes the project-related governance processes and facilitates the sharing of resources, methodologies, tools, and techniques.  The responsibilities of a PMO can range from providing project management support functions to actually being responsible for the direct management of one or more projects.”  According to the PMPOK a PMO can take various structures depending on the organization’s need for control and influence of the PMO on the organization.  The range of control and influence quite naturally will range from low (pretty much non-existent in my view) to high (pretty much complete control in my view).

The PMO’s primary functions are: managing shared resources, PM methodology development and organizational process assets, PM development, monitoring compliance with PM standards, and coordinating communication across projects.  PMBOK® further explains that the PMO and organizational PM’s have differing and unique objectives and thus are driven by different requirements.  PMO – manages major program scope, optimizes organizational resource utilization and manages methodologies, standards and interdependencies among and between projects.  The individual PM’s are focused on project specific objectives, controls project resources to meet project objectives and manages unique project constraints of scope, cost and schedule.

According to me a PMO is all of what the PMBOK® says (after all I really find it hard to argue with a book in its 5th edition) and also is the glue that binds the organization’s overall project endeavor or organizational project management (OPM) as PMBOK® puts it, plus it is the lubricant that makes all of this work.  The management of the components of the organization’s OPM – project portfolio, program management and project management – is (according to me) the only focus of the PMO in a mature project organization.  The PMO will use the functions listed above to drive to achievement of excellence in OPM which in turn will drive the organization to achievement of its strategic goals.  This focus on OPM aligns and ensures that the individual projects undertaken by the organization are intrinsically linked to the organization’s strategic goals and objectives.

 

What a PMO is not

According to me the PMO is not the arbitrator of the organization’s project portfolio.  This is the sole domain and responsibility of the organization’s strategic leadership team or SLT.  This does not mean that the SLT will operate in a vacuum in deciding the makeup of the project portfolio but rather that the buck stops here in regards to selection of projects to support the strategic plan.  The PMO might well assist or even be the sole provider of project analysis used to measure and rank a project’s worth to the firm.  It just simply cannot be the determiner of the makeup of the portfolio.

Why?  Because the PMO by my stated focus of being the glue and lubricant of the project portfolio, program and project management must have a focus towards monitoring and measurement of organizational project success.  This does not mean that the PMO leadership has no ‘business acumen’ as some of my learned colleagues in the PM profession might infer (http://blogs.daptiv.com/2012/07/has-pmo-become-a-bad-acronym/).  The job of holding project sponsors accountable for benefits claimed is the responsibility of the SLT, not the PMO as a functional group.  Holding functional leaders accountable for their area of responsibility includes holding them responsible for organizational projects they champion.  This can only be done by those who have the responsibility and the power to hold leaders accountable.  One functional group cannot hold another functional group accountable for its performance.

 

PMO’s place in organization

According to PMBOK® the PMO can have varying structures depending on the organization and desire of the SLT.  The place in the organization or control and influence as PMBOK® states it is dependent on how the organization establishes the PMO structure.

PMBOK® lists three structures:

  • Supportive – basically a project repository supplying templates and best practice with low control.
  • Controlling – providing support and compliance such as PM methodologies, templates and tools.  Control here is moderate
  • Directive – is the highest level of control in the organization with direct management of projects.

While it is not stated specifically the PMBOK® seems to infer that the PMO is a functional group standing outside of any other functional group.  And the listed structures imply a progressive path for the PMO.  And while the PMBOK® does not state it directly I will state that the inference is that an organization with a controlling PMO manages all projects through a single PMO via the ‘portfolio management’.   This would be an organization who would manage for instance information technology and manufacturing operations projects through a single PMO by using portfolio management to relate specific projects with the proper operational focus and resources.

According to me the only proper place in an organization for the PMO is as a standalone functional group with the same stature as finance.

Why?  Because for example as a captive unit of IT the PMO will be solely influenced by and owe allegiance to IT leadership and all projects will be by default ‘IT’ projects with no functional group sponsor.  This will mean that buy in from finance and marketing for implementation of a Customer Relationship Management (CRM) system will be minimal at best no matter how much effort is placed on including finance and marketing in the project phases.  Organizational realization of the economic benefits of CRM will be slow in coming if they ever materialize, the worth of projects will always be questioned, end-user resistance will always be high and projects will always fail (success as measured by budget, schedule, scope).  Only as a standalone functional group will the PMO be able to exhibit the stature and command the proper resource allocation required to manage projects to the organizations strategic plan.  The SLT and especially the CEO must hold the PMO in the same regard as finance and must also hold the PMO responsible for efficient and effective management of the organizations project assets.

 

PMO management structure

According to me the PMO must be a standalone functional area with leadership versed in both business and project management.  The ideal credentials of the leader(s) for this operational area would be graduate education in both business and project management (MBA & MPM) with a technical undergraduate degree as a bonus.  The technical area is pure bonus and in my view is not a leading criteria as I am quite certain that a base in education, philosophy or marketing to name a few would suffice as well.  The only reason I mention technical training is that it helps to understand the mindset of technical folks – IT, engineers, architects, scientists — when working through the organization.  The leader of this functional area must be a direct report to the CEO and on par with other functional areas especially finance.  The leadership of the PMO must focus not on PM processes, the PMO will staff with proper SME’s for this function, but rather on the business of the organization.  The leadership of the PMO will ideally be a member of the SLT and will need to converse and argue business reasons for projects to support strategic goals.

The PMO is as is IT, a service operation to all other areas.  Its only purpose is to manage projects for the benefit of other functional area.  Whether the project is implementation of local area network improvement or installation of a new manufacturing press the projects are all initiated via the same process and managed with the same methodology.  Project managers (in my ideal world) report into the PMO.  Resource (human) required to staff the project will be handled in various ways depending on the organization but they will general follow one of the following models:

Functional – organizations where all project staff reports into a functional manager and serve the project at the pleasure of the manager.  Here the PM has little control over the resources and as a result the outcome of the project.

Matrix – organizations are a blend of functional and pure project organizations and will range from a weak to a balanced to a strong matrix operation.  Weak matrix structures work with project coordinators with de-facto control of resources by functional managers.  Balanced structures move towards more PM control with strong matrix assigning functional resources directly to projects and control of the PM.  Only in a strong matrix structure can an organization truly operate a PMO.

Projectized organizations are at the opposite end of the spectrum as the functional organization where most of the resources are moved in and out of projects as required.  This is the form most will see when using a major IT servicing organization such as HP or IBM.  In this form the servicer will assign PM from the PMO and obtain resources from support groups as required to staff projects.  It is this structure which provides the PM with the most direct control over the project resources and project success.

 

PMO and the organization

According to me there are two type of organizations when it comes to organizational project management – immature organization and mature organization.

Immature Organization

The immature organization is one where it has either been recognized that management of projects needs a consistent approach but they are hesitant to alter the functional structure too much or too fast or the organization has latched on to ‘project management / PMO’ as a new fad with an expected quick return without bothering to understand the science behind project management.

I will only deal with the first case as the second case will abandon project management when the expectant results are not forthcoming.  The reluctance of the organization to alter the functional structure and move responsibility for undertakings formerly managed by functional leaders is understandable for a minute but completely without merit.  Immature organizations might eventually recognize the return on investment that a proper PMO function will bring to the organization.  An immature organization will generally continue to compartmentalize projects and insist on a ‘technical project manager’.    While a technical PM is not inherently bad it is not required either and may be a determent to project success depending on what emphasis is placed on the PM skills vs. technical acumen.  While some will argue that a PM leading an IT project for instance must have a technical background they will not argue for the same individual having exposure to PM training or practice as they value the technical skills as required and PM skills as a bonus.

The immature organization will generally not have a functional standalone PMO as I have described but rather operate projects out of each functional group.  This will unnecessarily reduce the level of project success in the organization due to lack of project team cohesion across the organization.  Projects will compete for scare organizational resources without regard to projects in other functional areas.  Immature organizations have not yet recognized the missed opportunity of OPM as defined by PMBOK®.

 

Mature organization

The mature organization recognizes and moves to fully exploit the opportunity offered by OPM and will have a functional PMO reporting to the CEO on par with the finance group.  OPM is recognized by SLT as a priority function which requires their direct focus.   PM’s will report into the PMO and projects selected by the SLT to support the organization’s strategic plan will be staffed by resources as required to ensure project success.  As noted by PMBOK® the PM’s role will become increasingly strategic with a focus on applying proper project operational knowledge and techniques.  A mature organization with a projectized structure does not require PM’s with technical knowledge in any specific discipline as SME’s for various project tasks are assigned as required by the project plan.  The mature organization recognizes the PMO as a required function and PM’s as a distinct discipline with a specific organizational charter.  The mature organization will recognize that functions such as project management and information systems are distinct disciplines and require specific skills and resources.  Information systems require architects who fully understand IT and continue to study the discipline but who can also relate IT to business issues.  Project management requires the same type of SME’s as the IT function only focused on PM methodology and best practices.

Tim Knutsen

Comments are closed.