Game Theory in Management

Let’s admit it: change (ProjectManagement.com’s theme for October) only really comes about within a Project Management Office (ProjectManagement.com’s theme for November) when ideas and agendas collide, or are mis-aligned in some fashion.

If everyone within the PMO was in complete agreement with both the technical agenda and its implementation approach, along with the rest of the macro-organization, then nothing would need to be changed.

The Nash Equilibrium would be in perfect, well, equilibrium – no advancement in capability maturity would be made. Barring trajectory-altering events from outside the organization, that ship will sail on its current course indefinitely.

Alas, such business environs never exist, at least not for long (and, by “for long,” I mean intervals measurable in microseconds). There will always be mis-alignments in agendas and ideas, not to mention those outside the PMO but within the macro-organization, as well as outside event intrusions.

In a sense, the whole point of management, contrary to the asset managers’ notion that it is to “maximize shareholder wealth,” is to handle these agenda mis-alignments in such a way as to maximize the benefit the organization, or, at the very least, to minimize their negative impacts. S

o, if we assume that conflict, or shall we say competition between ideas and agendas, are inherent in the formulation of business models and management approaches, it stands to reason that some attention needs to be focused on exactly how PMO directors handle such collisions, since that approach can (and will) have a direct bearing on PMO success or failure.

I have observed, broadly speaking, two modes of dealing with competing/conflicting agendas and ideas within organizations, and their impacts on the macro-organization and the PMO specifically.

One of these modes I hold to be the most beneficial, both towards resolving problems faced by the PMO and its owning org; and the other, which I view as rather toxic, leading to unnecessary strife, poor problem resolution performance, and, ultimately, PMO decline, if not collapse. I’ll address the beneficial one first.

I believe that the optimal method of managing competition and conflicting agendas in a business environment is (ironically) what I will call the Adversarial Approach. This is where any notions of how a given problem’s solution should be formulated is challenge-able by any member of the Project Team, given that such challenges are offered on a good-faith basis and grounded in legitimate management science theory, valid premises, and supported by verifiable (or, at least agreed-to) facts.

My favorite Niels Bohr quote is one delivered to a young physicist, “Your theory is crazy, but it’s not crazy enough to be true.” In the quest to solve a problem, no one should be afraid of suffering repercussions for putting forth an idea that they genuinely believe might provide a solution.

In this sense, what I’m calling the Adversarial Approach is similar to what happens in courts of law, where strict rules of evidence and law are enforced in order to maximize the odds of arriving at the truth and, subsequently (and hopefully), justice.

In the PMO version of this approach, elements of the technical agenda and implementation approach are fielded, scrutinized, and eliminated or resolved, until what remains is a foundation for formulating the business model and management approach to the issues being addressed.

Compare and contrast this approach with the other, one that I will name the Isolate-and-Diminish style. This version is marked by assigning validity, not to the superior idea or agenda, but to the person making the case for any given decision (a sure-fire way to determine if the PMO is engaged in this mode of problem solving can be observed when the Subject Matter Experts get into a conference room to discuss the technical agenda. If any of them recite their credentials prior to discussing the problem’s particulars, it’s almost certainly an Isolate-and-Diminish-tainted org).

If the PMO Director is incapable of accepting criticisms or challenges, no matter how well-intentioned or relevant, then those with the best ideas will be quickly cowed into silence, lest they suffer repercussions for daring to disagree with their “superiors.” Such organizational environs turn toxic quickly, since perks are usually given to those who make their managers feel good, and those who don’t tend to become isolated from the rest of the Team.

Once isolated, their status often experiences degradations and diminishments, as their reputations suffer at the hands of their more cooperative colleagues. I believe that it’s notable that this corporate culture is a perfect environment for the Jungle Fighter[i] archetype, who heavily depend on ex parte conversations to advance their careers, while the Craftsman and Gamesman archetypes are repelled by this manner of resolving competing ideas.

Look, I’m not naïve (at least I try not to be): I’m fully aware that in many PMOs (and organizations in general), the coin of the realm isn’t talent or merit, but displayed loyalty to the executive’s agenda.

Even so, organizations in general, and PMOs in particular, that use the Isolate-and-Diminish model for conflict resolution are on a toxic path to dysfunction. If you are in a position to set, or even influence, the manner of evaluating competing notions within your PMO, avoid Isolate-and-Diminish.

And, if you find yourself in such an org, you might want to find a way out. Poorly-managed idea competitions and conflicts will simply make things harder all the way around.


