The Underrated Hazard Of Obstructionism
| It’s time for another payoff grid (the Game Theorists’ favorite tool) to shine some light on that perennial enemy of the PMO, obstructionism. You see, PMOs don’t fail because PMI® failed to identify the best ways of capturing scope, schedule, or cost baselines; nor due to any deficiency in recognizing the best practices from across the PM universe (excepting, perhaps, the pixel-ink wasted on risk management [no initial caps]). No, PMOs often fail due to the insufficiencies of their implementation strategies, specifically where they do not line up with the dynamics of the macro-organization. And here’s the kicker: even when the most suitable implementation strategy for certain organizations has been selected, it still might fail, due to this aforementioned obstructionism. So, how does a PMO Director deal with obstructionism? First, let’s identify the specific varieties and their sources. GTIM Nation knows of my respect for the brilliant Michael Maccoby, specifically in his book The Gamesman (Simon and Schuster, 1976), in which he lays out four archetypes of corporate workers/managers: ·The Craftsman doesn’t much care about for whom he works, but cares very much about the quality of his output. ·The Company Man tends to take on the persona of the organization for whom he works. ·The Jungle Fighter succeeds via calumny and political maneuverings rather than the quality of the output. ·The Gamesman doesn’t see his paycheck as a roof over the head or food on the table. Rather, he sees the entire workaday experience as some sort of game, where his renumeration are as tokens. Back to the payoff grid. Imagine an evaluation of corporate workers along two axes: one scores if they are poor or middling performers as opposed to high performers, and the other scores if the worker is politically savvy, or not a good political player at all. Here’s what that would look like, along with the (likely) home of each of the Maccoby archetypes:
I’m going to continue under an assumption that might not be very popular outside PM circles, and that is high performers will, by nature, gravitate towards wanting an advanced PM capability within the macro-organization. Our friends, the Accountants, may believe that the point of all management is to “maximize shareholder wealth,” and to that end the desire to deliver scope on-time, on-budget may or may not be entirely incidental. But outside those who adhere to the MSW speciousness, delivering on-time, on-budget means a great deal to the enterprise’s success rates. So, if advanced PM acumen is consistent with the Gamesman’s and Craftsman’s persona, that just leaves us with the left-hand side of the performance ledger (pun intended). Unfortunately, this is where obstructionism lives, and is therefore more dangerous. If it’s one thing I’ve noticed about the Jungle Fighter types with whom I have had the misfortune to work, it’s that they can’t stand the notion that they would be identified as getting ahead solely on their political maneuverings rather than actually contributing to portfolio success. To this end they will tend to hover near the High Performers, to see who will actually succeed. The High Performers who appear to be nearing a success story will suddenly see the Jungle Fighters attempting to connect more often in order to poach high-profile but ultimately easy-to-execute pieces of scope or function in order to be more closely associated with the unfolding success story. Conversely, if a High Performer is running into extreme difficulty, and finds themselves in a situation where it takes Herculean effort just to avoid a large overrun, then the JFs will disassociate themselves from that Project as fast as they can. In the case of the PMO Director attempting to advance PM capability maturity, if it looks like it’s already headed towards success, then you’re fine. But, if they sense that such an effort will fail, they will abandon the PM cause quickly, and bad-mouth you and your attempts to bring about genuinely beneficial change to the organization. But as bad as the Jungle Fighters are, the Company Men are perhaps even worse. This archetype acts as dead weight on the PMO Director’s efforts. They won’t actively use the associate/disassociate strategy, based on the perceived odds of PM advancement success. Rather, they will seek to continue to pull a paycheck with as little disruption to their employment universe as possible. The near-twin tactics of the Slow Roll and Silent Veto, even though they can be very difficult to detect when deployed, are easily as toxic as any other obstructionist strategy. And, in a final, cruel twist, organizations that are struggling with a portfolio full of late and overrunning Projects are the ones most likely to attempt to set up a PMO in the first place, meaning that there’s a good possibility that it’s already predominantly populated by the low performer archetypes, i.e., obstructionists. I’m not recommending extended training in psychology prior to initiating a PMO implementation. But I will say that not being aware of these organizational behavior and performance pathologies, specifically obstructionism, will sink your efforts faster than overly investing in risk managers. No initial caps. |
AI-Assisted PMBOK®, Schmimbok, Part II
| Back when I was writing The Variance Threshold column, I wrote a piece entitled PMBOK, Schmimbok, (PMNetwork, March 2004) where I took exception with the inclusion of some areas of management under the PM umbrella that I thought shouldn’t be there (like Procurement, which, of course, is part of the general ledger). For Part II, I won’t review the PMBOK Guide’s® contents, but the style in which it’s written. Now, I know that this document serves as the cornerstone of PMI’s overall codex, and is expected to stand up to considerable academic review scrutiny, which largely precludes any stylistic nuance in its presentation. I get that. Even so, I can’t get past this sense that it’s exceptionally clunky in its style. Before members of GTIM Nation can ask “’Clunky’ compared to what, exactly?”, I would like to present a couple of AI-generated samples that will more clearly show what I’m talking about. I started by asking AskGPT to write a synopsis of Wuthering Heights as if it were written by the editorial committee that wrote the PMBOK Guide®, and well, here’s the first paragraph of what it produced: This document summarizes the Wuthering Heights Relationship & Revenge Program (WHRRP), an informally initiated, multi-generational engagement spanning two adjacent estates: Wuthering Heights and Thrushcross Grange. The program begins when Sponsor Mr. Earnshaw introduces an unvetted stakeholder, Heathcliff, into the Earnshaw household without impact analysis. This triggers sustained conflict with displaced stakeholder Hindley and creates a high-risk attachment between Catherine Earnshaw and Heathcliff, unmanaged by any governance or communication plan.[i] The world of projects is a bleak moor, where human schemes rise and sink beneath indifferent skies. This Guide, poor traveller, would arm you for that desolation. It speaks of initiations—how a project is first conceived in restless hearts and cold boardrooms; of planning, where hopes are measured, bound by scope, time, and cost, as if passion would submit to charts and baselines. It tells of executing those designs through human hands, weak and wayward; of monitoring and controlling, as managers strive to chain change itself, to hold back chaos with reports and metrics, though change beats at every window like the wind. You will find herein five great movements—Initiating, Planning, Executing, Monitoring and Controlling, and Closing—circling like seasons around ten grim domains: integration, scope, schedule, cost, quality, resources, communications, risk, procurement, stakeholder engagement. Yet beneath the processes and tools, the Guide confesses that all projects are but fragile houses on shifting ground, raised by mortals against uncertainty. It urges discipline, documentation, and governance, knowing still that no plan is safe from human pride, neglect, or fate, and that every endeavor must one day close, leaving only lessons, records, and echoes.[ii] The PMBOK Guide is, essentially, a big, careful attempt to answer one question: “What do competent project managers generally do, most of the time, when they’re not making it up as they go along?”[iii]
Back to the writing style of the PMBOK Guide®. I was actually on the writing team that developed the original Earned Value Management Practice Standard for PMI®. At a meeting held for several practice standard teams, one presenter said that a litmus test for including an assertion was that “no one who is considered a subject matter expert would disagree with it.” This, of course, was impossible, since you could get fifty PMs in a room, and they would not agree on the color of an orange. But it did steer the verbiage of the contributors towards an approach as if they were writing expecting to be attacked for what they put down, which pulled the whole document into definitively clunky territory. So, I understand why the Guide® was written in that particular style. I also know why I’ve never been invited to participate in writing the next edition of it. [i] Retrieved from https://askgpt.app/chat/019f0166-a003-71ec-93b2-352e8c46e37a on June 23, 2026. [ii] Ibid. [iii] Ibid. [iv] Ibid. |
The Old “Resistance To Change” Dodge
| One of the most dangerous failure modes to afflict Project Management Offices (PMOs) is easily identifiable by its post-mortem analysis, if that analysis is articulated in such a way as to place the First, let’s stipulate that, in order to advance, well, any capability within the macro-organization, we’re really looking at two distinct but related problems: (1) how to identify the optimal (or even workable) technical solution, and (2) formulating its accompanying implementation strategy. If I’ve seen it once, I’ve seen it a dozen times: a new PMO Director will come in full of confidence that the management strategies with which they are familiar will certainly work in this new environment, if only the staff will follow instructions. If (when) those strategies fail, then the fault must have been due to “resistance to change” on behalf of that same staff, the organization beyond the PMO personnel, or some combination of the two, since the exact same technical approach worked so well previously, dontcha know. The reason for the failure is virtually never perceived as the PMO Director’s inability to identify the optimal technical solution in a novel situation, or a viable implementation strategy. This managerial conceit is toxic to the PMO’s technical agenda, and potential for success. The good news, though, is that it can be avoided with a few basic concepts included in the original approach to advancing the PM capability. I want to break these basic concepts down into two bins: one for managerial leadership, and the other for executing the implementation strategy. GTIM Nation regulars know of my three rules for effective managerial leadership: 1.The effective manager-leader must be advanced enough to identify the optimal technical approach in the current environment. Recycling old strategies without proper consideration of their appropriateness in the new organization is an invitation to PMO crash-and-burn. 2.The effective manager-leader must care about the personnel in their organization. If you don’t care about your people, they will quickly pick up on it, and they won’t care about you – or your technical agenda (no matter how well-developed) – either. 3.The effective manager-leader must have sufficient confidence in the selected technical agenda that, even if they were to find themselves without a supporting organization, they would pursue that agenda anyway. Let’s add these three ground rules to the ones for developing an implementation strategy. True to the title of this blog, they were derived from Game Theory. Without going into the details, the distilled take-aways are: 1.Make the actual participation level involved in advancing the capability falling-off-a-log easy to do. If the needed level of support for advancing the targeted capability is minimal (or even non-existent), then any opposition to such change has nothing to push against. 2.For those whose active participation is required, if they fail to do so, don’t just notice. Do something about it. Call them out, put them on the spot, challenge them, use their previous words of support to remind them … whatever, just don’t let it slide. “Retaliate” is a bit harsh of a term, but if withheld needed participation goes without response, then your implementation strategy will fail to the pathologies of the Silent Veto, or the Slow Roll. 3.If those from whom you need participation are participating, but their data is sub-standard, they’re golden. Better data can be far, far more easily achieved than cooperation where it’s absent. Incorporating these elements into your leadership and implementation strategies all but removes any legitimate “resistance to change” phenomena in the macro-organization, leaving only those elements within the team who will oppose you on the most specious of grounds. The optimal (or even a workable) technical approach, coupled with an implementation strategy tailored specifically to the macro-organization, and rolled out in such a way as to minimize the additional effort needed to achieve it removes almost all of the rational bases cited in all of those articles and columns on how to deal with such resistance, just without the avalanche of psychobabble that’s often attached to them. Essentially, resistance to change is baked into the organizational cake. Blaming it for any given PMO’s demise is analogous to attributing the loss of a football game to a bunch of players in different uniforms preventing your team from scoring. PMs that understand this will see a much greater success rate. PMs that don’t will blame “resistance to change” in the post-mortem analysis. |
John Connor, PMP®
| Yes, yes, I know that this blog’s title has some explaining to do, primarily along the lines of “Are we really going to start awarding honorary PMP®s to fictional characters?”, along with “Well, if we are, why on earth would we start with the protagonist from The Terminator movies?” I can explain. For those members of GTIM Nation who were born after 1984 (the first reference to John Connor, even though he does not actually make an appearance) or after 1991 (his first actual appearance, in the sequel Terminator 2, Judgement Day), John Connor is the person that leads (will lead?) the humans in their ultimately successful counter-offensive to Skynet and its killer robots, known as Terminators, after they have turned the world into a violent, dystopian nightmare. As Connor and his forces close in on Skynet, it sends some of these killer robots back in time in order to stop Connor from being conceived in the first place (The Terminator), or growing out of adolescence (Terminator 2, Judgement Day). As with several movie franchises that feature time travel, other “futures” with different ultimate outcomes crop up; but, in at least one of the timelines, Connor is successful in either preventing Skynet from coming on-line in the first place or, having come on-line and nearly destroying humanity, leading the forces that finally, well, terminate it. Meanwhile, Back In The Project Management World… I have to snicker whenever I see Project Managers listed among the professions that are considered likely candidates for replacement by Artificial Intelligence, or AI. As GTIM Nation knows, my particular management science take on the Pareto Principle is that the 80th percentile best managers who have access to only 20% of the information needed to obviate a given decision will be consistently out-performed by the 20th percentile worst managers who have access to 80% of the information so needed. So, with critical PM-oriented information streams becoming more and more commonplace even as they are getting easier to generate, that means that even an asset manager will be able to make the optimal PM decisions on a consistent basis in the near future, right? Well, no. Notice that I’m not even attempting to speculate on the outcome of a 100% information available scenario. That’s because it doesn’t exist, and it doesn’t exist because the future cannot be quantified, despite the risk managers’ (no initial caps) attempts to do just that. As Dwight Eisenhower famously said, “Plans are worthless, but planning is everything.”[i] The difference between these two seemingly identical terms is filled by the PM. We PMs refer to the original plan as the baseline – scope, cost, and schedule, the notorious Triple Constraint – but I have yet to encounter a baseline that either remained unchanged throughout the Project’s life cycle, or accurately captured all of the variances that the Project would encounter. This is because those baselines are static, whereas actual Project execution is a highly dynamic process. The baselines are indispensable when it comes to measuring cost and schedule performance, but they simply can’t capture the events and changing circumstances that emerge that create a barrier to successfully attaining the particulars in the scope baseline on-time, on-budget. Add to that the fact that, even with 80% of the information needed, a workable decision or strategy is by no means guaranteed, let alone the optimal one. Hindsight is 20/20 goes the cliché, due to the fact that managerial decisions are almost always made with incomplete information at the time they need to be executed. Making key decisions with incomplete information is the stock and trade of PMs everywhere and, if those decisions stand the test of time – which is to say, they still make sense even after all of the relevant information is made available – then that PM’s judgement is shown to be sound. But enough of evaluating this on management science theory grounds – how does this appear in the And so, for demonstrating that AI doesn’t stand a chance against a human in a dynamic environment (even in a fictional setting), I would like to nominate John Connor for an honorary PMP®. Do I hear a second? [i] Retrieved from https://quoteinvestigator.com/2017/11/18/planning/ on June 2, 2026, 20:09 MDT. |
George Jetson, Bring Me A Rock!
| The Jetsons was an animated situation comedy by Hanna-Barbera, aired originally in 1962, but set one-hundred years into the future, in 2062. Where The Flintstones was set in the Stone Age, The Jetsons was its futuristic counterpart, and depictions of how the titular family lived were both colorful and fanciful. The family’s patriarch, George, worked (will work?) for Spacely Sprockets, where his job appeared primarily to arrive at work (via flying car, of course), take a moving sidewalk to his control panel/desk, and press a single button. If the reason why George was uniquely qualified for this task was mentioned, I don’t remember it (and, just for the record, I was too young to watch it when it first aired – I saw it in reruns). Meanwhile, Back In The Project Management World… Efforts to more fully integrate Artificial Intelligence (AI) into the PM world have some level of fascination for me. Make no mistake – I am absolutely not an AI alarmist, but I can see a certain scenario unfolding that would make us PMs’ lives harder, and it has to do with this idea that critical information streams can be had rather simply, simply because technology is advancing. After all, if the readily-available AI bots out there can write up a believable Baseline Change Proposal or Variance Analysis Report, how much harder could it be to produce more complex, enterprise-wide PM documents and reports? Here is where The Jetsons and the traditional “bring me a rock” exercises come together. Quick reference: a “bring me a rock” exercise is when a superior in your organization wants you to produce a certain thing, but their scope definition is, shall we say, wanting. You take your best shot at delivering what you believe your superior has requested, only to learn that what you produced is certainly not meeting expectations. The dead giveaway that you are in a BMAR cycle is when the requestor can’t be any more specific about what it is that they desire. You leave the presentation upbraided and frustrated, without really knowing why, and needing to come up with some other You see, plenty of these “enterprise” systems promise highly valuable information streams at (almost literally) the touch of a George Jetson-esque button. The problem is that the specific information streams that are held to be highly valuable vary from manager to manager, organization to organization. For example, consider the numerous sources needed to generate an informed facility resource plan for the next, say, fiscal quarter: ·Available resources, both human and non (payroll, inventory, facility management system, etc.), ·Programmatic load (General ledger, scheduling system), ·Anticipated programmatic load (contract backlog, proposal backlog), ·Gap analysis of the existing programmatic load to the existing resource profile (the previous bullet’s data, plus HR [projected adds] and facility capacity), ·Gap analysis of the projected programmatic load and projected resource capacity, …among many others. There is simply no way any one computer program could synthesize this information stream reliably, even if it could successfully crawl all of the data sources it would need, which is itself unlikely. Keep in mind that this is just one product that would be expected out of an enterprise-wide system. If one were to add in other, more complex information-starved decisions (such as whether or not to respond to Request for Proposals on scope that is similar, but not identical to, the existing portfolio), and the highly improbable nature of such a comprehensive Information Technology program becomes clearer. And those issues manifest even before other, more fundamental ones would have to be definitively resolved. For example, ask a typical PM how to generate an Estimate at Completion, and she will likely respond “Easy! Divide the Cost Performance Index into the Budget at Completion.” Pose the same question to a member of the same organization’s Finance and Accounting department, and he will likely respond “Easy! Take the average monthly cost expenditures for that Project, normalize it by the number of working days in each month, and then project that figure out for the remainder of the period of performance.” Each is likely to be supremely confident that their way is the right one (though the F&A fellow shouldn’t be); but, unless this enterprise system has been told how to approach this particular data processing point, it’s going to generate an “answer” that is only useful to a fraction of the macro-organization. So, here’s my ultimate take-away: if your organization has been sold on some software company’s promises of an on-demand, reliable, all-encompassing information stream that renders their high-level decisions intuitively obvious, step back, take a breath, and ask: “Can you be a little more specific about what, exactly, that output looks like?" |




