For most people involved with project management, a Program/Project Management Office (PMO) is an ideal entity to deploy at any company. Theres much to like about a centralized group that does everything from creating and deploying standardized project management practices and tools, to managing dependencies among various projects while tracking their performance. At their best, PMOs provide an air traffic control organization of sorts, tracking a wide range of projects while guiding them toward their destinations, collision-free.
Unfortunately, many PMOs fail to provide these functions, and instead become a layer of administrative overhead and bureaucracy. Usually, this results in a loss of focus on the high-level objective of the PMO: keeping projects on track and providing a consolidated vision into their performance. When this objective is forgotten or ignored, the PMO can turn into one of these most dangerous PMOs:
Standards for standards sake
Having a common language and toolkit for managing projects is always a good idea, as long as that toolkit provides the right balance of standards and flexibility and ensures the tools accomplish a business objective. Since setting standards and producing templates are highly visible and relatively simple activities, its tempting to spend time cranking out templates and sending out the Project Police to ensure their use.
In the field, however, an overly burdensome or irrelevant set of tools wastes time and resources. Weve all likely been on projects where you needed to check the box, completing some irrelevant template or documentation activity simply so you could report that the activity was complete. In the worst case, Ive been on projects where requirements gathering was all about checking the boxes, and critical requirements were missed or ignored since everyone was so busy drawing pretty diagrams to complete the documentation requirements, rather than actually interviewing stakeholders.
Another dangerous PMO is the one obsessed with status reporting. The best PMOs quietly track performance and keep a finger on the pulse of the project without getting in the way. The worst are constantly scheduling meetings and conference calls to report on status, focusing on meaningless deliverables rather than whether the project is meeting its business objectives and is equipped with the right resources to get the job done. When the going gets tough, rather than helping remove roadblocks this PMO only demands more status meetings, to the point that half the project teams day is spent reporting status.
With such a deep focus on deliverables rather than business objectives, this PMO usually paints an overly rosy picture of projects in their early stages. After all, its easy to produce documentation, but often difficult to solve the right business problems. Usually a few weeks before implementation the reporting turns from clear skies to hurricanes ahead, and just when an individual project could most use the PMOs guidance their demands for more wasted meetings increase.
The shadow PMO
Perhaps the most insidious PMO is one staffed with recent project managers who feel they can out-PM the people actually tasked with managing individual projects. This PMO is constantly second-guessing PMs, calling their own meetings, and generally making it unclear who is actually leading an individual project, all while the key functions of a PMO are ignored. While its tempting to look at a PMO as a group of super project managers, like air traffic control your job is to provide guidance and information, not to attempt to second-guess each pilot in your airspace.
Project Management literature paints a rosy picture of PMOs, often suggesting that by taking a few veteran PMs and cobbling together some standards your PMO will become an immediate winner. While a PMO certainly requires a subset of project management skills, theres far more to a successful PMO than standards, status reporting, and attempting to provide another layer of project management to individual projects.