I have worked as a PMO and under a PMO. You hear the term often, and I have been starting to see it more and more in job descriptions and in meetings. PMO stands for Project Management Office, but there has been some misunderstanding regarding what this group does.
It really focuses on Project Governance. This is the process that standardizes the project-related governance processes and facilitates the sharing of resources, methodologies, tools, and techniques. For those of you who are familiar with agile, you may have heard of the “Scrum of Scrums.” This is a series of meetings where the Scrum Masters of different sprints get together to ensure that that agile project is staying focused and if there are any potential conflicts. They can also see if there are resource allocation changes, or ways that one team can assist another. When it works, it is a great system.
The PMO can be seen as a “Project of Projects.” It is where an individual (or team) overseas the management of sponsors, stake holders, and other issues related to governance. This group oversees the individual project managers (who should be meeting regularly to review projects). In a PMO, however, the projects may not be as closely related as they are in the scrum of scrums. However, I have been in very many PMO meetings where another project manager has learned a great deal from updates on a project that was seemingly unrelated to the project they were managing. There is always some organizational overlap.
It really comes down to corporate culture. If your organization is leans heavily to “functional,” there may be some difficulty in setting up a PMO. By functional I mean:
- Project Manager has little authority
- Limited Resource availability to projects
- The project budget is managed by a functional manager (not PMO)
- The project manager is most likely a part-time role
- The project management administrative staff is also part time
Some may see the PMO as a road block to responsiveness, but it doesn’t have to be. I have worked with PMO’s that were very effective on clearing the way for their teams, and allowing the PM’s to learn from the best practices of other PM’s.
The downside is that there is a risk of creating standardization and rules when none are necessary. Standards should help with the flow and make things easier, not restrict a project’s potential. If standardization does not improve quality, communication, cost etc, it shouldn’t be a standard. If the only reason for doing a project a specific way (per standards) is that everyone does things the same way, there will be problems. You don’t want to introduce standards created to solve problems that don’t exist.
The best PMO I ever worked with was a stickler about reporting (you had to give her the project updates in a standard format), but each project manager was able to manage in their own style. That is the model that I tend to follow when I have worked as part of the PMO.