By Bruce Beer, PMP:
Note: This is Part 2 in a series on Project Management Offices. Part 1, What is a PMO and What Does it Do? can be found here.
In Part 1 of this series, I outlined what a PMO is and what a PMO can or should do. Now let us turn to the business reasons and incentives for having a PMO. A PMO is often packed with senior and expensive resources so there has to be a good business case for this expenditure.
Not all programs can justify the cost of a PMO. However, consideration has to be given not so much to the cost but to the “value” of a PMO: things like how much does it influence the success of the project, how much money can it save, how much additional cost would there be and could the program objectives be successfully met without one, etc. So let us look at some of the features of a PMO and how this could be cost justified.
At the project level we have three key baselines: scope, cost, and time. It is the Project Manager’s responsibility to establish and then meet those baselines. In a program where there may be multiple related projects, each of those projects will have their own baselines and there may be a Program Manager who is in overall charge. However, the Program Manager has a finite limit regarding the number and complexity of projects in the program that they can manage alone. It will not take long for the Program Manager to start recruiting additional resources to assist in managing various aspects of the program. It also does not take long for this to escalate and morph into a PMO, whether recognized or not.
One thing most projects will do is to evaluate constraint priorities – the flexibility matrix. What is the key “driver” for each project – time, cost, or scope/functionality? If different projects have different priorities there is a high chance that the program will not be totally successful due to conflicting project priorities. If, for example, the program is time driven, the whole program must be complete by a certain date. Unless each individual project understands that time is the key driver and if they focus on one of the other constraints instead, they could cause the program to slip. So enabling a time driven program to coordinate and amalgamate individual project schedules and milestones will enable identification of the program’s critical path, ie which projects are on the critical path. The PMO can then ensure the focus on these projects is to attempt to ensure critical timescales are met. This could provide major benefits to a company in terms of reducing cost of slippage of a time driven program and have a direct impact on the bottom line of the program and the company.
If the program level critical path changes, the PMO should be aware of this and shift their focus to the new critical path projects, so again maximizing the chance of overall success. Missing a time deadline can have serious financial implications for a company, and the reverse is true – meeting contractual or defined deadlines can save or gain additional revenue.
Information and Reporting
Without relevant coordination and management of the constituent projects at the program level, senior management may not be able to obtain a consistent view of the program objectives and status without a lot of digging. Consequently, one of the major functions of a PMO would be to gather information from the constituent projects, combine these disparate objectives, plans, status reports, deliverables etc. into a set of higher level overall program information for easier understanding by management. These reports should indicate developing issues at the earliest time, together with any action required to put a program back on track.
Some tasks that the PMO will undertake at the program level may include overall risk management – assessing how a risk on one project might impact other projects. If a risk starts to happen on one project, the PMO can immediately assess action required on other projects to minimize “knock-on” effects.
Ensure a consistent look and feel for each project under the PMO and provide templates that can be used to ensure the constituent projects look like they are coordinated and are not just a mixture of random projects thrown together. This may not have a tangible bottom line benefit but will improve the final product of the program.
Managing a Program vs. a Company-Wide PMO
All the above considerations were in regard to multiple related projects in a program. Now let us consider a “company” PMO where the PMO is not managing a program of related projects but is there to provide assistance on all projects being undertaken by the company. Many of the benefits detailed above also apply to this scenario, but there are also additional considerations.
Having led a PMO for a major computer company, I can highlight some of the benefits. Before there was a company PMO, all projects were little “islands” of work. The company wide PMO was staffed by several of the most senior PMs in the company and the main roles of the PMO were to:
- Train all PMs in the company methodology – this was compulsory for all PMs.
- Provide a consistent framework to review all potential projects to ensure that any response to an RFP that the company submitted had considered all the relevant areas of the plan, had achievable baselines, and risk was contained.
- Provided the framework for Quality audits or reviews of all major projects in execution to ensure consistent application of the company methodology, in particular financial, time, quality and risk management.
- Provide a formal mechanism for mentoring less experienced PMs.
- Allow for consolidated monthly reporting on all projects to assess any problem areas and attempt to even out risk among all company projects.
- Provide templates and tools that could be used not only throughout the USA projects but also were accessible globally.
- Implement a standard and comprehensive change management process for all US projects.
In conclusion, there are many quantifiable benefits of having a PMO for both a group of related projects in a program or as a company-wide function to improve project management over time in a company. There are also many intangible or “soft” benefits of a PMO such as common standards, methodologies, tools and templates, etc. that will have an eventual impact on the bottom line of a company even if they cannot be quantified at the individual project level.
The next post in this series will look at why you might want a PMO and at what stage you could think about creating one.