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

Consider this case study coming from the world of IT (which is often challenged with mega-projects).

It was a complex project -- a new application with lots of data integration challenges, a web front-end, a new DBMS platform, dedicated servers in the data center, and field-office training during the roll-out, along with all the usual issues of change control, help-desk set-up, and contracting for ongoing support-service SLAs. It looked like half the managers in IT were going to be involved, one way or another.

This project needed world-class teamwork and project management, both in the proposal (feasibility study) phase and then to implement it. The question is, who is IT is good enough to handle it?

Based on past experiences, applications developers didn't seem to be up to the challenge. Sure, they're great engineers and can do their own parochial share of the project. But they don't seem able to pull all the pieces together and manage the entire project. Too often in the past, teams don't form, or don't work well, and IT struggles to deliver large projects like this one.

The PMO as Project Manager

For a project so complex and important, the CIO felt they needed a "super project manager" for this huge, politically visible, enterprisewide project. Acting on that believe, he set up a Project Management Office (PMO) which included a pool of project-management experts who would serve as project managers for tough projects.

Henry, an experienced project manager, was asked to lead it. 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.

Definitions

To sort out what happened here, language is very important here. So, first let's 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 -- for delivery of the project (in this case, the delivery of a new application). Translating this into the language of business, the client "buys" an application from the project manager (whether or not money changes hands), who in turn gets help from various other groups (applications engineering, web engineering, DBMS engineering, server engineering, etc.).

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 "engineer" 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. Elsewhere in the IT organization were engineers (as well as other specialists like service providers).

Henry's troubles arose when his project-management experts were appointed as "project managers." This meant that Henry was accountable for delivering products that were in other managers' domains. To put it bluntly, when the going gets tough, the PMO took over delivery of other managers' lines of business.

There were three 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 strategic 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.

The results of this disempowerment were insidious. The other managers no longer felt in charge of their domains. Instead, they began to see their jobs as managing a resource pool. As a result, they lost interest in their competitiveness, their strategies, innovation, 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 which were not transferred to Henry's PMO were not improved.

2. Technical incompetence: Despite the staff 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, a project manager has to make many key decisions about the design and delivery of complex technologies. But project-management experts really aren't qualified to make decisions like what help they'll need from all those other groups, what development methods and tools to use, and key design decisions throughout the project. All their beautiful PERT charts and dashboards aren't a substitute for the depth of knowledge of trained engineers.

Of course Henry's project managers solicited input from the engineers on their teams. But a project manager is accountable for delivery of the project, so they must have the ultimate authority to make these project-related decisions. They still make the final judgment calls, even though they aren't technically competent to do so.

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.

3. This approach leads to a lack of clear accountability -- the opposite of good project management practices. Who is really responsible for the end-to-end delivery of applications? Normally it's the applications development group, but sometimes it's the PMO. How do clients know where to go for what, and whom to hold accountable for results?

And is the manager of an applications engineering group really in control of his or her products? Can they plan the future of their technologies, invent new products, optimize its methods and practices, maintain its skills, manage its resources, quote its prices and make commitments to its customers, deliver its products and services, and support its installed base? Can an applications development manager really be an empowered entrepreneur when the PMO occasionally takes over and delivers its products?

If you were an applications development manager, might you wonder how you can be sure that the project manager will make decisions that are in the best interests of the applications development line of business in the long term? Wouldn't it be tempting for the PMO project manager to cut corners, get the project out on time, get the credit, and perhaps accept undue risks with regard to future maintainability, supportability, operational effeciencies, integratability, etc.?

And will you be prepared (or motivated) to support the solutions the PMO produced?

But Don't We Need Super Project Managers

Clearly project-management gurus are critically important on large, complex projects. But making PMO staff the accountable "project manager" raises as many questions as it settles.

While on the surface it may appear that most staff aren't very good at managing projects, the problem may be deeper -- it may be systemic.

Most problems in teamwork aren't due to a lack of knowledge of what skills are needed on the team. Most applications developers know whose help they need, and know exactly what they need to buy from others. The real problem is generally a lack of an organization process to get the needed help from others, or perhaps a lack of the discipline required to be confident that others will deliver their pieces of the project reliably without lots of oversight.

Similarly, most problems in project management are not due to a lack of skill in managing projects. Rememeber that applications developers are entrusted with smaller projects.

