The Dreaded Project Accountability Avoidance Office
| In last week’s blog, an alert GTIM Nation member added a comment that contained the following: “Hence, many PMOs operate as a PAAC (Project Accountability Avoidance Office).[i]” (Yes, the commenter subsequently addressed the fact that the Project Accountability Avoidance Office’s acronym is actually PAAO.) This set my remaining active brain cells into overdrive, as I reflected on that sentence’s implications. In particular I remember reading about an interview question that went “Would you rather be part of an empire in its ascendency, or its decline?” Let’s set aside the sheer goofiness of this question actually being asked in an interview. Any thinking person would instantly recognize that the potential employer is going to prefer candidates that choose the former, and respond accordingly. But that question, I believe, points to one of the main implications of the term Project Accountability Avoidance Office, that I would articulate as “Project organizations begin with the goal of actually executing scope on-time, on-budget; however, over time, they tend to shift their overall focus on sustaining themselves as a PMO, collecting salaries and scolding internal opponents.” The movement over time from genuine PMO functions towards “Project Accountability Avoidance Office” purposes strikes me as a migration away from accomplishments outside the PMO (the macro-organization’s project portfolio) and towards the internal goals of self-perpetuation and well, to be blunt, influence peddling. Recall the axiom “This is an unfair thing about war: victory is claimed by all, failure to one alone.” Originally attributed to Tacitus[ii], derivatives include “Success has a thousand fathers, failure is an orphan.” What would lead the nominal PMO to seek to engage in accountability avoidance, then? Would it not be … failure? Failure to bring Projects in on-time, on-budget? Rather than continue asking rhetorical questions, let me just drop this unattractive truth on the conference room table: when the project portfolio performs poorly in cost and schedule space, the whole reason for having a PMO in the first place comes into play. If such a PMO is already in sustaining-themselves mode, their tactics will become more and more off-putting, as they will attempt to justify their existence through narratives that are divorced from actual performance, and more along the lines of the eat-your-peas-style hectoring that I often decry in this blog. And here is where a cruel irony of the Project versus Asset Management struggle manifests. There is no Return on Investment (ROI) without happy clients, which, in turn, doesn’t happen without effective PM. But, once those clients are being confronted by overruns and delays, the litmus test that will be used to overhaul (or even dismantle altogether) the PMO will be the ROI. So, how does the PMO Director keep from crossing the line between legit PMO and the downward slope towards PAAO? For this I want to turn to one of the four Maccoby archetypes, the Company Man. Quick refresher for recent GTIM Nation additions: the brilliant Michael Maccoby wrote a book entitled The Gamesman; The New Corporate Leaders (Simon and Schuster, 1976), in which he posits four worker archetypes:
The canary in the PMO-to-PAAO path coal mine is going to be the Company Man. Craftsman and Gamesman will feel right at home in the legit PMO, Jungle Fighters in the PAAO, and each will feel out-of-place in the opposite environ. What are your Company Men doing? Remember that they tend to take on the persona of the organization around them, in this case, the PMO. Are they directly involved in advancing PM capability within the organization? Or are they attempting to distance themselves from failing/failed Projects, Jungle Fighter-style? If the latter, there’s at least a possibility that your PMO is starting to turn into a PAAO. Three strategies will help avoiding that path: (1) keep your PMO lean, spending only on the things that actually improve Project performance, (2) base assessments of PMO value on actual portfolio cost/schedule performance – no appeals to what others hold to be “proper” management techniques, and (3) keep reading this blog.
[i] Freeman, George, from the comments section of the Game Theory In Management Blog, posted 16 April 2024. [ii] Retrieved from https://dailystoic.com/success-many-friends-failure-orphan/ on 20 April 2024, 19:47 MDT. |
Does Your PMO Have More Road-Hugging Weight?
| Back in the 1970s a major American car manufacturer had an advertising campaign for one of their cars that included the assertion that their car, when compared to others in its category, had “more road-hugging weight!” I and my car enthusiast friends would often mock this assertion – anyone with a sense of the need to optimize a car’s power-to-weight ratio would instantly recognize that “selling point” as pretty lame – but, after all these years, I’m not sure we were mocking the right people. Consider the mindset of the people who wrote the actual ad copy. They must have known more than the average car buyer about which car specifications would be considered attractive, and yet they included the more-weight data point as if it wasn’t a detriment. The more I (over-) think about it, the stranger it gets. I have to wonder if they considered going with “better ride,” which often accompanies heavier car chassis, or even “safer in a collision,” which is also associated with heft. Don’t get me wrong – I don’t know who put those ads together, or approved them for airing. My speculation, though, is that they knew going in that the “more road-hugging weight” assertion would not be attractive to consumers with an advanced knowledge about cars, and were, therefore, attempting to attract those people who would hear such a statement and consider it a preferable feature. They may have also been under the belief that those people who considered “more road-hugging weight” to be a positive thing outnumbered those who would instantly recognize it as a negative, at least among the population of those who made the ultimate decision in car purchases. The whole thing essentially begs for a clear-headed person, familiar with the actual goal of an automobile (to reliably, efficiently, and effectively transport people and cargo from Point A to Point B) to step up and say something. Meanwhile, Back In The Project Management World… Ah, yes, that perennial need for a clear-headed person to step up at critical times. This need is obviously not confined to advertising campaigns for 1970s-era cars. It is, in fact, ubiquitous, but this is a blog dedicated to Project Management, so I’ll confine my discussion to that arena by starting with the question, What is the point of a Project/Program Management Office (PMO)? Since I’ve posed this question to GTIM Nation previously, you only get go-to-the-head-of-the-class recognition if you are both a newbie AND answered “to provide PM-centric information to decision makers that is accurate, timely, and relevant.” In those cases where the PMO also serves as the organizational node for PMs, it also has to have a lot of meetings. I’m not going to debate it – that’s the right answer, the warp and woof, the raison d’être of the PMO. Of course, I’m fully aware that there are those who would disagree with this assertion, typically by maintaining that the PMO is also responsible for:
…or, perhaps most odious of all,
I take sharp exception to each of these claims, on the basis that these hangers-on to legitimate PM science fail to directly contribute to PM’s ultimate goal, to select those strategies and technical approaches that maximize the odds of bringing in the project on-time, on-budget. For those of you who are curious whether or not there’s a litmus test for what I consider a legit PMO purpose or not, it would be this: is it quantifiable? The accuracy and timeliness of PM information can be gauged. Not so whether or not an organization’s culture is advancing with respect to its embrace of PM precepts. The risk managers (no initial caps) consistently flunk the relevancy test, as do the Six Sigma aficionados. Procurement and recruiting – which, incidentally, fall under the Asset Management umbrella – should work efficiently and effectively, but those standards of efficiency and effectiveness are entirely subjective. Now consider how much effort is put into selling the PM community writ large that each of these specialties should have a place at the table when it comes to establishing an overarching codex of PM practices and principals. All they would need to do is to conduct a valid study that showed, in whatever quasi-controlled experimental setting, that the PMO that spent time and energy pursuing, say, an advanced Communications Management capability was consistently bringing in its portfolio on-time, on budget, due to the adoption of CM techniques. I’ve never seen such a study even attempted. It's almost as if all they have left to back their claims of their specialty’s PM relevancy is to assert the management science equivalent of “more road-hugging weight.” |
PM Career Advancement – Why Is It Different?
| No discussion of career advancement within Project Management (ProjectManagement.com’s theme for March) would be complete without an at least cursory compare-and-contrast exercise with the nominal career trajectory of our friends, the accountants. What pops to the surface of this cursory examination is the obvious fact that these two nominal career paths are very different, even though in each case we’re talking about bringing to the macro-organization a certain level of business expertise in matters ranging from the picayune (should we rent or buy the copier? Which estimating method should be used in deriving the Cost Baseline?) all the way to the future-defining (which indirect projects should be funded this year? Which projects in the portfolio represent the macro-organization’s core capabilities?). I think the central reason that the Asset Managers’ nominal career trajectory is so different from the typical PM practitioner’s has to do with the fact that the general ledger is the system of record when it comes to determining how much tax revenue is due to the government. That’s the reason that all licensed businesses are required to have a general ledger before they can conduct any actual business. Compare this to the fact that, for the most part, even large project-oriented businesses are completely free to either embrace the tenets of PM as articulated by PMI® (or any of the other organizations promoting its practices), or to eschew them altogether. Granted, those organizations that do resist the precepts of PM are far more likely to fail, earlier rather than later, but the fact remains that they are still entirely able to ignore the PMBOK Guide® if they so desire. No such leeway is granted for the creation and maintenance of the general ledger. Conducting business without one can (and almost certainly will) lead to the arrest and imprisonment of the managers responsible. Can GTIM Nation imagine how the business world would be different, if PM was the law of the land, and it was the Asset Managers who had to convince the management universe of the efficacy of their information systems? Conventional wisdom would bestow axiomatic status to the assertion “The point of all management is to deliver the customers’ expectations on-time, on-budget,” and to hint that the point of all management is to “maximize shareholder wealth” would get one laughed out of the faculty lounges in business schools across the land (hey, a guy can dream, can’t he?). The point here is, as long as there are governments keen on collecting tax revenue from businesses (essentially, forever), there’s going to be a baseline-level of demand for those who have a talent for creating and maintaining those types of information systems, i.e., accountants. We PM-types are left on our own, to seek out and support those organizations on the lookout for a competitive advantage when it comes to delivering scope on-time, on-budget. “But Michael!” I can hear GTIM Nation say, “That’s also a forever business environment! There will always be companies seeking such an advantage!” True, but, as pointed out earlier, those organizations that eschew PM won’t go to jail for it. And falling behind on Project cost and schedule performance can take time to become obvious to the clientele writ large. Here, again, is an example of why the Asset Manager’s career path is different from the typical PM practitioner. If, at month-end close, the books don’t balance, the accountant/CFO has clearly erred. Conversely, if, at the project review meeting, a PM is showing an out-of-threshold negative cast and schedule variance, he has an opportunity via the Variance Analysis Report to accurately explain why … or to obfuscate, deflect, and deny the bad news in front of everyone’s eyes. Essentially, the accountants’ mistakes are clear, direct, and reliably quantifiable. The PM’s mistakes can be obscure, circuitous, and imprecisely quantifiable (hence the need for Variance Analysis Thresholds). With that kind of space between timely, accurate, and certain evaluation parameters and eventual PM reward (or comeuppance) being established, non-merit-based operators have all they need to move upward in the macro-organization’s PMO at the expense of the most talented. Only the long view, at the portfolio level, will reveal which PMs consistently bring in their scope on-time, on-budget, and even that is contingent on a broad-based Earned Value Management System (EVMS) that keeps track of all of the projects’ actual performance. But EVMSs aren’t required. General Ledgers are. I think that’s the main reason why the career advancement of PMs is usually more uneven than that of the Asset Managers’/accountants’. All this having been conceded, I must admit that I kind of prefer the uneven trajectory. It keeps things from getting boring. |
It’s Time To Play … The Contingency Game!
| GTIM Nation knows of my low regard for risk management (no initial caps) analysis as a source for reliable management information. The one area, though, where it might be of some use is in the creation of a Contingency Budget for projects that have been negotiated as a Cost Plus-type contract. This type of contract is normally used for projects that involve a significant degree of risk, typically due to being performed at a venue where personal and materiel security can’t be guaranteed, or else due to the incorporation of new technology, truly novel scope, or some combination of these. Due to this inherent level of uncertainty, many project sponsors will allow for the development of a Contingency Budget, for work that is definitely in-scope, but isn’t in any of the baselines. Ah, but there’s the rub: what, exactly, is in-scope, uncosted? This question is the very essence, the raison d’être of the whole Baseline Change Control process. For if there was an easy litmus test for which requests for additional budget were legitimate, and which were based on poor performance (and should therefore be rejected), then it wouldn’t take a multi-member Baseline Change Control Board to micro-evaluate each and every Baseline Change Proposal (BCP), deliberate it, and hand down a determination days (or even weeks) later. Such a litmus test could have conceivably prevented the entire Agile/Scrum Project Management theory codex from coming into existence, since its main purpose was to streamline configuration management in such a way as to keep BCCBs from delaying needed changes to software projects’ baselines that had to happen in the very near-term in order to prevent IT project failure. Alas, such a litmus test does not exist, requiring the now-elaborate processes embedded in the Baseline Change Control Board charter to ensure the funding of true contingency events, the exclusion of false ones, and an equitable treatment of the in-between events. These processes are highly resistant to formulaic remedies and, due to this chaotic aspect, begin to assume the characteristics of some grand game. For example, a common assertion from the risk management (no initial caps) crowd is that, if an uncosted event occurs, and it was described in detail in that Project’s risk register, then the approval of the Contingency BCP should be somewhat automatic. However, if a true contingency event has happened, but it was not documented as a possibility, then the risk managers’ strategy with respect to the role of the risk register has to change, from being an adequate tool that captures potential risk events, to a document that only addresses some of the things that might happen, and we just missed this one, don’t you know. It’s the risk managers’ version of the heads-I-win, tails-you-lose trick, rephrased as “If it happens, and it’s in the risk register, it’s automatically a legit contingency event; but, if it’s not, it still might be a contingency event, we just need more time to tell you why.” Then we have the very real possibility that either the customer or the PM may act in a way that would allow only one of them to win this game, as depicted in the following Payoff Grid:
Scenarios (B) and (C) depict the BCCB functioning as it should. Savvy customer oversight management will be on the lookout for Scenario (D), in order to prevent a “get well” BCP from getting through the process, and covering the costs of poor performance, a bad initial estimate, PM-initiated scope creep, or any of the other drivers of project overruns and delays. Conversely, PMs will work to prevent Scenario (A) from unfolding, which would lead to the contractor having to absorb the costs from an event that had nothing to do with the Project Team’s performance, or even the agreed-to Scope Baseline. It’s noteworthy that Scenario (A)’s outcome is exactly the same as those instances where the Customer induces scope creep, in that (1) the Project Team performs work that was not costed, but somehow And Game Theory is what this blog is all about. |
Culture Is Downstream From … Well, What?
| I’m sure most (if not all) of GTIM Nation is familiar with the axiom “politics is downstream from culture,” but what is upstream from culture? In using the upstream and downstream analogies, I mean that changes in the “downstream” entity follow ones in the “upstream” categorization, sometimes with a clear cause-and-effect manner, other times more subtly. So, if the politics version of this axiom is apt, what would be the equivalent connection for, not the hopelessly complex culture in general, but for the more specific corporate culture, or the Project Team’s? If you perform an internet search on the truncated version “Culture is downstream from …”, a common answer is “leadership,” but this is problematic in that it leads to a form of tautology. Since most nations elect their leaders in some form of a political process, the whole upstream/downstream business becomes cyclical, as in Politics is downstream from Culture, which is downstream from Leadership, which is elected politically. Within the confines of the specific organization, leadership determining corporate culture does have the ring of reasonableness about it. Sure, there are going to be at least some cultural values shared by the macro-organization, but individual management leaders are going to have a far more direct impact on the Project Team’s philosophy than executives who may have little or no direct interaction with any of them. GTIM Nation knows of my respect for the work of Michael Maccoby, specifically his book The Gamesman (Simon and Schuster, 1978) where he asserts four archetypes of workers, The Craftsman, The Company Man, The Jungle Fighter, and The Gamesman. Now consider a scenario where the macro-organization has a certain set of values and managerial philosophies that make up its “culture,” such as it is. Some of these values and philosophies are formal, and documented in policies, procedures, and in other venues. Others are unspoken and undocumented, either because they’re considered to be obvious, or else because they make up a behavioral expectation that’s part of the business model, but would reflect badly on the macro-organization if they were to be articulated openly. But make no mistake: transgressing the unspoken rules of the corporate culture can easily be as career-threatening as breaking the stated rules, should the outcome be other than unmistakable success. Funny thing about success – it has a way of reducing the stigma of having broken cultural norms, if not clearly-articulated rules. But back to The Gamesman. Bouncing off of the notion that Culture is downstream from (Project) Leadership, your Project Team’s derivative culture will almost certainly be influenced by the Maccoby archetype of the PM, so:
It follows, then, that if my assessment of what happens at the intersection of Maccoby archetypes and Project Team sub-culture influence is reasonable, that “culture” follows success; and, if that success is attained by bending (or even breaking) the spoken and unspoken codex that represented the existing culture, then that codex will change towards one that is more conducive to future Project victories (or the organization will fail, depending on how rigid the existing codex may be). Two implications from this conclusion stand out: (1), “organizational culture” cannot be directly changed, but can be influenced by those managerial leadership approaches that result in success, and (2) Company Men and Jungle Fighters are particularly poorly placed to effect such changes. Oh, well. |





