NDMA Home Page
Index of topics on this NDMA website
Search this NDMA website on Google
© 2024 N. Dean Meyer and Associates Inc.
Excerpt from www.NDMA.COM, © 2024 N. Dean Meyer and Associates Inc.

Analysis: A PMO that Manages Projects

when a Project Management Office (PMO) actually class= manages projects, the collateral damage is severe

by N. Dean Meyer

[excerpt from the book, Principle-based Organizational Structure]

Excellence in project management is essential to reliable project delivery. On large, complex projects, it's particularly critical.

Traditionally, a project leader is accountable for managing every aspect of the project, including the tasks assigned to every team member. But for large projects, few people have sufficient project-management skills.

Some leaders address this by creating a small group of "super project managers" for the difficult projects.

An IT department tried this, and reveals its problems.

Fred was in charge of the applications engineers who did most of the projects. But Fred's group was weak in project-management skills.

So, the CIO formed a Project Management Office (PMO) and appointed Kathy to head it up. He moved a few of Fred's best project managers under Kathy.

The structure under this CIO looked as follows:

  • Kathy, project management office
  • Fred, applications engineering
  • Operations

Kathy wasn't there to help Fred manage his projects. It was the other way around. Kathy was accountable for big or complex projects, and Fred was just a "body shop" supplying people to work on Kathy's projects. For large projects, it was as if the PMO sold applications.

This led to numerous problems....

Quality Suffered

Kathy's project managers were experts in project management, not applications engineering. Nonetheless, they controlled who was on the project team and their assignments, schedules, and key design decisions that affected delivery dates.

Sure, project managers got input from others. In fact, they wanted to understand the technical decisions they were making. Their well-intentioned learning curves slowed project delivery.

But project managers were accountable for results, so they had to have the ultimate authority to make those decisions. With non-technical people calling the shots, quality suffered.

Exacerbating this, the incentives were biased against quality. Kathy wasn't accountable for long-term applications support; but she was certainly accountable for on-time delivery.

Project managers had an incentive to sacrifice quality in favor of due dates. They were quite willing to accept undue risks with regard to future maintainability, supportability, operational effeciencies, integratability, etc., -- to cut corners and reduce quality -- to get projects done on time.

Architecture Suffered

The future was also put at risk for lack of ownership of the applications line of business -- someone to plan its future, define its products, optimize its methods and costs, and evolve its skills.

Fred didn't really own the "applications" line of business. He couldn't control key design decisions; but he was still accountable for future support, maintenance, operational efficiency, integrations, etc.

With Kathy taking over delivery of his products from time to time, he wasn't an empowered entrepreneur who could plan its future, define its products, optimize its methods and costs, and evolve its capabilities.

Morale Suffered

Fred's staff, being just a body shop on all the interesting projects, were demoralized.

And they had little incentive to improve their project-management skills -- the root cause of the problem.

Client Confusion

Both groups Fred and Kathy delivered applications. So how could clients know where to go for what?

Internal Tension

Fred's staff never really felt they had full authority for their own product lines. They couldn't control key decisions on new projects, and yet they were stuck with maintaining those applications once the project had finished.

As you'd expect, Kathy and Fred were at odds, not because they didn't get along but because the structure set them up to fight.

Bottom Line

An entrepreneur owns a business, plans its future, establishes its products, optimizes its methods and practices, maintains its skills, manages its resources, quotes its prices and makes commitments to its customers, delivers its products and services, and supports its installed base.

Fred couldn't be an empowered entrepreneur when Kathy's project managers occasionally take over and deliver his/her products. This undermined Fred's ownership of his line of business, dampened his entrepreneurial spirit, and demoralized his staff.

And by the way, there was little incentive for Fred's developers to improve their project management skills -- the original root cause of the problem.

A better answer is to leave all projects with Fred, regardless of size. Then, Fred's developers can employ Kathy's project managers to help them succeed at their difficult projects.

In short, Fred alone should be in the business of selling applications. Kathy should be in the business of selling project planning and facilitation services to Fred.


Free library


Speech abstracts

NDMA coaching/consulting services