Understanding the project management office

PMO—Project Management Office…. Why does everybody think they need one, and what should a PMO really do?

Henry, an experienced project manager, was asked to set up a PMO when the IT department took on a huge, politically visible, enterprisewide project. He was well qualified, with both PMI certification and a track record of successes.

The CIO also wanted Henry to establish common project reporting, a dashboard that tracked how everybody’s projects were going.

The need for good project management wasn’t limited to the one big enterprisewide project. Henry soon found his tiny staff swamped with additional work, which he took as a sign of the value of his group. But trouble wasn’t far behind. It seemed there were never enough project managers in the PMO to go around. While Henry’s staff handled a few big projects, many other projects ran adrift. The proposition of growing the PMO to manage all projects was neither affordable nor politically acceptable.

Meanwhile, relations between Henry and his peers became strained. The other senior managers in IT resented Henry when hot strategic projects were taken away from them and given to him. They resented his control over their resources. They resented his looking over their shoulder, judging their progress and reporting on them to their boss. And they were offended by the implication that Henry was somehow more competent than them.

On a technical side, this PMO didn’t work well either. Henry’s projects didn’t fit the technicafl directions established by the other senior managers. And when his solutions went into production, the other groups were not prepared to support them.

Excellence in project management is essential, but PMOs can do as much harm as good. Let’s examine the fundamentals and scope a proper role for a PMO.

Definitions

First, we need to define a few terms:

Project management is a task people do in order to deliver projects (results). It involves a discipline and a set of methods and tools for planning and controlling project resources. It’s a means, not an end in itself.

A project manager is the person accountable for results. Project managers are responsible for delivering products to customers; and to do so, they manage projects.

A project-management expert is a person trained in the techniques and tools of project management. Generally, people cannot be world-class at two different professions at once. A project-management expert is someone who has chosen to study a discipline that applies to any and all projects—to any and all technologies—rather than someone who has spent his/her career studying a particular domain of technology.

I’ll use the word technologist for the person who has dedicated his/her career to mastering a domain of technology, be it applications, computing platforms, networks or end-user computing tools. These IT engineers are qualified to design, build, repair and support complex technology-based solutions.

Troubles When PMOs Manage Projects

Applying these definitions, a project management office comprises people who are project-management experts. The rest of the IT organization comprises technologists (as well as other specialists like service providers).

Henry’s troubles arose when his staff were appointed as project managers. In truth, what this meant was that Henry became accountable for delivering products that were in other managers’ domains. There were two major problems with this:

1. Competition and disempowerment: When Henry took on responsibility for delivering projects, he was in competition with his peers. Either the other managers could sell their products, or Henry could sell their products (using their resources). Of course, when Henry got the glory for the hot enterprise projects, competitive feelings flared.

Beyond this, the other managers were no longer in full control of their “businesses within a business.” They supplied warm bodies to Henry, but they couldn’t really manage their product lines. Indeed, it would be unfair and ineffective to hold the other managers accountable for running a line of business within IT, since they didn’t have full authority over that line of business. They were disempowered. (See “The Golden Rule” on empowerment.) The results of this disempowerment were insidious. The other managers no longer felt like entrepreneurs running a business. Instead, they began to see their jobs as managing a resource pool. As a result, they lost interest in their competitiveness, their strategies and growth opportunities. Creative ideas were lost, and staff were demoralized.

Furthermore, the rest of the organization’s ability to deliver the myriad smaller projects that weren’t transferred to Henry’s PMO deteriorated. And IT staff certainly weren’t prepared (or motivated) to support the solutions Henry produced.

2. Technical incompetence: Despite the warm bodies with technical expertise drafted onto his teams, Henry’s project managers were not technically qualified to lead high-tech projects. Sure, they knew how to manage projects; and PMI had told them that they were qualified to manage any project, with or without knowledge of the content of the project.

But in fact, project managers have to make many key decisions about the design and delivery of complex technologies. Of course Henry’s project managers solicited input from the technologists on their teams. But they still made the final judgment calls, and they weren’t technically competent to do so. All their beautiful PERT charts and dashboards weren’t a substitute for the depth of knowledge of a trained IT engineer.

This resulted in solutions that may have been delivered on time and on budget, but didn’t fit the technical architecture, weren’t in keeping with other managers’ technology strategies and were difficult to support.

