Today we’ll be talking about the PMO. The shorthand stands for Project Management Office, and it is meant to be a department (dedicated or not) that ensures all the organization’s projects are compliant with the organization’s project governance.
Since this sounds pretty abstract - and perhaps quite bureaucratic in the eyes of smaller teams - let’s see what we mean by that. Even after an organization’s or a team’s first project, there will be some lessons to learn. Whether they’re small or big, most organizations or teams want to at least never repeat some basic mistakes they made. For instance, when working with contractors, there should perhaps be a limit beyond which all billable hours should be reviewed or approved. This is not necessarily intuitive until you suffer the consequences.
At some point, the organization will start developing quite a comprehensive set of rules for how the projects should be managed, how resources should be found or paid and when to report on what. Those rules exist, but now two questions are raised.
Does everyone know about them ?
It’s not enough to have rules if nobody knows about them. And this isn’t only relevant for rules, it’s relevant for lessons as well. Perhaps for physical projects, most parts should be supplied from a pre approved supplier that offers amazing discounts based on the history between the two organizations. In that case, if the project manager doesn’t know about the discounts, they may waste significant portions of their budget. What’s worse, that budget was probably approved with this supplier in mind.
Are they applied as they should be ?
Even if the project team knows the rules, that is no guarantee they will also be applied to the fullest. Sometimes such rules impose additional work in the form of approvals or reports, and that is not exactly the most fun part of the job. Other times, the rules are written in a way that is open to interpretation. This is meant to give project managers and their teams some space to maneuver, but sometimes that doesn’t achieve the desired results.
So what’s the PMO’s role, again ?
Since we now know the two largest issues with project governance (which means “what should be done as part of a project”), let’s see how a PMO can help solve them. Not all PMOs are created equal, in the sense that there are different approaches to make sure a project is compliant with the organization’ rules. You have to remember a very important thing: a PMO does not exist to help the project deliver what was proposed in the Project Proposal or promised in the Business Case. Instead, the PMO answers to the organization’s upper management, and it exists to enforce whatever rules and guides the organization’s management has for the activities regarding project management.
As such, let’s take a look at a hypothetical situation. The project manager finds a way to obtain a cheaper part from a different supplier, but this means going around the pre approved supplier list. The project manager is blocked by the PMO, since all parts must be procured from the appropriate supplier. In this case, the interest of the PMO is conflicting with the interest of the project manager, but the PMO is right to enforce the organization rules regarding procurement, even if it means the project manager feels like they were hampered by it. A common solution for this kind of problem is to leave the project manager some room to maneuver, in the sense that, for instance, for all parts under a specific price, the project manager may exploit procurement opportunities, but starting from a certain price, they must use the pre approved supplier.
Before talking about the different types of PMOs, it should be noted that it is the project manager’s responsibility to seek out and implement whatever rules the organization has regarding projects. This applies even if they are informal - the project manager should try to learn as many lessons as possible from the other project managers or colleagues that have relevant knowledge for the current project.
The supportive PMO
This type of PMO is an interface between project managers and whatever policies, methodologies, templates and lessons about previous projects the organization has. This can be a person or a team that all project managers know to contact whenever a project is initiated, so that they receive the sum of all the organization’s knowledge regarding project governance.
The PMO will provide answers to the project manager, along with checklists and perhaps templates for the most common project management artifacts. This way, the project manager doesn’t have to reinvent the wheel for all the documents, reports or presentations, but instead use the templates expected within the organization.
As this type of PMO is meant to assist, it is expected to have a very low level of control over any project. This is (or should be) by design, in order to give the project managers more control over their projects, while also having a baseline for situations that are completely normal.
The controlling PMO
This type of PMO is a bit more hands-on than the supportive one. It not only offers support, but also a bit of guidance. This guidance takes the form of suggestions, best practices, or other actionable info that the project manager can use in their project.
This type of PMO is also enabled to train project managers and the project teams in the use of various software tools and different tools that could be used in projects (such as spreadsheets or versioned documents). Because of this approach, the project managers no longer have full autonomy, instead they are helped and shaped by the PMO in a tighter relationship than the one with a supportive PMO.
At the same time, because the controlling PMO is enabled to transfer information from the organization to the project managers and teams, they are also responsible to measure whether the project is compliant with the very guides the PMO teaches. This means that the controlling type of PMO will have a moderate level of control over projects - they can’t tell the project manager what to do, but they can tell them how to do it.
The directive PMO
The final type of PMO is also the strictest one. This is because in this form, there is no separation between the PMO and the project managers. Instead, the project managers are part of the PMO, and they are assumed to know, apply and expand the organizational knowledge related to projects.
In this case, there is no exchange between project managers and other employees because the project managers will have to adhere to some stricter standards themselves. This type of PMO has a very high level of control over projects - not as an external influence, but from within because the project managers themselves are “guaranteed” to know and apply all the rules.
Examples of PMO activities
A PMO could manage the interactions between various projects, or between projects and programs or portfolios. This means that if there are synergies to be found between an organization’s various efforts, the PMO could help identify and manage them.
A PMO could measure the results of projects, programs and portfolios and compare those results with the initial roadmap. This way, project managers are not burdened with this type of effort, since it doesn’t really pertain to their project(s).
A PMO could assist the project manager in determining whether a project should be terminated, either because it is not performing well enough with regards to the organization’s goals, or because, for instance, it failed to stay compliant with the Business Case.
A PMO could work with the project manager and the team to identify valuable new knowledge and lessons that were uncovered, in order to make them available to other project managers and teams. This is a very valuable activity and the foundation of what a PMO can do for the organization.
A PMO could assist the organization to analyze and prioritize project proposals, using financial indicators and verifying that those indicators remain valid for the duration of the project. This means that the PMO could have a very important role before a project even exists, and its influence could taper down in a manner that is proportional with the project manager starting to handle more and more of the project.
Conclusion
The PMO does not necessarily have to be a huge team, or even a whole team for that matter. Think of it as a set of roles and responsibilities that can be worn as a hat by various persons in the organization. In the case of the controlling PMO, this hat is worn by all project managers. In other types of PMOs however, the hat (role) could be worn by a senior project manager assisting the others. In the end, it’s not important how the PMO is implemented, what’s important is that there is someone (or multiple persons) with this role in the organization.
