Building a PMO from the ground up: Three stories, one result

Introduction

A project management office (PMO) is a strategic component of an organization trying to improve its ability to deliver projects that bring value to the organization. Historically, the process of starting a formal PMO has been assigned to different entities, depending on the scope of the office. However, it is always a challenge to start from scratch.

This paper will establish a basic understanding of what a PMO looks like. Then, it will describe three case studies based on real-life experiences, which will form the basis of the conclusion—the important aspects to consider when building a PMO. The analysis will be performed based on the impact of the implementation in three significant areas, which represent the highest risk. When properly addressed, they provide the highest value and the most noticeable impact of the new entity.

Premier on PMO

Project management offices have been part of project management practice for many years. Lately, the use of the PMO term has expanded to mean “portfolio management office” or “program management office.” For the purposes of this paper, the term will be used in the classical sense, but it may mean that the PMO will have some mandate around programs or portfolios. The PMO is defined as “an organizational structure that may be used to standardize the portfolio, program, or project-related governance processes and facilitate the sharing of resources, methodologies, tools, and techniques” (PMI, 2014, p. 6).

PMO Models

There is no definitive source of truth or a universal accepted classification model for different kinds of PMO. Classification is important because project management practitioners typically turn to best (or accepted) practices when faced with the challenge to explore a new task that requires more information than the one they possess from their own practices.

This paper will use three references that will provide common elements to be considered in the case studies.

The first model comes from a Project Management Institute study on PMOs. This study outlines the following classification for PMOs (PMI, 2013, p. 6):

1. Organizational PMO: Provides project-related services to support a business unit
2. Project support services: Provides enabling processes to continuously support management of project, program, or portfolio work
3. Enterprise PMO: Highest level PMO, typically responsible to align project and program work to strategy
4. Center of Excellence: Supports project work by providing the organization with standards, methodologies, and tools
5. Project Specific PMO: Provides project related temporary services as an entity to support a specific project or program

The second model comes from a very experienced practitioner who presented his experiences as part of the PMO Symposium in 2012. Based on his multiple experiences in the establishment of PMOs, he provided the following classification (Dow, 2012):

1. Supportive: Provides services to project managers
2. Controlling: Enforces compliance of existing methods and standards
3. Directive: Directs the work to be executed based on strategic and tactical plans
4. Managing: Manages the work in projects and programs
5. Consulting: Serves as an experience-based consultative body to project managers
6. Project Repository: Repository of previous project documentation, lessons learned, etc.
7. Enterprise PMO: Provides PMO services to the organization
8. Center of Excellence: Creates the standards and methodologies, and provides tools
9. Managerial: Manages the project and program managers, and eventually other project resources
10. Delivery: Manages the projects and programs

Finally, the A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) – Fifth Edition also provides a basic description and classification of PMOs (PMI, 2013a, p. 11):

1. Supportive: Provides a consultative role to projects by supplying templates, best practices, training, access to information and lessons learned from previous projects
2. Controlling: Provides support and requires compliance through various means
3. Directive: Takes control of the projects by directly executing them

Creation of PMO

After looking at the possible models, the next obvious question is: Are there any standards or best practices around the creation of a PMO? Unfortunately, practitioners facing this question do not have a readily available source, handbook or template. A few authors have written books and articles that hint best practices as it relates to create a PMO, especially where no one exists.

Levatec (2013), for example, attempts to define a series of parameters to define a PMO for a specific organizations based on the concept of frameworks, domains, and enablers. He notes that much confusion exists on the definition and it extends to the criteria used to establish a specific PMO with a specific mandate.

Dow (2012) proposes a workflow with twelve very specific steps that, if properly followed, will take a practitioner from start to finish in the process of creating a PMO.

Perhaps the most recent and detailed source of information is the publication of The Complete Project Management Office Handbook (Hill, 2013). This publication consolidates many of the most common trends, decisions, and practices that can help an organization build a successful PMO. Although the author does not provide a “recipe” for the actual creation, most of the concepts can be easily extrapolated to a particular situation.

Based on the research, the case studies presented in this paper will be analyzed in regards to three specific elements which will provide the largest amount of information and lessons learned:

1. Scope of the PMO: What are the services that the new PMO is supposed to provide?
2. Stakeholders: Who are the benefited parties of the new structure being created?
3. Business value: How much value is added to the organization via the creation of the PMO?

Case 1: A PMO for a large IT Service Unit

A large IT company was awarded a multi-million, multi-year outsourcing contract to support an infrastructure transformation and services transformation project for a government entity. As part of the deal, the IT services contract was to provide a PMO to support two large programs, several small projects and establish a series of best practices to stabilize an ever-growing sprouting of ad-hoc project management practices.

