Some project management offices (PMOs) are annoyingly clumsy at times. Just trying to launch a PMO with suitable governance can be tedious.  A huge motivational factor for implementing a PMO is the amount of pain that the organization feels over failed projects. If most projects end successfully without the benefit of a PMO, there may not be a strong need to build one. However, if there is a lot of pain associated with project delivery, then it’s best to invest resources in a PMO to address the situation.

The cost of building a PMO is a factor. A PMO that includes all the bells and whistles could cost more than $130,000 to build. However, if you get it right by establishing enterprise standards for project management, you may be able to reduce project costs overruns by half as well as save some projects that may otherwise be delayed or cancelled.

Organizations are adopting PMOs to improve effectiveness by putting IT projects under the PMO umbrella, one of the most powerful steps your organization can take to integrate project management into the enterprise.

PMOs: The early days
Since the 1990s, the early versions of a PMO offered very little service and support and hardly a whisper of career progression for project managers. Many failed because they used the PMO to “police” project managers instead of offering project managers direction and guidance, according to a 2001 Cutter Consortium report. By the late 1990s, the need for managing entire enterprise portfolios became evident to project leaders and PMOs began popping up all over. For neophyte managers and executives, the PMO proved to be the perfect answer. Here was a concept that allowed organizations to create an environment that would execute the business strategy. The PMO achieved this tactically by evaluating and prioritizing each project against the business strategy and, then, allocating suitable resources to each project.

Once a project was started, the PMO continuously monitored and tracked each project for variances and escalated to stakeholders in a timely manner. The key thing I must emphasize is that as organizational priorities change, so does the status of any project. The PMO facilitates adjustment to company changes by revising, accelerating, terminating or de-prioritizing any active/proposed project in the portfolio pipeline.

Do I really need a PMO?
 An organization typically needs to be of a certain size before the overhead associated with a PMO becomes beneficial. If you only have one project per year, then don’t waste your time on a PMO. If you have a handful of projects every year, you may still be able to get by using only the skills of individual project managers, although you can start a PMO on a small scale. If you have a large organization that delivers more than 50 projects annually you should start building a PMO immediately. (See Figure A.). Chances are you’ll find you have quite a few project managers, each possessing varying skill levels and experiences working on their own projects. Those managers may be unaware of other project successes or even what anyone else is doing. If this sounds familiar, get moving with a PMO.

Caveat emptor: Remember that any PMO will cost money and staff to run. In many respects, a PMO reflects an overhead investment and executives are not enthusiastic about creating excess overhead. The trick is that the money and time invested in the PMO will be made worthwhile by allowing project managers to execute projects better, faster, and cheaper across the enterprise.  A centralized PMO makes great sense if you want to ensure that all your project managers have a core set of project management skills, use a common methodology, common processes and templates, and have a support organization to utilize for project management assistance.

Figure A
The structure of a typical PMO.

The simplicity of a PMO allows virtually anyone to create such an office. A project director/manager, subject matter experts, project managers and a coordinator are roles that need to be considered when staffing the PMO.

What benefits does a PMO provide?
It’s a fact: Poor scope definition and uncontrolled scope changes still rank as the top culprits in project failures. Some organizations need to decide whether they would best benefit from a formal PMO as a functional entity or from a virtual PMO community of practice to support and enable project work. In either case, here are some of the most immediate advantages PMOs offer:

  • They increase project visibility and correspondingly reduced project risk and uncertainty.
  • Change control is ensured over the life of all projects. The PMO ensures that the scope and quality criteria in quantity and definition cannot change without management visibility and trace-ability.
  • PMOs endorsing rigorous gating criteria to move projects from the requirements phase to the development phase may save more than 25 percent in operational costs for cancelled projects.
  • A deliverable-oriented organizational culture enables the creation of smaller quantitative parts of the project scope, each with a unique scope statement and quality criteria.
  • It reduces the time to ramp up on new projects coming into the system.
  • Since many organizations are largely driven by cross-functional teams using borrowed resources, the allocation of resources make things extremely complex. The PMO is a mechanism to assist project managers with this allocation.
  • Reduced risk of project failure.
  • It assembles high-quality, robust, reusable and interoperable work project templates and processes for use on all projects.
  • It highlights critical issues that need to be managed, including those that arise during design, development and implementation.S
  • It disseminates lessons learned from past successes and failures.

Figure B
Every PMO should produce these “now and later” pictures.

The first half of the illustration (See Figure B) focuses on the most immediate critical success factors required in order to launch the PMO. Once established, the focus will be to establish long-term objectives for the PMO within the organization. For those of you thinking that this is difficult, it’s not. It just takes time and some coordination.

Figure C
The basic steps involved with building a PMO.

Keep in mind that a typical PMO is responsible for deploying a consistent project management methodology within an organization (including processes, templates, and best practices) as part of a broad initiative that could cover a number of years. Figure C provides a guideline for building your PMO.

PMOs in action
Today, we find that PMOs have geared themselves to identify and capture projects the day they enter the organization. None of this was possible before PMOs. No more finding out about projects coming through the back door and then scrambling to find a suitable project manager. This means it provides visibility to executives and IT staff, awareness of who is available to manage the project, alignment to the business strategy and prioritizing the project correctly. Your PMO should ask the following entry questions for any new project:

  • How long is the project?
  • What is the effort in terms of resources? (e.g., development, staging, production)
  • What is the priority of this project to the organization? (e.g., ROI, business case)
  • Is the project target date firm or flexible?
  • How much time will be spent on QA/Testing and Documentation purposes?
  • Has an initial budget been allocated to the project?
  • How complex is the technology on the project and are project resources familiar with them?
  • Will this solution interrupt existing business systems when put into production?
  • Will the project solution abide by enterprise standards?
  • Which project manager is best qualified and available to manage this project?

Once these questions have been answered, the PMO manager will then move ahead and allow the project/proposal entry within the PMO and the project process will begin.

So, no matter how you view a PMO, I submit that it is a significant advance in the evolution of project management. I would recommend that you plan to use a PMO to enable project communication between all levels of your organization. Additionally, use the PMO to collect metrics that show how effective the PMO is at delivering savings to the entire organization. If it doesn’t, then it’s of no use really, if you cannot show the organization what value it has provided.

Do you have a PMO?

Is your organization currently using a PMO? If not, are you considering it? What questions would you like Jason to answer about PMOs? Post a question or comment in the discussion board below.