Many, if not most (or all) large organizations that perform a significant amount of project work will have some group or team that’s supposedly in charge of the institution’s Project Management capability. Sometimes it will bear the formal title of Project Management Office, or PMO; other times, it won’t, but will still fulfill the same basic function. These organizations will typically pursue a wide variety of techniques or capability advancements traditionally associated with PM, including:
- Procedure or policy-writing,
- The selection of the preferred Critical Path Methodology software,
- The selection of the preferred Earned Value Management software (I do wish people would stop referring to the EVM software as the “cost processer.” That’s not what an EVM system does.)
- The development of templates (often in a word processer package) for the basic PM baseline documents, such as Work Packages, Variance Analysis Reports, or Control Accounts,
- Endless process diagrams, indicating how the overall system is supposed to function,
…among others. And, to be fair, these are the obvious ways that the PMO will seek to expand its influence, and bring the organization’s Project Management capability to a point where most (if not all) projects can be reasonably expected to come in on-time, on-budget, and without claims against for failure to deliver the contracted scope.
But is this the way it’s supposed to happen?
Clues That You May Be Doing It Wrong…
Here are some signs that the PMO is doing the whole strategy implementation game wrong:
- You still have a significant number or magnitude of overruns or late completing projects.
- Medium-sized projects’ managers put significant effort into avoiding compliance with the organization’s guidance on PM, especially the ones that prescribe a certain level of robustness.
- Small projects have their costs “managed” by information that comes solely from the general ledger.
- This one is key: the existence of “shadow organizations,” or small teams of PMs or project controls professionals who do not belong to the PMO, or institutional PM organization.
Any of these conditions should be taken as ipso facto evidence that your PMO’s strategy is failing, and in need of immediate correction. But where to begin to assess the errors in the existing strategy?
…And How To Get It Right
Fortunately, GTIM Nation has the inside track on this. Recall an axiom I often return to, that for any organization that’s providing a good or service, Quality, Affordability, Availability: pick any two. In other words,
- A quality service that’s affordable will usually require a wait in line;
- A quality service that’s available right now isn’t going to be cheap, and
- An affordable service that’s available right now isn’t going to be advanced, or robust.
It’s been my experience that those setting up or revamping an existing PMO will almost never consider this axiom. They blast ahead, confident in their ability to fulfill all three aspects. When confronted with any (or all) of the numbered phenomenon, they invariably attribute it to recalcitrance on the part of the organization, rather then their own selection of a non-viable PM advancement strategy.
However, if you, as head of the institutional PMO, encounter one or more of the numbered symptoms listed above, it’s almost always attributable to an unmet demand for PM information systems or services that are not predicated on the institution’s notions of what constitutes “quality.” The PMs are seeking an approach based on Strategy C above – at least from the institution’s perspective. Not to get back on an all-too-familiar soap box here, but there are numerous aspects of Project Management that are associated with a more robust capability that are, in fact, not only failing to advance PM, but are often guilty of detracting from it. Examples include:
- Quality Management, particularly at the “Six Sigma” level;
- Communications Management, especially the whole bit about “engaging all stakeholders,”
- The notion that the PMO must be able to prove a positive return on investment (ROI) in order to establish its worth or viability, since (a) ROI as applied to PM is an irrelevant metric, (b) it’s impossible to accurately capture the needed parameters, and (c) the very effort of pursuing that figure is evidence that the people running the PMO don’t understand what it’s for, and…
- …of course, risk management.
The remedy? Make available a simple Earned Value Management System, shorn of the extraneous attributes (among others) above, with a minimum of data collection needs. Put it in place, and quietly provide its critical cost and schedule information to the projects’ decision-makers. Don’t breathe a word about what the PMO or institution believes the system should do, or contain. Let the PM dictate every last characteristic.
Then step back and, with a little patience, watch the surprise overruns and shadow organizations simply fade away.