Process

As part of the original proposal, a corporate practice team was to establish a tested and proven PMO template at the client site. Then, this team would train and transfer knowledge, processes, and tools to the local team and leave. The process was to last around 12 months.

As planned, the team arrived days after the contract was signed and quickly started to meet with the client to define the details of the operation of the PMO. However, from those initial meetings, it was clear that the expectations of the client and the template provided by the practice team were not aligned. The model proposed by the IT company was based on compliance; whereas, the client was expecting a more consultative approach (closer to a Center of Excellence model). As a result of those early interactions, the local management of the IT company decided to change the approach.

A group of local project management practitioners that was already working in the PMO for another client was appointed to bridge the gap between the client expectations and the ability of the organization to provide specific services. The group's approach was to build processes and define the services to be provided to the client, in consultation with client subject matter experts (SMEs).

As a result of this collaborative approach, the PMO was set up and started working six months after the contract had been established. The new PMO also established a governance committee to allow a joint review (of the PMO, not the programs or projects) of the PMO results and suggest changes and improvements.

Lessons Learned

Scope of the PMO

1. It is very unlikely that a corporate template can be applied when the new group has not validated that it is the right model.
2. Clients oftentimes do not express their full requirements and assumptions cannot be made.
3. Client had expressed that they needed help with best practices and methodologies. It was clear that a compliance model would not fit these needs.
4. This was an enterprise PMO, but it was also directed toward specific programs and projects. A mixed scope was difficult to manage, and input from both organizations was needed.

Stakeholders

1- The main stakeholders of this PMO were the contract managers in the IT Services organization and the project executives in the client side. It was a difficult and not very common mixture that created some interesting challenges as to whose interests had to be prioritized.

2- Project and program managers were caught in the middle of the discussion about the PMO mandate just when the projects were more vulnerable: during their initiation and planning phases. This created confusion and negatively affected the internal stakeholders within the IT organization.

3- For practitioners of the IT organization, it was a positive turn of events that they were given the opportunity to correct and learn from the experience. This created a positive and collaborative atmosphere that also permeated the client.

Value

1. The organization was able to quickly recover and provided more value to the client than initially expected. The practical approach to the creation of the PMO brought people to the table that usually were spectators of the process.
2. The new governance structure set up for the PMO was copied by other areas of the IT services (namely service management and security and compliance). It was considered a success.
3. Value is not only real but perceived. Most of the actions taken to create the new PMO could not be quantified in terms of revenue or cost (even less when the PMO is set up to start the execution of a project or program). Practitioners need to be careful when considering economic benefits as a tool to justify specific activities in the creation of a PMO.

Case 2: A PMO for a transportation company

A large private transportation company decided to set up a PMO for its IT operations (Departmental PMO). However, the same company had an established PMO for its engineering group and also a corporate structure closely resembling, at least functionally, an enterprise PMO.

Process

A project management practitioner was hired to create the new IT PMO. Several constraints were evident: the new PMO did not have any resources assigned to it, it had to play within the rules and regulations of the quasi-corporate PMO, and it was required to deliver results within a year.

The PMO manager set his sights on three specific areas: a project delivery framework, a series of templates and tools for the IT Project Managers, and a reporting mechanism to communicate the interim results of the process. Within the first year, all those areas had been successfully implemented. However, the main stakeholders were still dubious about the value of the PMO, as the delivery of IT projects had not improved. The mandate of the PMO was then shifted to focus more on delivery and delivery capabilities.

Lessons Learned

Scope of the PMO

1. The scope of the IT PMO was clearly delineated by its departmental reach. However, it wasn't clear what the main services will be and the initial assumptions were wrong. It was necessary to establish a center of excellence, but at the same time it was expected that some delivery capabilities were in place.
2. As with any project, the implementation of a PMO may have changes. These changes must be properly controlled. The PMO lead, acting as a project manager, should decide when it is necessary to formally document the change request.
3. Overreaching mandates in a functionally-oriented organization are not the best environment for a departmental PMO. A certain degree of liberty may be exercised but it has to be properly negotiated within the organizational hierarchy.

Stakeholders

1. When the PMO is created within a functional organization, the stakeholder analysis should be done before any action is taken. Do not make assumptions as to what activities may be performed in a closed and well-contained environment of a department or business unit.
2. Establish a clear charter to underline the expectations. These expectations can make or break the PMO in its early stages. Do not be afraid to apply corrective actions.
3. Success criteria or objective metrics that stakeholders can relate to are an essential tool for the practitioner trying to establish a PMO. They are a key tool to track results and establish baselines for the future.