Sure, if you expect one person to manage and control the activities of a large project team, it would take an exceptionally talented person.

In fact, excellence in teamwork and project management does not require confusing accountabilities and disempowering other managers. Applications developers sell applications, big and small. They are the right choice for project manager, indeed the only choice in an empowered, entrepreneurial culture.

"But," you ask, "in the past, they've struggled with big, complex projects; how can we address that problem?"

Consider how the real world manages complex projects.

A REALLY Tough Project

Take, for example, the challenge of managing one of the most complex projects in the world: getting a cup of coffee.

With the traditional approach, you'd have to tell "Juan Valdez" how many coffee bushes to plant.

You'd arrange for workers to plant, tend, then harvest the crop, and a truck to carry it to market.

You'd coordinate shipments of fertilizer.

You'd build a truck to carry the beans to the dock (and we're not even thinking about where the roads came from).

You'd send a ship (fully staffed) to pick up the beans and dock workers to load it.

On the other end of the voyage, you'd arrange trains (again, fully staffed) to carry the beans from the dock to the roasting plant.

You'd pump natural-gas to roast the beans, and containers with labels to package them. And where did all that equipment come from?

You'd schedule trucks to carry the coffee 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....

It all adds up to an unthinkably complex project.

If you had to depend on one person to manage every aspect of such a complex project, you'd be in jeopardy.

But fortunately, there is another way.

How the Real World Manages Projects

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?

The market handles the challenges of teamwork and project management perfectly.

In a market economy, each step in the value chain simply manages its immediate subcontractors.

As the "project manager" for a cup of coffee, all you need to do is run down to your grocery store and buy the coffee and filters. You leave it to the grocery store manager procure those products, managing their suppliers and their staff. The distributors they buy from, in turn, manage the manufacturers, shippers, and store staff. And so on, all the way back to Juan Valdez.

Note that your suppliers don't just provide you with people whom you have to direct. They give you complete subcomponents -- a can of coffee grounds, a mug, a coffee-maker, filters, electricity, and water. You don't have to manage their tasks; they do.

In the real world, there's not just one project manager; everybody on the team manages their own sub-projects. And all you have to do is manage your immediate suppliers.

The value chain eliminates the need for those scarce super-project managers who can control what every individual throughout this long supply chain does every hour of the day.

The market works in any industry. Consider the general contractor who sold you a home. He or she hired plumbers, electricians, sheet-rock installers, roofers, etc. And each subcontractor delivered a product -- a component of the house -- not just staff for the general contractor to manage.

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 subcontractors 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.

Note that with this systemic approach to project management, you no longer need a small group of super-project managers on top of every detailed task. Instead, everybody is a project manager for their respective deliverables, and the PMO helps them all succeed.

How It All Plays Together

Back to our original example. The client wants to buy an application. Regardless of complexity, it's clear that they buy the solution from the applications development group.

Both at the proposal stage and the implementation stage, that prime contractor subcontracts for all needed components -- other applications groups for data feeds, the web CMS group for the front-end, DBMS engineers for the data model, etc.

And let's not forget one very important subcontractor: In any line of business, a project manager can (and should whenever needed) subcontract to the PMO for project planning services, project-management advice, and project data administration. In this way, excellence in the discipline of project management is available to any project in any line of business.

Just remember, to avoid confused accountabilities and disempowerment, the PMO serves a subcontractor, not the prime, helping everyone succeed as project managers in their respective lines of business.

Three Rules

There are three rules needed to make this work:

First, everybody is the prime contractor (ie, project manager) for products and services within his or her line of business; and nobody sells products or services outside their line of business (not even the PMO).

Second, the first job of a prime contractor is to line up needed subcontractors. This involves working with peers to gain commitments for deliverables, not people.

Third, everybody is accountable for delivering their products and services as promised, whether it's the prime contractor delivering the whole solution to clients or subcontractors delivering their components to the prime. This degree of integrity is based on two more principles: Never make a commitment for others. And never make a commitment you can't keep.

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.

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 know what it sells. That is, every group is defined as a business within a business.

Every group in the organization must identify its products and services, both those sold to clients and those sold to peers within their immediate organization (in this case example, IT). This exercise teaches staff to accept responsibility for results, not just for technical competence.

Then, the organization 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.

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.

Abstracts Free library

Books Speech abstracts

NDMA coaching/consulting services

UP.... NEXT PAGE....