How To Monetize PM

Yeah, I know this blog’s title appears to be somewhat inconsistent with ProjectManagement.com’s December theme of philanthropy – in fact, it’s kind of the opposite, examining ways that PM can be used as a tool to attract funds rather than charitably dissipate them. But such funds can’t be charitably dissipated if they’re not available in the first place, so I will proceed.
GTIM Nation is familiar with my assertion that, within a given organization, the demand for Project Management expertise can be highly cyclical, generally adhering to the following template:
·The young organization experiences an increase in the dollar value or visibility of its project portfolio, or a more mature org sees a significant overrun or late delivery.
·This prompts an awareness (for young organizations) or an urgency in advancing or recovering PM capability.
·New PM specialists are hired (or current PM-adjacent professionals trained), and put into their own organization, typically referred to as the Project Management Office, or PMO.
·Tools are selected for ascertaining cost and schedule performance, techniques for deriving scope, cost, and schedule baselines implemented, project review meetings scheduled, etc., etc.
·Areas where project performance is lacking get addressed by management, and, perhaps more importantly, projects that are doing fine get left alone by upper management, leading to an overall improvement in the cost and schedule performance of the portfolio.
·As the fears of experiencing a large overrun or late project delivery fade, some of the smaller projects (at first) will make the case that they do not need to use the cost/schedule performance systems that the larger projects use, nor should they have to participate in the project review meetings.
·The percentage of projects in the portfolio being covered by any type of valid cost/schedule performance measurement system continues to erode, along with the authority, influence, and budget of the PMO, until…
·One or more projects experiences a significant (or even catastrophic) overrun or late delivery, and the cycle begins again.
Naturally such fluctuations in demand directly impact PMO morale, retention and staffing which, in turn, advances or contracts PM capability maturity. I used to work with one brilliant Project Controls Team Lead who would remind his charges “You never know, we could all be run out of here tomorrow!” Seasoned PMO Directors are well aware of this pernicious cycle, and will often attempt to implement strategies that will lessen its effects. One of the primary methods for attempting to place a “floor” underneath the cycle (i.e., limit the extent that the PMO loses its authority/budget in times of low demand) is to set the elements of the PMO’s business practices into official organizational policy or procedures.
But here’s the problem with such attempts: projects are, by definition, unique. Procedures and requirements are, also by definition, designed to restrict the amount of latitude a given manager has in pursuing project objectives. Any procedural document with any oomph to it will almost certainly proscribe use of a managerial technique or strategy that’s appropriate for most of the projects within the portfolio, but not all of them (especially if there’s a requirement for doing risk management [no initial caps]). Sooner or later this appropriateness mismatch will be used to break through the “floor,” and the PMO will continue to hemorrhage relevance until the re-initiation of the cycle.
How can this cycle be broken? I don’t have the definitive answer to that question, but I would like to offer some ideas, beginning with this: I don’t believe you can stop the cycle by publishing procedures, so that technique should be abandoned. I think that the preferrable approach is more like the way food is offered in a cafeteria. Let the PMs choose for themselves if they want or need thoroughly documented and approved baselines, Earned Value or Critical Path Methodologies employed, Baseline Change Control Boards formed, and so forth; or, very simple cost/schedule performance measurement systems, informal reviews, loose configuration management boundaries (e.g., Agile), etc. Many who will tap into the more robust PM techniques will be compelled to do so by their customers, others may simply seek the confidence that they will be given sufficient warning when a project disaster looms. Still others will either have legitimate reason to avoid an advanced PM implementation for their scope, or they may simply be too arrogant (or ignorant) to employ one, but that’s okay. The PMO Director’s job, in my opinion, is not to humble or inform the latter, and attempts to do so often lead to overreach and frustration. Simply make PM strategies, exhibits and techniques available to the owners of the scope – because we all know what will happen. Those projects in the portfolio that avail themselves of the PMO’s assistance will consistently out-perform their counterparts in cost and schedule results. Projects may very well experience overruns and delays, but at least the PMO-covered ones will be able to provide early warning. Project disasters are never welcome, but there’s just something about them arriving as a surprise that makes them particularly galling to the execs.
Note that this analysis pertains only to the PMO within the macro-organization. The client organizations can issue procedures, guidance, and requirements to their heart’s content – it’s their money, after all. But if you want to monetize the PM application so that it attracts money, in my opinion, humbly offer it as a service – never push it as a mandate.