PMO – How Do We Establish One?
By Bruce Beer, PMP:
Note: This is the fourth post in a series on PMOs. Read part 1 What is a PMO and What Does It Do?, part 2 PMO Business Value and Impact, or part 3 PMOs – Why Might I Need One?.
In the previous three blogs in this series we looked at what a PMO is, the business value that they bring to a company, and why your company might need one. In this blog I want to look at the steps to consider when actually planning and establishing a PMO – how many people, what functions, ROI etc.
If we reach the conclusion that yes we think we do need a PMO to make our program / company / project portfolio more successful, we need to create it. So as the overall maestro of this potential vehicle to success or failure, you need to sit down to consider how many and what skill types you want in it, and how you actually bring one to life. In the following sections I use the term “program” but it is also valid for larger projects.
Some of the questions you may ask yourself during this consideration are:
- If there are multiple projects in the program, should the individual PMs be part of the PMO or not?
- How well established are your methodology, tools, infrastructure, and previous project history database?
- How technical is the project?
- How inter-related are the projects? Are they mainly independent of each other or highly dependent?
- What is the generic level of risk for the program?
- What is the projected cost of the program (including the PMO)? If it is for an external customer, what is the projected profitability of the program and what is the potential cost of failure of the program to your customer and to your company?
- What is the projected length of the program?
- For an external customer, should customer representatives be included in the PMO?
Before we look into these questions that may affect the size of your PMO, one consideration that I do not think has a major impact on the size of a PMO is whether the program is for an internal or external customer. All programs need to be planned for success whether the customer is internal or external, so the size of the PMO should not be significantly affected.
1. PMs IN OR OUT OF THE PMO
From my own experience I can suggest that as a rule, the cost difference will be negligible because there is little additional time or expense involved if the PMs are established as members of the PMO or not, unless there are traveling expenses involved. On the other hand, having all PMs together to discuss status, progress, issues, risks, etc. will usually have a significant impact on the success of the program because of the level of communication between the PMs which will enable the PMs to be more proactive on their project. So I would suggest that there are substantial benefits to having individual PMs included in the PMO rather than have them hanging around the edges.
2. METHODOLOGY, TOOLS, INFRASTRUCTURE, PROJECT HISTORY DATABASE
If your company does not have a solid methodology, including tools, techniques, and historical project information to review, then it is likely that individual projects will be managed in the way their individual PM does it and are likely to be little islands of work that are unlikely to be well integrated, consistent, solid, or repeatable. They are likely to provide the overall program manager with a great opportunity for failure and a need to polish up their profile. In this situation, a successful outcome will probably involve more people in the PMO just to develop the missing infrastructure, train and support program team members, etc. Having a well established methodology, tools and techniques will not only raise the chance of a successful outcome but will enable your company to add this experience, lessons learned, plans, etc. to a database of completed programs to enable future similar programs to benefit by previous experience. So not having a well established project infrastructure will either lead to increased size of the PMO or a decreased probability of success.
3. TECHNICAL LEVEL OF THE PROJECT
This will impact the number of technical leads and SMEs you may need in the PMO.
4. PROJECTS: HIGHLY DEPENDENT OR MAINLY STAND-ALONE
It is possible to have a program with multiple projects that although they are related, may not be highly interdependent. In this case, the size of the PMO may be significantly smaller. Where there is a highly dependent set of projects in the program, the issues of risk and scheduling in particular are a serious consideration. In this case you may need a PMO scheduling manager who will take each individual project schedule and combine them at the program level to identify dependencies and risks. There may be a need for a PMO risk manager who could assist PMs to be proactive in assessing and managing the risks on their project caused by other projects.
5. COST AND PROFITABILITY OF THE PROGRAM
For both internal and external projects the cost of having a PMO should be compared to the risks and potential costs of not having one. In my experience, for external customers we assessed the optimum size of the PMO and if the customer will not accept the resultant price of the program our management quite rightly stated that we did not want “bad business”. Consequently we would not reduce our quotation unless requirements were de-scoped. If this were not acceptable to the customer, the decision was usually made to not pursue that opportunity as the likely lack of success would erode any anticipated profit.
6. LENGTH OF PROGRAM
This is a factor in considering the size, consistency and skill set of your PMO. Unfortunately people – even PMO members – tend to want to have vacations, be ill, and leave the company. On a long term engagement, allowance must be made for these inconveniences. One obvious way to reduce the impact is to cross train PMO members to allow for short term absences. In addition, they can perform other background tasks such as assisting and mentoring PMs, working on capturing lessons learned, training project team members in the company methodology, etc.
7. CUSTOMER REPRERESENTATIVES: IN THE PMO OR NOT
Having the customer represented on your PMO can have an associated risk depending on the maturity level of the customer. An immature customer who does not realize that all programs have issues can be a disruptive force when things go wrong; they may panic and want to implement short term fixes. The more mature customer will be an asset on the PMO provided they work with the PMO cooperatively, and resultant communication will be greatly enhanced. Ideally there will be no finger pointing when issues arise, just a cooperative approach to resolving them.
There are other questions that you, as Program Manager, may need to consider in planning the size, consistency, and skill level of your PMO, but I think the ones above are the main ones as you build your PMO.
The next and final blog in this series will consider how to integrate PMOs into the organizational culture and how to make PMOs a permanent and valuable asset to your company.
What steps have you taken in planning and establishing a PMO?
