Choosing the right PMO setup
by William Casey and Wendi Peck
Any company investing in the PMO strategy must understand that different kinds of PMOs solve different problems—there is no one-size-fits-all solution.
AS ORGANIZATIONS WRESTLE with change, a favorite silver bullet is the program management office (PMO). The phrase itself has a reassuring sense of sanity, order, and control. Unfortunately, the meaning of “PMO” gets a bit murky after that. In fact, “PMO” means vastly different things to different people with only this as their common thread: “Something that's going to fix our project management mess.” Yes, there are various PMO solutions that will cure various project management ills. But simply to prescribe the “PMO solution” would be like a physician telling you to go get some medicine without specifying what kind. Different kinds of PMOs solve different kinds of problems.
We won't spend time on the PMO that is simply the office of a program manager: someone who is accountable for pulling together several related projects into a single strategic initiative. That configuration is just a matter of cascading accountabilities and authorities. For the most part, it operates (or should operate) like any line organization. We will describe those various PMOs and the problems they solve.
There are three other varieties of PMO, each of which may be used either independently or in combination within a single entity.
William Casey, Ph.D., and Wendi Peck are principals in Executive Leadership Group Inc., a Colorado-based company that provides training and consultation to help companies implement their strategies. Executive Leadership Group Inc.combines skills in organizational design, project management, and change management to produce TransFormance™: organizational transformation with no transitional loss of performance. Contributions on this article are gratefully acknowledged, especially to Claudia Baca, Lona Cram, and Cindy Muir, plus the students of our “Building Project-Capable Organizations” class.
PMO No. 1: Weather Station
The Problem. Sometimes executives get nervous about all the money they're spending on projects without their really knowing what's happening. They get confused by different reporting formats coming from different project managers with different varieties of jargon, plus the sheer number of activities going on at once. To end their confusion, they set up a “Weather Station.”
The Solution. Like a real weather station, this PMO tracks and reports events without directly influencing them. This means communicating various aspects of project progress to executives and anyone else having a need to know (for example, the project managers of interdependent projects).
Basic Functions. Weather Stations answer these questions about the projects in their purview:
What's our progress? This reporting will probably be done at the level of milestones, not tasks (though projects in trouble tend to be microscrutinized).
How much have we paid so far? How much have we budgeted for this point in time?
How much have we paid for our current progress? How much did we budget for this level of progress?
What are the current major risks and issues?
Additional Functions. More robust Weather Stations may perform such chores as:
Maintaining a database of action items, project history documents and lessons learned
Reporting (without dictating) accountability and authority structure
Reporting (without dictating) Measures of Performance (MOP)
Tracking post-project achievement of promised MOPs (that is, business results).
Authorities. Although the Weather Station's functions sound minor, almost clerical, they require that the Weather Station set the frequency, format, method of delivery, and associated tools for reporting and planning. (Remember that “actuals” must be compared to “plans.”)
If the Weather Station does not have enough clout to ensure cooperation with its functions, then it will resort to “nag authority,” making it inefficient, embittered, and disliked. This situation is an example of the classic illegitimate assignment: accountability without authority, which can turn mild-mannered employees into people you don't want to know. So, either give the Weather Station a piece of each project manager's performance appraisal (possibly through a customized report card that feeds the appraisal), or, when the Weather Station tattles on foot-draggers, action had better be swift and sure.
Another alternative to the tattling trap is not to hold Weather Station managers accountable for actually obtaining progress data. Instead, hold them accountable only for requesting progress data … and properly relaying data received, plus reporting on who didn't turn in their data. That way, the problem of enforcement lands squarely in the laps of the project managers and their bosses, not the person running the Weather Station.
Pitfall Alert: Don't expect too much. If you are an executive who employs the Weather Station, or if you are the person running it, please don't be tempted to use this type of PMO to fix screwed-up projects. The Weather Station is not authorized to tell project managers and their clients how to do things. If you want your Weather Station to perform that duty, you will have to replace or add to its functions (and authorities). If you want your PMO to fix projects, consider the function described under PMO No. 2.
Another Pitfall Alert: We commonly see the problem of Weather Station managers not being given enough authority. But we've also seen the less frequent mistake of according the Weather Station manager too much authority: input on project managers’ appraisals for how well they performed on the project. Because this judgment has nothing to do with the function of a Weather Station, it serves only to confuse and annoy.
PMO No. 2: Control Tower
The Problem. The project management function for many organizations is a vital asset. But, vital asset or not, some organizations completely fail to manage it as an asset. A few symptoms:
Training—which may be copious—is neither applied nor supported.
Expensive and voluminous “methodologies,” ransomed from hotshot consultants, do little more than strain sturdy bookshelves.
Executives with little project management savvy oversee project managers.
Lessons learned on one project are not applied to other projects.
Project managers use whatever methods and tools fit their whims, and change them like underwear.
Management rewards heroics while ignoring or penalizing quiet competence.
You get the picture. Those organizations obviously cannot improve their delivery of projects, no matter how much consultation and training they throw at the problem.
The Solution. How do you start treating project management as an asset? Consider using a PMO called the “Control Tower”—a term coined by project management consultant Jan Renerts. The Control Tower treats project management as a business process to be protected and nurtured. Following W. Edwards Deming's classic dictate to reduce variability, the Control Tower makes possible improvement in the project management process.
In our view, Control Tower functions should be combined with those of the Weather Station; there is no need to set up separate entities for these functions.
Exhibit 1. A single PMO may perform various combinations of PMO functions, depending on the circumstance. Here is one workable approach.
Basic Functions. In practice, the Control Tower PMO performs four general functions: establishes standards for managing projects; consults on how to follow those standards; enforces the standards; and improves the standards.
1. Establishes Standards for Managing Projects. You have got to have basic standards for managing projects, and the PMO might as well author them. Typical topics addressed by such standards include:
Risk management—template, frequency, method of delivery
Project configuration—who reports to whom must make sense from a role and authority standpoint
Communication/escalation standards— when/how to inform whom
Lessons learned—processes for gathering, documenting, and applying across the organization
The standards—tools and processes— will need to scale up or down to accommodate different size projects.
Pitfall Alert: You let some people start writing standards and they just never stop. Either get them jobs in Washington or manage them closely. This is a place for the 80/20 rule: 80 percent of the good to be done will come from 20 percent of the rules you can think up. Stop there and hope for intelligence and routine management to carry you the rest of the way.
In preference to detailed standards, one of our colleagues employs a technique she calls “Expectations of Project Managers.” She gives the project manager a document that spells out the point of each standard she would have written. Then she asks the project manager to address each point. For example, under “Scope” she might ask the project manager to describe the project's scope, how it was determined, what is included and excluded, how scope changes will be managed. In this way, she leads project managers to cover all the bases, while letting them do it in their own style. Templates are provided to those who want them.
2. Consults on How to Follow Those Standards. If project managers are required to meet a set of standards, then they need to understand those standards. Internal consultants working for a Control Tower manager can help ensure that standards are successfully communicated and understood. Consider using one-on-one consulting, small orientation sessions, and classes on “how to audit yourself.”
These internal consultants can also serve as the conduit of lessons learned from project to project, thus ensuring better organizational absorption of new ideas and information. These new ideas and information may also call for occasional revision of the standards.
3. Enforces the Standards. An intrinsic element of accountability is performance consequences. Without this element the whole program office will be treated as a bureaucratic nuisance—or, worse, a joke. Of course, performance consequences are not possible without performance auditing.
If you do plan to deliver performance consequences, consider these possibilities among others that you will surely think of. For the carrot, use hefty bonuses to the project and program managers for meeting milestones and following standards. For the stick, remove the nonperforming project manager from the project, thus removing the possibility of the hefty bonuses.
Pitfall Alert: The philosophy of “build it and they will come” does not work here. You might think that project managers would naturally seek out standard, proven processes, and that they would embrace the internal consultant who aims to install those standards. Well, forget it. This is a cross-functional entity that must have its authorities. Minimally, the Control Tower must control a piece of each project manager's performance appraisal. Ideally, it would also be able to remove project managers from projects. These authorities are necessary if the Control Tower is to ensure the quality of project management practices within its scope. And that is the point, isn't it?
Another Pitfall Alert: Unless budget constraints demand otherwise, the person from the Control Tower who audits a project should not also consult on the project. This will help ensure greater client cooperation with the internal consultant, as the client is likelier to disclose discomfiting information to someone who is not holding a stick. It will also help ensure better objectivity on the part of the auditor, who has not had a chance to develop a chummy relationship with the client. Another point: preferring to avoid confrontation, consultants who are asked to audit will often procrastinate on audits, performing far fewer than are needed.
4. Improves the Standards. Once standards have been documented and are reliably followed, it becomes possible to improve the standards. Each project makes the organization smarter. “Lessons learned” are actually learned—and incorporated into new standards. But resist mightily the temptation to start amassing a vast tome.
After exposing executives to the differences between PMOs, their inevitable question is, “So, what's the right one?”
PMO No. 3: Resource Pool
The Problem. Often, the person who hires and manages project managers knows less about project management than they do. Therefore, the asset of project management talent tends not to be managed as an asset: it isn't expertly selected, improved, and retained.
The Solution. Organizations that rely on projects to do business cannot afford inattention to this key capability. Set up a “Resource Pool” for project managers. Managers and executives needing projects then “hire” a project manager from this repository of expertise. It makes logical sense to combine the Resource Pool with the two earlier PMOs.
Basic Functions. With a Resource Pool properly in place, executives may reasonably expect:
A pool of skilled project managers from which to draw
Project managers skilled at managing the type of projects to which they are assigned
Project managers supervised to ensure that they properly apply their skills.
The function of the Resource Pool does not include interfering in the organization's project selection process or determination of project outputs. However, if a project's sponsor insisted on not properly defining the project's output (or otherwise circumventing basic principles of project management), then the pool manager would certainly intervene. The function of the Resource Pool is to ensure that projects are done correctly, not that the correct projects are done.
Authorities. The Resource Pool is another of those structures in which “build it and they will come” doesn't apply. Executive leadership must agree on some basic ground rules to leverage this important advantage effectively. Among them:
1. The Resource Pool Manager is in Charge of Supplying Project Managers to Projects. The pool manager must be the only source from which project managers are assigned. Obviously, the idea is to ensure a uniformly high level of expertise and to follow organizational standards. Therefore, executives should not be allowed to hire project managers outside the Resource Pool (at least, not without some sort of review to ensure adherence to the intent, if not the letter, of the law,).
2. The Pool Manager is Granted Ordinary Managerial Authorities with Respect to Pool Employees. What ensures the expertise of these project managers? The fact that the pool manager is a black-belt project manager whose authorities, which are also accountabilities, include:
Hiring only expert project managers
Supervising them to ensure that they use their skills
Coaching them to help them upgrade their effectiveness
Arranging for their career development, such as certification from the Project Management Institute, attendance at and contribution to conferences, and so on
Removing project managers who do not prove their mettle.
The pool manager should also help remove organizational barriers to the practice of good project management, working to persuade and educate executives and internal clients. But don't make the mistake of holding them accountable for persuading people over whom they have no authority.
The Internal Business Arrangement. In smaller organizations, members of the pool may serve only one internal client, such as the president. But in larger organizations, the Resource Pool will have several, perhaps many, internal clients. In these cases, the internal business arrangement must be worked out in advance. Some questions to resolve:
Will assignment of project managers be strictly up to the pool manager, or will it be a negotiated process?
Will the internal client pay for the project manager? If so, on what basis: hours, days, or by the project?
Is the relationship between the project manager and client one of subordinate and manager, or one of supplier and customer? (This question is answered primarily by the degree to which the client directly controls the project manager's performance consequences—more control starts to lean toward a managerial relationship, in which case accountabilities to the client vs. those to the pool manager must be distinct and different.)
Conclusions, Decisions, Suggestions
The chief tool of strategy implementation is the project. That makes project and program management a key organizational asset. Executives wishing to hone and nurture that asset will implement some form of PMO. However, beyond the decision simply to have a PMO, decisions remain.
What's the Right One? After exposing executives to the differences between PMOs, their inevitable question is, “So, what's the right one?” It's a good question, but a little like asking, “Which is better, bacon or eggs?” Because each of the PMO types represents a major function, you can have any one or a combination of functions, depending entirely on your needs.
We believe that the Weather Station may function independently or be nested within the Control Tower. If the Weather Station were nested inside the Control tower, then the PMO would report on project progress and ensure that project processes met standards. Likewise, the Control Tower (plus Weather Station) may function independently or be nested within the Resource Pool. If the latter case were true then the PMO would report on project progress, ensure that project processes met standards, and manage the pool of project management talent.
Scope of the PMO. Some “projects” are really no more than tasks. On such projects, the machinery of the PMO may not add substantial value. Thus you may want to confine the reach of the PMO to projects above a certain size or perhaps projects that extend across functional boundaries.
You can also apply the PMO's functions based on the size and scope of the project. With one client, we have recommended PMO deployment based on size and scope of the project. Exhibit 1 illustrates.
In Exhibit 1, a full-functioned PMO would perform all three major functions on cross-functional projects. On large, single-function projects, the functional area conducting the project would supply the project manager yet would be subject to the quality enforcement and reporting of the PMO. On medium projects, the functional area would supply the project manager and would only be subject to reporting requirements.
Of course, this is only an example. Any PMO deployment strategy would be subject to the needs and abilities of the organization in which the PMO resides.
Strategic Oversight and PMO Success
The success of any PMO will largely depend on oversight and involvement at the executive levels of the organization.
Portfolio Management. Ensuring that projects get done correctly—the realm of the PMO—is a different matter than ensuring that the correct projects get done. PMOs do poorly at ensuring that corporate funds are spent in the very best way to advance the strategy of the organization. It is not even the PMOs’ job to prevent conflicts and overlaps between project outcomes. In short, PMOs do not make strategic decisions about what projects to do and when to do them. That job belongs to the portfolio manager.
In small organizations, one person, say a COO or CEO, will perform that function. In larger organizations, numerous people need to be involved in a more formal way—sometimes called the “governance process.” However, the ultimate decision (and accountability) must still rest with a single person.
Executive Project Sponsorship. If you've ever seen a great actor in a terrible movie then you know that the person on center stage doesn't entirely control the outcome of a project. The practice of good program management does not rest solely on the shoulders of project managers and PMOs. PMOs can only broach so many of the potential obstacles to good program management. Those obstacles must be removed at a higher level. This is the accountability of management, often including the CEO and other senior executives.
Has the business result of a project or program been adequately defined?
Do the program and project managers have ordinary managerial authorities— hire, fire, assign, reward—with respect to their key team members? (This sounds trivial, but it is a major policy decision in many organizations.)
Does the organization tolerate time spent planning projects? (We agree, though, that planning time must now be briefer than ever—but not nonexistent, as some managers seem to prefer.)
Is money available for the purchase of an adequate project planning and reporting system?
Has a project's sponsor been narrowed down to one person; in the right part of the organization; at the right level—neither too high nor, more commonly, too low?
Will the sponsor's career be affected by the outcome of the project?
SO, WILL A PROJECT management office fix your project management woes”? Will it achieve what you want it to achieve? Understanding the various kinds of PMOs will help you to decide whether one, a combination, or none may be right for you. ■
PM Network February 2001