[i] Maccoby, Michael, The Gamesman: The New Corporate Leaders, Simon and Schuster, 1976.

The answer to the title’s riddle is, of course, change itself, but besides being a play on words, I think it points to a larger truth, one that has the capability of influencing the way that PM-based business models are formulated. Because when we talk about Change Management (ProjectManagement.com’s theme for October) we’re not really discussing managing change per se. “Change” cannot be managed, at least not from a PM perspective, since change happens in the future, and the future does not exist. Rather, what we PM-types mean when we discuss Change Management is altering the plans (“baselines”) that we had set in-place prior to the start of a project, alterations that typically require a significant amount of scrutiny prior to approval, and integration into, those same cost, schedule, and scope baselines. Such scrutiny is warranted due to … well, let’s load everything into the Game Theorist’s favorite analysis tool, the payoff grid, shall we? Consider:

As per custom, we’ll dispense with the all-good scenarios first. If a Change Proposal isn’t called for, and it is not submitted (B 1), it’s all good. Similarly, if a BCP is indicated, and one is filed (A 2), again, everything’s okay. Things only get gnarly with the other two scenarios.

In Scenario B 2, a BCP is submitted before the Baseline Change Control Board, but it really should not have been. Unscrupulous PMs (not GTIM Nation members!) have been known to submit a BCP seeking additional budget or time added to the schedule for reasons that don’t really pertain to unpredictable, uncosted changes to the original baselines, including:

• Poor performance,
• Inaccurate original estimate,
• Subcontractors’ poor performance,
• Inaccurate performance measurement systems leading to the illusion of poor performance,
• Misinterpretation of the particulars of the Scope Baseline, or…
• Did I mention poor performance?

Customers issuing Firm Fixed Price contracts don’t have to worry about any of this, but pretty much all clients issuing Cost Plus contracts (or their derivates) do have to be concerned, lest they end up paying for their contractors’ errors. Avoiding Scenario B 2 is essentially the raison d’etre of Baseline Change Control Boards, who can be counted on to ferret out proposed changes that are being advanced that have even the slightest whiff of being driven by the above-bulleted reasons. Unfortunately, there is no objectively reliable Litmus Test for when a given Baseline Change is solely due to an unforeseen change in the Scope Baseline which, in turn, drives higher costs and longer durations. It’s rather subjective, leading to the need for a relatively high level of PM expertise on the BCCB – otherwise, poorly-performing Project Teams are in a good position to take advantage.

However, as odious as B 2 is to customers, from the PM’s point of view Scenario A 1 has to be considered even less desirable. In those situations where the Scope Baseline is being changed informally, with no Baseline Change Proposals/Requests being submitted, a condition known as Scope Creep enters in. The clearest example I have witnessed first-hand had to do with an environmental engineering project, where the customer would regularly ask the PM to “just” add one more analysis, or “just” expand the reliability study. Soon the calculated Estimate at Completion jumped above the Budget at Completion, and wasn’t coming down in subsequent reporting periods. I finally had to approach the PM, and told him “For cryin’ out loud, the next time (your customer) comes to you and asks for ‘just’ one additional item, tell him ‘I’d be happy to do that, and I’ll have the cost estimate ready for you tomorrow.’” Sure enough, another request came in, and the PM had an estimate prepared. “I had no idea it would cost this much!” the customer complained, completely ignoring the fact that, low cost or high, he should not have been leveraging the PM’s willingness to stay on his good side to extract non-baselined performance from the Project Team. The informal scope addition requests did stop, though.

There’s a reason Scope Creep is often identified as the number one danger to completing projects on-budget, on-time. PMs are often under Mariannas Trench-level pressure from their home organizations to expand the project base, and keeping existing customers happy is axiomatically asserted to be far easier than attracting new ones. Scenario B 2 guardrails entail entire BCCBs standing ready to enforce boundaries. Scenario A 1 protections are typically borne by just the PM.

And I have a sense that, for as long as PM remains a distinct management discipline, the threat of Scenario A 1 unfolding will never change.

[i] Template is a derivative of one from ProjectManagementDocs.com.

[ii] Retrieved from https://en.tigosolutions.com/the-standish-group-report-839-of-it-projects-partially-or-completely-fail on October 20, 2025, 20:19 MDT.

[iii] Retrieved from https://www.forbes.com/sites/jasonsnyder/2025/08/26/mit-finds-95-of-genai-pilots-fail-because-companies-avoid-friction/ on October 20, 2025, 20:21 MDT.

[iv] Retrieved from https://teamstage.io/project-management-statistics/ on October 20, 2025, 20:24 MDT.

