PROJECT MANAGEMENT OFFICE (PMO) NDMA Inc.: PROJECT MANAGEMENT OFFICE (PMO)
how to implement a PMO that helps everyone succeed
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 technical 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.
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 PMO 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, 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. (For more on this approach to project management, see High-performance Teamwork.)
Note that 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. (See Beneath the Buzz: Service Catalogs.)
Defining each group's products and services requires an understanding of what business each is in. (For more on the lines of business within IT organizations, see The Building Blocks of Structure.)
Then, a CIO must establish a discipline of contracting internally, not just SLAs with clients. This is essential to the prime holding internal subcontractors accountable for delivery of subcomponents. For more on this, see Beneath the Buzz: SLAs and Internal Contracts.
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.
How NDMA can help
Myth of the Super Project Manager:
why we think we need superheros and how to be great at project management with the people you already have (speech)
Who's Got the Ball? (speech)
STRUCTURE: The Building Blocks Approach to Organization Charts.
"ERP AND MEGA-PROJECTS: ROLE-CLARITY": Sorting out the roles of clients, the project team, and traditional staff (consulting process)
"ERP AND MEGA-PROJECTS: CONTRACTS": Clearly and precisely defining the distinct deliverables within the project, and the individual accountabilities of each member of a project team (consulting process)
Contact us for a free one-hour telephone consultation on your unique challenges.