The Proper Role of PMOs

The proper role of a PMO is to help everybody become a good project manager—not to be a project manager for a few big projects. It’s not to disempower others, but rather to empower others with advice, training, methods, tools and services that make everyone successful at delivering their projects.

There are two levels at which a PMO can help others: At a high level, a PMO can help others plan their projects. This includes planning the steps in the process (PERT charts, Gantt charts, work breakdowns, etc.) and how they will control project resources. High-level advice may amount to a little bit of help up front, or active involvement throughout a large project. But regardless of how involved the PMO may be, they are still a “subcontractor” to the real project manager within the appropriate line of business.

At an administrative level, a PMO can help others administer project-specific data. The PMO not only helps them control resources, but also helps them report project status to their boss and their customers in a consistent fashion.

Why Project Management Is So Tough

Some readers may be thinking that this supporting role for a PMO won’t be enough. They may feel that their technical staff will never be able to manage big projects. Why do some CIOs feel the need for a SWAT team of super-project managers in a PMO? On the surface, it may appear that most staff aren’t very good at managing projects. But the problem may be deeper—it may be systemic. Imagine being the project manager for a cup of coffee. You’d have to tell “Juan Valdez” how many beans to plant. You’d arrange for workers to harvest the crop, and a truck to carry it to market. You’d send a ship to pick up the beans and dock workers to load it. On the other end, you’d arrange trains to carry the beans from the dock to the roasting plant. You’d buy natural gas to roast the beans, and containers to package them. You’d schedule trucks to carry them to market. You’d plan shelf space in the market, and check-out clerks to sell the beans. You’d arrange for filters, water and electricity for a coffee-maker…

Clearly, a cup of coffee is an impossible project to manage using the traditional model of a project manager as one who directs the activities of everybody on the project team. In reality, how do we get a cup of coffee?

In a market economy, each step in the value chain simply manages its immediate subcontractors. We buy beans from a grocery store or coffee boutique, and leave it to the store manager to figure out how to supply them. The store manager buys the beans from a distributor, and leaves it to the distributor to arrange for their production and delivery. And so on.

The market model can be applied within organizations as well. For every project, one group can be considered the “prime contractor.” This prime can subcontract to peers within IT for help. The key is subcontracting for deliverables, not for people. For example, an applications developer (the prime on an application project) can subcontract to peers for a logical data model, a physical data model, installation into production, etc. Other managers can figure out how to produce these sub-deliverables.

In this paradigm, the subs become project managers for their components. Thus, the prime is still fully accountable for the entire project, but much of the project-management workload is shared with subcontractors. With this systemic approach to project management, you no longer need a small group of super-project managers in a PMO. Instead, everybody is a project manager for their respective deliverables, and the PMO helps them all succeed.

How to Implement Effective Project Management

The first step in implementing systemic project management is to charter a PMO carefully. Its job is to serve peers, not supplant them, sharing its in-depth knowledge of project management without actually being the project manager.

Next, every group in the organization must identify its products and services, both those sold to clients and those sold to peers within IT. This exercise teaches staff to accept responsibility for results, not just for technical competence. Defining each group’s products and services requires an understanding of what business each is in.

Then, a CIO must establish a discipline of contracting internally, not just service level agreements with clients. This is essential to the prime holding internal subcontractors accountable for delivery of subcomponents.

Finally, a CIO must establish the practice of “walk-throughs” as the first step in project planning. A walk-through starts by defining exactly what the customer is buying and identifying the prime contractor who’s in the business of selling it. Then, the prime decides what to buy from subcontractors, and subs buy from their subs, and so on. A tree-structured project plan emerges that defines who’s on the project team and exactly what deliverables each is accountable for.

This systemic approach takes a bit more effort to implement than simply throwing in a PMO as a paladin, a shining knight there to save the organization from its incompetence. But the payoff warrants the investment. The systemic approach makes the entire IT organization successful at every project, not just the big ones. And it supports a culture of empowerment, entrepreneurship and accountability.

Dean Meyer helps IT leadership teams design high-performance organizations. Author of six books, numerous monographs, columns and articles, he brings innovative systematic approaches to what others consider the “soft” side of leadership. Contact him at dean@ndma.com or visit his website for information that can help you implement these ideas, or with suggestions for other buzzwords to analyze in future columns.