How can my Company use a PMO?
An important development in recent years is that Project Management has become legitimized as an understood business practice for businesses and organizations that need continuous, active, repeatable management of effort. The Project Management Office (PMO) is an entity to support Project Management with oversight and process development. But the PMO can risk being swayed by the business to serve specific audiences instead of the overall business itself. This can undermine or contort the mission of the PMO.
Seeking a definition of a PMO is a relatively easy thing to do. I was more or less satisfied at this definition from the pmpedia. But what has disturbed me about PMOs is that they tend to have one specific weighty “customer” or owner who slants the focus of the PMO against other activities or customers. Obviously my bias is towards a PMO that should be balanced in its focus.
So let’s think about who are the customers of a PMO in a decent-sized Enterprise organization.
The Project Managers and their Projects: Sure, this is an easy one. The PMs need the benefit of supported, reusable tools and processes (as endorsed by the organization) to execute the projects to meet their Customers’ goals. This is probably the easiest PMO customer to identify. PMs need the PMO to fly cover for them should a situation become difficult to manage. PMs also need the PMO to support the PMO tools and to have the PMO coach and guide on allowable shortcuts or exceptions to the standard processes.
The Gatekeepers and Key Business Stakeholders: It may be less intuitive, but the PMO should be available to the project Gatekeepers and Key Business Stakeholders should the normal channels through the PM not be appropriate for escalation of concerns. I would regard it as a very bad sign if the Gatekeeper or a Stakeholder were positioning questions of concern over process, but a question of an individual PMs capabilities or other constructive criticism should have an advertised channel into the PMO.
New PMs and Process Adopters: Obviously as a PMO grows is reputation in an Enterprise, there should/will be inquiries from teams who would be new adopters of the PMO’s toolkit. This would be akin to a business development activity, and could be as much an outreach activity and it would be receiving inquiries. Nonetheless, the PMO should enable itself to be a growth engine for influencing the entire organization to use standardized PM concepts where possible.
Portfolio Managers: Here’s where I believe the PMO begins to get swayed by business factors. Organizations of scale will be required to implement portfolio management across segment, functional or application lines in order to make portfolios of manageable scope for budgetary, resource, and strategic planning. That’s as it should be, of course. The problem seems to arise when the PMO becomes over-focussed on assisting the Portfolio Managers with meeting their obligations for budgetary information (such as forecasts, actuals, accruals, probabilities, etc). The PMO runs a real risk of undermining their role as “process champions” by being enjoined with the Portfolio Managers as “budget harpies”. The PMO needs to assure that their toolkit meets the information needs of the Portfolio Managers. The PMO also needs to provide the appropriate level of separation between the Portfolio Management process and the Project Management process. They are inexorably intertwined, but one must not trump the other in importance or bias of allocated energy.
Management Reporting: A key benefit from standardized tools and information is that it should be far easier for consolidated Management Information (MI) reporting to be prepared for upper-level management as to the overall efficacy of the project management activities - and portfolios as well. The PMO must continually bridge the environments between the Management Information that is being requested and that which can be provided. The PMO must set expectations with the Management team and must manage the toolkit and standards for the PMs so that the desired information is obtained.
A key risk in the production of Management Information is when the Management and the Portfolio teams hold too much influence and begin to request (and then require) information that is not constructive for the Project Team to collect or manage - at least not within the context of the project. This creates a disconnect between the project management needs and the data required from the PMO process. Frequently the PMO will take the position “Management wants it” in response to challenges over the production of such fluff. It’s vital for the PMO to recognize when such challenges are not just complaints about “more work” but are really legitimate questions about “why are we doing this”. It’s a fine line to discriminate between the two perspectives sometimes, but a smart PMO will be a champion for it’s PMs working context as well as serving the needs of the MI scope.
Again, without balance for MI, either the PMs feel marginalized and overworked to produce information they don’t need, or the MI customers feel that the PMO isn’t producing valuable output and may question the overall value of the PMO. Since the PMO are often paid or incented by the MI customers, it’s often a balance that tilts away from the project managers. Watch out for staff turnover at the PM and project analyst level when this balance is too lopsided!
A few words about PMO behaviors:
- A PMO cannot be in “tell mode” - advocating standards, mandating things - all of the time. The PMO needs to spend time soliciting comment, opening up new avenues of discussion, and taking constructive criticism of itself from all Customers it serves.
- A PMO must support continued personal development of the PMs under its pervue. With required personal development needs to maintain certifications such as PMP, it is strategic for a PMO to provide regular, beneficial training and topic-based sessions to allow the PMs to step away from the projects to discuss new ground and expand beyond their daily grind.
- The PMO must respond in a timely fashion to all feedback. A PMO undermines its own value if it does well at collecting feedback to make improvements and then does little outward work to deliver on such feedback.
- The organization must be clear where the role of the PMO stops and the role of the business begins in terms of actual HR-style activities of evaluating performance of the PMs. If the PMs work directly for the PMO, then staff inside the PMO need to be in position to create the appropriate line management reporting chain. If the PMs work for a business entity, then the PMO and the business need to be clear what information the business will want for periodic evaluation of the PM’s career achievements.
In conclusion, the PMO should be regarded as an investment by an organization who wishes to bring project management processes together, who wishes to commit to continued maturity in their project and portfolio management, and who wishes to ensure that the myrid of customer interests are served in a balanced fashion.
Comments welcome for this post! Thanks! Spammy stuff will be purged.
Comment by David Richardson — January 11, 2007 @ 3:22 pm