I was not at all surprised to find several varied opinions about how to make a PMO successful, but what was most interesting was the wide range of ideas over what constitutes a PMO and what its purpose should be. If you’ve read my column before, you know that my focus in the industry is on project management systems, but imagine the challenge for someone in my area if it is that difficult even to define a PMO. Let’s take a look at a couple of different perspectives of what a PMO could be:
It’s the rarest of all PMOs. In this scenario, the PMO has ultimate authority over every project manager. The project managers report directly to the PMO. We see this most often in a mega project environment where the entire organization has been created, in fact, to accomplish a particular project. It can also happen in Defense and Aerospace projects where the government has imposed project management standards, which define how the organization must manage. In this environment we’re more likely to find a small, centralized project management office staffed by highly skilled full-time project scheduler and project cost analyst personnel.
The tools that are chosen for this situation are heavy on the analytics and light on user-friendliness. Compliance and collaboration are not the first concerns here. What’s more important is that we can do strong forecasting, strong project accounting, and that we’re able to have sufficient flexibility to integrate directly into the organization’s ERP and corporate reporting systems. We focus more here on government or contract compliance, so we’re more likely to find things like requirements for Monte Carlo risk analysis and Earned-Value standards for cost analysis.
(No, not the couch – that’s where PMO staff end up after a long day!). Perhaps the most common PMO role today is that of mentor or coach. They’re not there to impose their authority on a project or on the project manager but, rather, to be there to guide the Project Manager, to offer assistance if needed, and to provide tools and resources to help the project get out of trouble.
In this case, the PMO is more likely to be a small, highly skilled group and extremely unlikely to be hosting a strong centralized enterprise project management or enterprise portfolio management system. They’re more likely to offer tools that each individual project manager can use, and to facilitate training exercises and the delivery of easy-to-implement templates. There’s not much room here to police the projects under the coach, so the role is supportive rather than prescriptive.
If it’s all about supporting others, the ability to disseminate information is more important than our ability to collect it. So, we look for tools that are strong on document management, strong on communications and light on centralized analysis.
Many PMOs are set up like the Defense Early Warning (DEW) System of cold-war fame. The purpose of the office is to identify potential problems within projects and to report back on this to management. Scout PMOs don’t have much authority but often they are much more than reporters. After all, if they can identify the problems early on, why not try to tackle them up front. It’s not unusual to find a desire for an enterprise project management system here, but deploying one can be a challenge. The Scout PMO is often empowered from the highest levels of management, and that’s a good thing if you’re trying to deploy an EPM system. However they’re often viewed with suspicion by the project managers themselves, and that’s an awful thing if you’re looking for the cooperation you need to get an EPM system used by everyone.
Systems for a Scout PMO will be strong on data collection, strong on reporting, and a little lighter on heavy analysis. Assembling information from numerous disparate sources into a single view for management is almost impossible, so the Scout PMO will lobby heavily for data collection and tool standards, as well as some semblance of standards for projects, such as coding for stage gating phases and project durations.
While it’s not yet the most numerous, certainly one of the most desired types of PMOs anywhere is that of the Facilitator. This kind of PMO doesn’t have authority over the rest of the project managers, yet it doesn’t have a passive role either. The PMO’s role is to facilitate the execution of the projects under its purview. This means that the role includes that of the Coach and the Scout. It’s often said that a facilitator has the toughest role in a negotiation. They are held responsible for the result but carry no authority to generate it and that, indeed, is how it works in this environment also.
The Facilitator PMO will have the backing of senior management but will be a dotted line on the organigram. Without authority, they will resort to cajoling, threatening, inspiring, evangelizing and pleading in order to produce the result, and it’s often very successful.
This PMO is characterized by a small cadre of highly trained and highly charismatic personnel. We’re most likely to find a successful Enterprise Project Management system implemented with this kind of PMO. Communication and collaboration are very significant desirables in this scenario, and that is often a key to making an EPM system work. Also, centralized information is essential to the Facilitator’s being able to identify areas in which project managers, team leads and management must collaborate. So getting all project data into one place is going to be an essential part of making the Facilitator PMO successful.
There are other kinds of Project Management Offices, so if I’ve not mentioned yours or if yours is a hybrid of the couple I’ve described, don’t fret. The point is that before you head off to choose project management software ideal to your PMO, or before you start to implement the project management software you’ve got, it’s worthwhile to think about what role you’re trying to fulfill. None of the definitions I’ve listed are the “best”. They’re all specific to what an organization is trying to accomplish and the particular business challenges they are facing at that time. In fact, it’s not unusual to see the role of a PMO change over time as the organization it serves changes.
Most high-end enterprise project management packages these days have so much flexibility that they can be deployed in many different ways. You can focus on so many different aspects of these systems that they can easily support many different PMO scenarios. So, think about your PMO scenario before leaping directly to installation and training of the system you’ve chosen.
Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal's McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI's PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University's Executive Institute. He can be reached at firstname.lastname@example.org.