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.
More on empowerment....
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
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.
More on empowerment....
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