PMOs – Why Might I Need One?
By Bruce Beer, PMP:
Note: This is the third post in a series on PMOs. Read part 1 What is a PMO and What Does It Do or part 2 PMO Business Value and Impact.
In the previous two blogs in this series we looked at what a PMO is, and the business value that they bring to a company. In this blog, I want to look at the considerations that might help you decide whether you need one. After all, they can cost a great deal of money so you should be sure there is a definite requirement.
First, let’s look at a standard project with a PM, several team leads, and various team members. The planning would normally be performed by the PM and team leads with possible input from senior team members or Subject Matter Experts (SMEs), and the plan would include the three basic baselines – scope, time, and cost, considering the other key elements such as risk, quality, resources, and communications, etc.
When the project goes into execution, the PM will normally have a weekly status meeting where he/she would determine the current status of milestones and deliverables (scope), how well this is being performed compared to the schedule (time), all relevant costs (cost) and would probably review risk. During this meeting he/she can implement corrective or preventative actions as necessary.
Now consider a very large project with several sub-projects. During planning there may be a need for a high level view of scope, time, cost, risk, quality, and resources covering all of the sub-projects. The sub-projects may each have a PM, so the overall PM is now managing a team of PMs plus the overall baselines of the project. This is starting to look like a Project Management team!
Now let’s look at a program with several or many projects. This is an expansion of the previous case, and unless the overall Program Manager is careful, it will be easy to lose control and become a statistic for project failures.
The answer for both of the last two cases is probably a PMO, elevating the functions that spread over multiple projects to a PMO team. This team will consider and evaluate the effects of one project on other projects in the program and, where necessary, institute proactive activities as soon as possible.
Other considerations for implementing a PMO include 1) possible resource efficiency improvements across the program and 2) a much improved change management process that evaluates the impacts of changes in one project on all the other projects before deciding to approve or reject that change.
So where is the line drawn between having a Project Manager and a PMO? A PMO can be relatively small, maybe the overall PM plus the individual project PMs, so although it may not be called a “PMO” it could be the embryo of a PMO. The larger the project or program gets, the more likely the PMO is to include:
- A risk manager to review risk of the overall endeavor
- A quality manager to ensure consistent quality goals and “look and feel” across all projects
- A scheduling manager to create the overall schedule, dependencies, milestones, deliverables etc.
- Other specialist personnel
Costs could be collected and reported at the PMO level as could overall status and progress reports, to give management the relevant level of detail they require.
Another major feature of the PMO is the customer interface, whether for internal or external customers. It relieves individual PMs from interfacing with the customer, but probably more importantly, it gives the customer one focal point of contact for the program rather than multiple individual PMs. The customer will be able to have a coordinated view and assessment of the program rather than having to piece together different reports from each project.
In short, there is a grey area between PM and a PMO and it is a subjective judgment as to when one morphs into the other. One big element of the decision whether to have a PMO or not is cost – both the cost of having a PMO and the cost of not having one (potential project/program failure).
Another type of PMO that can be deployed is at the company level rather than project or program level. Several major companies have PMOs not tied to specific projects, but to act as an oversight for all projects and programs being performed by the company. This type of PMO would normally contain senior PMs and might perform project audits at various stages of a project life cycle. They might define and implement project quality measures, tools, techniques, templates, etc. to be used across the company to provide a common “look and feel” for that company’s project deliveries. These senior people could also provide mentoring for the more junior PMs in the company. This type of PMO will be particularly interested in lessons learned from individual projects to provide improving project ability for a company. If a company does not have a methodology, tools, templates, etc. in existence, the PMO could be the entity to develop, train, and implement these standards across the company. The decision of whether a company should have a PMO or not is again a subjective judgment made by senior management and will be subject to financial justification.
Although this blog gives some pointers as to when you might consider having a PMO, it is a highly subjective judgment based on things such as the company’s risk and quality policies, financial justification, and requirement for improvement of project success over time, among other things.
How do you see a PMO benefitting your current project or organization?
Next in this series we will look at how you might establish a PMO.