Yeah, I know my alter-ego, the “normal” Michael, likes to write about the practical and academic aspects of advancing Project Management within organizations, but can we get real here for a minute?  Talking about Game Theory, payoff grids, and Maccoby Archetype derivatives can only get a PM so far. A recent example of how Normal Michael likes to research PM-related topics came about a few months ago, when he was travelling and picked up a copy of On Mental Toughness, a compilation of Harvard Business Review articles, from an airport news stand, part of HBR’s “Ten Must Reads.” After reading it, the only takeaway that I had was that, if you really want to be tougher mentally, don’t read anything that Harvard Business Review thinks will get you there.

So, since we’re free of observing the trappings of academic niceties, let’s jump straight to the real motives and drivers behind advancing the Project Management sciences, shall we? In this regard, I’m reminded of a group class that I attended at my dojo some years back. There we were, wearing our dogis and lined up for our black belt instructor, ready for our usual drills, when he ups and says “Why do you think you are all here?” We students exchanged confused looks, with some offering that we were there to get in better physical shape, while others asserted that proficiency in the martial arts was the reason.

“Wrong!” the instructor stated flatly. “You’re here because of one thing, and that’s fear. Fear of being bullied, perhaps, or of doing poorly in our next tournament, or even finding yourself in a situation where you truly need unarmed fighting expertise, but, one way or the other, you are here because of fear.”

Meanwhile, Back In The (Dark) PM World…

Normal Michael has pointed out in previous blogs the phenomena of executives in an organization exerting varying levels of support for the creation and/or maintenance of a Project Management Office, and how these varying levels tend to be cyclical. This cycle tends to follow a familiar pattern, to wit:

• One (or more) major projects in the portfolio encounters a significant overrun or schedule delay.
• A fact-finding or post-mortem analysis reveals a deficiency in PM capability, particularly for an organization or project portfolio of that size.
• If a PMO already exists, it receives more attention, resources, visibility, etc., etc. If one does not exist, it is created.
• The new/revamped PMO issues policies and procedures, hires schedulers and Earned Value Management specialists, buys/upgrades software, among other things.
• Full participation in monthly Project Reviews occurs at first, but soon, certain low-risk or low-dollar value Projects are exempted from having to present their cost and schedule performance information.
• As more and more work comes in on-time, on-schedule, the shame and terror of the previous overruns fades away. Attention and an emphasis on “doing PM right” is reduced.
• Our friends, the accountants, teaming up with those in the organization who despise cost and schedule performance measurement systems (because it vividly shows their lack of performance) question the expense and trouble the PMO represents, and seek to undermine – if not out and out get rid of – that same PMO.
• Then, as if on cue, another major or high-profile Project incurs a significant overrun or schedule delay, and the process begins anew.

The cyclical nature of this curve is clearly inefficient and wasteful to the macro-organization, but how does one flatten it out? By reminding those executives that, if they retreat on the capability maturity of the PMO, they are essentially inviting such overruns/delays – and it doesn’t take many of those before your larger customers simply stop awarding the high-value, high-priority work in the first place. Essentially, we’re right back to the same thing that brings karate students in to group classes on a regular basis: fear.

Fear is a powerful motivator, but it typically loses its effectiveness over time. And, again, speaking realistically while sounding cynical, policies and procedures, as they pertain to PM capability, will not reliably prevent the macro-organization from hemorrhaging that same capability to the point that staff gets re-assigned, quality control checks on the Management Information Systems deteriorates, and a vulnerability to high-impact, high-profile overruns returns. You can’t document your way to a minimum-acceptable level of PM competence.

Normal Michael isn’t a big fan of Machiavelli, but I am. One particular quote pops to mind:

You know better than I that in a Republic talent is always suspect. A man attains an elevated position only when his mediocrity prevents him from being a threat to others.[i]

And here we have, at last, an insight that Normal Michael would be loath to point out, but is almost certainly true: the dark reason that successful PMOs actually succeed is because they thread the fear needle, between relieving executives of their anxieties that they are sitting atop a project disaster that no one is telling them about on one side, and not perturbing the Project Teams with what they see as onerous additional administrative tasks to set up baselines, collect status, etc., etc. on the other.

But one area where I will agree with Normal Michael is this: risk management (no initial caps), as currently practiced, still has no place in the PMO, even in the dark paradigm.

[i] Retrieved from https://www.azquotes.com/author/9242-Niccolo_Machiavelli on October 8, 2025, 19:52 MDT.