How PMOs Are Like Uranium

 

Without getting into specifics, if one were to place too much of a specific isotope of Uranium in the same place and at the same time, it would initiate a fission reaction, also known as “going critical.” If this were to happen unintentionally, many, many people would have a very, very bad day. This being the case, how on Earth, I can hear GTIM Nation say, is Michael going to draw this analogy, between a nuclear fission event and your run-of-the-mill Project Management Office, or PMO? I’ll explain.

Recall my oft-cited Hatfield’s Rule Of Management #23: Affordability, Availability, Quality, pick any two. When PMOs first start off, they are typically made up of small-to mid-sized teams, even within large macro-organizations. Many will fail, but I’m convinced that its odds of success are significantly enhanced if their overarching strategy takes into account the previously-stated rule, and aligns itself with the owning macro-organization. For example, a contractor that does not deal with new or cutting-edge technology, known for its ability to deliver more basic, usable output on-time and on-budget, would probably not benefit from a PMO that insisted on a rigorous, highly-detailed audit-survivable Cost/Schedule Control System. On the other hand, an organization that did work with high-profile, cutting-edge technology, intended for mission-critical applications is likely to have a customer highly desirous of accurate and timely performance information, and would likely fail without such a Cost/Schedule Control System.

But here’s the rub. Many (if not most) medium-to-large contracting organizations will not be totally one or the other. Their portfolios are likely to be mixed, with a combination of high- and low-risk projects, rendering a one-size-fits-all PMO approach more of a liability than an asset. And yet, it has been my experience that the small/initial PMO, as it moves towards mid-size and maturity, will prioritize the writing and publishing of procedures and guides, standardizing the techniques and outputs for PM in general, essentially mandating just such an approach.

Now consider what is likely to happen when all of the elements of this PMO are brought together in close intellectual proximity, throwing out their ideas on how PM should be advanced within the macro-organization but needing the rest of the PMO to agree with them. Some will, no doubt, stress the need for an enforced solution (basically, writing down everything they believe needs to be done in a procedure, which is then approved by upper management), while others will point to more recent capability maturity theory as the only way to go. Still others, wanting to avoid organizational conflict, will suggest a cafeteria approach, where the technical managers decide the level of baseline and performance measurement system robustness, and there will always be the ones who believe that more PM training will automatically move the macro-organization closer to an advanced PM capability. As the debate continues, temperatures rise, and those who are least prepared to defend their assertions rationally may resort to pointing to their education, including their certifications, or experience in some gee-whiz project, all of which tends to produce more heat than light. It all reminds me of Hatfield’s Rule Of Management #26, that you can put fifty PMs in a room together, and they will not be able to agree on the color of an orange.

As the free neutrons competing ideas slam into other radionuclides self-designated experts, the entire core technical agenda can go critical degrade, with only the introduction of graphite tamp a compromised solution (which nobody really wants, but offends the fewest PMO Team members) preventing a complete meltdown technical agenda collapse. So, how do we avoid even approaching this scenario in the first place?

Let’s start by circling back to a couple of assertions made earlier in this blog, specifically (a) that some parts of the portfolio are going to need only basic PM capabilities in order to increase their chances of successfully bringing in their projects on-time, on-budget, while others will need significantly more robustness in those systems, and (b) a one-size-fits-all approach ignores those needs. This being the case, the savvy PMO director will bifurcate the resources into two Teams: Team 1 will leave the level of cost/schedule performance measurement systems robustness to the Technical PMs, and simply provide the talent to make it happen. This Team will be affordable and available. Team 2 will bring with them the expertise to make advanced PM Information Systems a reality. They will be available and quality-oriented. These two Teams will only play by the same set of rules if those rules are general in nature, as their specific missions will be quite different. By splitting the core PMO’s deployed resources along these lines, you are decreasing the odds that it will go critical arrive at a dysfunctional business model, which would lead to, well, a lot of people having a bad day.

For those members of GTIM Nation who disagree with me, I’m looking forward to seeing y’all nuke my arguments in the comments section.