7 Components of a PMO Strategic Concept

Introduction

If you plan on building or recommending the deployment of a PMO in your organization, it isn't too early to start thinking from a strategic operations perspective. If you’re the one selling it - or, perhaps the one buying it - then the effort will no doubt begin with a strategic formulation of this sort...

Since the implementation of a PMO is a project itself, this is considered the ‘prior to’ formal planning document that lays out the organizational objectives and requirements of the PMO.  Here, the focus is on the operational capabilities of the PMO.

Specifically, the PMO Strategic Concept serves four purposes: (1) Establishes the Business Imperative & Mission of the PMO; (2) Defines the goals, deliverables and continuing service functions of the PMO; (3) Provides a basis for the detailed PMO implementation plan; (4) Acts as a marketing vehicle for the PMO.  Let’s take a look at the various components.

Business Background and PMO Mission

This section describes the current business situation – specifically, the current organizational project/portfolio management situation.  This section of the Concept provides a clear, succinct executive summary of what is right with the organization, what is wrong with the organization, how you got there as well as how the PMO will engage the organization to improve the situation. 

If possible, the concept should embody high-level objective data which support the notions of what is wrong in the organization.  Examples include observations, project performance data, PM Assessment or preliminary assessment.  Finally, the nature of the PMO remedy in terms of the people, processes, and tools involved should be summarized.  This should be no more than one page in length.

If you plan on building or recommending the deployment of a PMO in your organization, it isn't too early to start thinking from a strategic operations perspective. If you’re the one selling it - or, perhaps the one buying it - then the effort will no doubt begin with a strategic formulation of this sort...

Objectives

This section will spell out in very certain terms the PMO’s people, process and tool goals. These are not measures of success but rather what the PMO will accomplish to realize the measures of success specified later in the Concept.  Examples include items like PM training, process standards to be developed and implemented as well as any systems required to execute the PMO’s strategy or systems falling under the organizational control of the PMO.

Span of Control

Span of Control refers to and specifies what does and does not fall under the authority (or span of control) of the PMO.  An excellent example of this is the entire project lifecycle – the PMO might be responsible for the lifecycle from concept through closeout but is explicitly removed from responsibilities surrounding implementation methodologies.

The implementation methodology might reside strictly within a development group, but the PMO might have a say in stage gate monitored attributes. The project selection or portfolio processes might be supported by the PMO but in actuality managed by Finance.

PMO administered systems would be designated as such. Personnel authority would be specified as well – PMs might work directly within a PMO or for a development or business unit adjunct with a dotted-line relationship to the PMO for compliance, training, reporting, etc.

Processes

This section includes any process or process improvements which the PMO will implement or existing ones that the PMO would be responsible for.  Establishing repeatable change control practices or the deployment of a planning standard designed to work with different development methodologies are examples.  

A highly inclusive list would include the core project standards of planning, execution, tracking/control and closeout along with specialized approaches to strategic planning and selection, stage gating, capacity planning and resource allocation.  Axelerate's article regarding time reporting defines a typical process scenario.

Service Functions

Service functions represent the on-going operations of the PMO in terms of services provided to the organization at large.  This includes items such as process or system training functions, project audit, review or assist, even production of a PMO Newsletter – any routine, repetitive services should be listed.  These will need to be assessed in more detail later to ensure the PMO is properly staffed to meet its obligations.

Systems

Any system under the PMO's charge or identified for roll-out would be cataloged as well.  Normally this is confined to the strictly PM or Portfolio Management line of tools.  However, development or collaboration tools may find their way into the PMO Span of Control. 

In the cases of systems 'owned' by the PMO, their responsibility might include administration of a system, various levels of support, training, or it might have the responsibility for its implementation as well.

Measures of Success

The measures of success applied to a PMO deployment will vary from organization to organization.  Successful completion of all stated objectives will be primary.  Additional factors might include cost-benefit measures to be assessed, before and after maturity assessments, organizational surveys where respondents assess the PMO from their particular organizational perspective.  Ultimately the measures of success will depend not only on requirements of the organization but on the scope of PMO activities.

Conclusion

Worked through completely, this article develops the PMO as a concept.  To be sure, this is an "out of the gate" approach.  If you're PMO initiative is in a more evolved state and requires more in-depth - and perhaps time phased information for management - then PMI's "PMO Road-map" is worth reviewing.

In this treatment, I have intentionally excluded certain programmatic details  such as costs, risks, assumptions, facts and constraints. This data is passed over since it isnot descriptive of the concept itself – however important they may be as program variables.