Value

1. Value can be subjective. Even the most mature organizations cannot establish a value framework that can be 100% measurable under all circumstances. The creation of a PMO can bring value over time, but it has to be properly framed in the forming period to avoid disappointment.
2. When establishing value measurements, try to determine what is important for the organization. If financial results are the key aspect, any measure that does not relate back to it will be seen as innocuous.
3. Not all project issues can be attributed to the PMO or the lack of it. Be prepared to defend the value when the mandate of the PMO does not provide the tools to positively deliver the real or perceived value.

Case 3: A PMO for an educational institution (Research projects)

A large educational institution received large funding from a Federal Government to continue the development of several key research projects. The Federal guidelines require a very demanding reporting process that can only be achieved by properly planning and controlling the projects being funded.

Process

The institution found out that their project management practices were not up to the standard of the requirements of the funding agency. In addition, several in-flight projects also needed help to reach a successful outcome. An experienced practitioner was hired to establish a set of best practices to be used by the research projects and also be used as a template to engage other areas and disseminate those best practices within the organization.

This effort is still in its initial stages but there are clear indications that the practices are starting to permeate the organization.

Lessons Learned

Scope of the PMO

1. It was clear that the organization was looking for a supportive PMO. The need was immediate and did not have any indication of possible scope creep.
2. All levels of the organization accept and understand the benefits of the approach. None of the stakeholders is looking for more than has been required.
3. Stakeholder analysis has determined that additional elements of the best practices in program and portfolio management may be implemented in the future. However, no resources have been provided and it will be risky to try to extend the scope of the mandate.

Stakeholders

1. The main stakeholders belong to a functional organization with a clear mandate around projects. They are convinced of the value and need of the PMO.
2. Other executives and have not entirely bought into the concept of having a PMO. For example, one area is using a very particular approach to manage their projects, and it is their belief that a PMO will try to change this approach.
3. Grassroots support has been difficult. The organization has been managing projects with a very basic or no standard approach for many years, and people fear change.

Value

1. The PMO manager has been accepted as a member of the Operational Executive Committee. This is a great step because it shows that the executives see value in the discipline of project management.
2. New funding proposals include a narrative around standard practices of project management being applied to ensure positive results in the research projects.

Conclusion

These three cases highlight how different the task to “create a PMO” can be. It is clear that each organization has different expectations around the PMO. It is a consequence of the different frameworks that can be applied to its creation. It is also difficult to establish common threads that can be used to establish a set of parameters to be used to direct the creation of any PMO.

However, as the lessons learned demonstrate, there are a few common elements that can be extracted and used to drive decisions.

Positive lessons

1. It helps to have a clear understanding of the scope. In the three cases, it was clear (at least at the beginning) what the intent or the need for a PMO was. Any practitioner tasked with this activity needs to focus the energy of the first few weeks understanding what model needs to be applied.
2. If there are changes, they have to be discussed with the stakeholders. If expectations are not fulfilled, the value of the PMO can be greatly understated or even questioned early in the process.
3. The main stakeholders need to be identified and they have to be on board. Do not try to get everyone on board at the same time. If additional stakeholders need to be engaged, make sure there are not forgotten and bring them to the table as soon as possible (but not earlier).
4. Define early in the process what is the success criteria. IF objective metrics or measurable objectives are agreed, make sure they are tracked as soon as practically possible.
5. Define the value proposition early in the process and use checkpoints to validate. The last thing stakeholders and practitioners want is to find out late in the process that the value proposition has been over or understated and that the time spent on the activities has been “wasted” on the wrong things.

Suggestions for improvement

1. Do not underestimate the complexity of change management. As time progresses, make sure the extent of the change and new processes, standards, roles, and responsibilities is clearly understood. The three cases have run into deep issues around this topic but this risk can be properly managed with the right tools.
2. Do not try to rush it. The implementation of a PMO, even when it is a mandatory or deeply needed activity, cannot be rushed as it involves lots of analysis, planning, and legwork. This has been a major concern in all three cases, but it can also be properly managed, especially as it relates to stakeholder expectations.
3. Make this clear from day 1: The PMO is NOT the solution to all project issues in the organization. It could be a great idea to run a parallel project to assess the project management maturity at the same time as the PMO is being created. Organizations need to understand where they are as it relates to project management practices and they need to make sure the PMO will attack either the root cause of some of the symptoms of lasting practices that may have brought projects to unsuccessful outcomes.

These three cases highlight that even in the most demanding environments, a project management practitioner with the right guidance should be able to provide the expected result: an established and functioning PMO.