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.